HarmonyOS 鸿蒙Next中网络请求时间过长导致THREAD_BLOCK_6S

HarmonyOS 鸿蒙Next中网络请求时间过长导致THREAD_BLOCK_6S 问题代码及相关说明：

  1. 请求完成后还包含解密时间，解密工具已经优化过了，这个接口从请求到解密确实会数据量大，确实会执行很长时间，这点基本无法优化。
  2. 在其他系统平台这个接口超时时间被定在30秒
getOrganizationalStructure(companyNo: string, companyName: string)
    : Promise<ArrayList<OrganizationalDepartmentEntity>> {
    Timber.i("getOrganizationalStructure 0000")
    return new Promise((yes, no) => {
      NetUtils
        .only()
        .post<BaseEntity<ArrayList<OrganizationalDepartmentEntity>>>(
          OS_URL_FORM.GET_ORGANIZATIONAL_STRUCTURE,
          {
            'companyNo': companyNo,
            'companyName': companyName,
          }
        )
        .then((response: AxiosResponse<BaseEntity<ArrayList<OrganizationalDepartmentEntity>>>) => {
          Timber.i("getOrganizationalStructure 1111")
          //返回成功结果
          yes(response.data.data == null ? new ArrayList() : response.data.data)
        })
        .catch((e: Error) => {
          Timber.i("getOrganizationalStructure 2222")
          // 抛出异常
          no(e)
        })
    })
  }

未到返回抛出THREAD_BLOCK_6S

存在疑问：

  1. 使用Promise网络请求后是否属于异步？
  2. 是否需要放到TaskPool或Worker中去请求？或者还有其他方案？
  3. 看过《长时任务》方案，但貌似有通知提示，接口用于界面。通知感觉没必要
  4. Promise内的操作执行也不能超过6S吗？还是我使用的方式不对？

更多关于HarmonyOS 鸿蒙Next中网络请求时间过长导致THREAD_BLOCK_6S的实战教程也可以访问 https://www.itying.com/category-93-b0.html

3 回复

THREAD BLOCK 6S 不是 HTTP 超时 6s，而是主线程（UI渲染线程）被阻塞卡住超过 6s，对用户来说就是软件卡死无响应了整整 6s，所以必然会杀

  1. 使用 Promise 处理网络请求确实是异步执行，系统在将 HTTP 包处理完就交给网络模块发送去了，网络模块不会占用主线程，所以一个正常的 HTTP request 不应该阻塞主线程，无论 http timeout 是多久都不应该阻塞主线程

  2. 理论上不用，因为 HTTP 请求的过程本身就是交给新线程完成的，主线程只做一个非阻塞等待的活

  3. 长时任务和这个不是一个概念，长时任务是让应用在后台的时候保证不被冻结，但是阻塞主线程该杀还是杀

  4. 什么东西都不能阻塞主线程超过 6s，可能你虽然 Promise 了，但是 Promise 里的任务仍然会阻塞主线程 6s，那样照样杀

我的建议是你仔细排查一下应用运行流程，多打打 log 打打断点看看应用到底是在哪一步被杀的，如果是解密的代码被杀的话，就上 TaskPool 吧

更多关于HarmonyOS 鸿蒙Next中网络请求时间过长导致THREAD_BLOCK_6S的实战系列教程也可以访问 https://www.itying.com/category-93-b0.html


在HarmonyOS鸿蒙Next中，网络请求时间过长触发THREAD_BLOCK_6S通常由主线程执行耗时网络操作引起。鸿蒙应用开发要求网络请求必须在Worker线程执行，避免阻塞UI线程。检查代码中是否使用了异步任务或TaskPool处理网络请求。若在主线程直接调用同步网络接口，系统会检测线程阻塞并抛出此异常。需将网络请求移至后台线程，通过事件机制或Promise异步处理返回结果。

在HarmonyOS Next中，Promise本身是异步的，但网络请求和解密操作如果都在主线程执行，仍可能导致THREAD_BLOCK_6S。针对你的问题：

  1. Promise包装的异步操作仍可能阻塞主线程，因为实际网络请求和解密是同步执行的
  2. 强烈建议将耗时操作移至Worker或TaskPool：
    • Worker适合长时间运行的后台任务
    • TaskPool适合短期密集型任务
  3. 对于界面相关请求，推荐使用TaskPool，它不会显示系统通知
  4. Promise内的同步操作受6秒限制，你的使用方式正确但需要线程优化

具体修改方案：

  • 将网络请求和数据解密封装成独立函数
  • 使用TaskPool.execute()执行该函数
  • 在主线程通过Promise处理返回结果

这样可以避免主线程阻塞，同时保持界面响应性。

回到顶部