AppFreeze采样栈定位“循环处理计算任务”，解决鸿蒙主线程超时问题

本原创文章帖发布在华为开发者联盟社区，欢迎开发者前往访问评论交流，更多与该内容相关讨论，请点击原帖查看：

AppFreeze采样栈定位“循环处理计算任务”，解决鸿蒙主线程超时问题-华为开发者话题 | 华为开发者联盟

前文我们分享了“锁竞争”、“UI 渲染过载”及“主线程同步 IO 阻塞”引发无响应问题的分析方法。这一篇，我们将介绍另一种无响应故障模式：“主线程执行耗时循环计算”。在鸿蒙应用开发中，部分开发者由于对业务逻辑梳理不够充分，或对算法复杂度估计不足，习惯性地将大量计算密集型任务（如数学公式计算（三角函数、矩阵运算等）、复杂的排序、遍历、递归搜索、数据转换等）直接放在主线程（UI 线程）中执行。这类操作会持续独占 CPU 资源，导致主线程消息循环（Event Loop）陷入“繁忙”状态，无法及时响应 UI 事件，导致界面卡顿、掉帧甚至无响应，严重影响用户体验。本文将演示如何利用 AppFreeze 增强采样栈，定位此类 CPU 密集型计算导致的无响应根因。

1. 问题现象

用户正常使用应用时，触发业务逻辑中的循环计算任务，应用界面逐渐由卡顿、掉帧变为无响应，最终被系统强制退出。

此时系统生成了 AppFreeze 日志，我们需要分析该日志，定位应用无响应根因。

2. 问题分析：从快照到采样栈

第一步：初步诊断（常规快照排查）

查看 AppFreeze 日志中的 THREAD_BLOCK_3S 和 THREAD_BLOCK_6S 主线程堆栈快照。

THREAD_BLOCK_3S 快照

Tid:38843, Name:xample.dfx_teststate=R, utime=612, stime=19, priority=-54, nice=-10, clk=100#00 pc 000000000018bd70 /system/lib/ld-musl-aarch64.so.1(__rem_pio2_large+1016)(86bed4865a3ab1368370b92fd7f496bb)#01 pc 000000000018b8b0 /system/lib/ld-musl-aarch64.so.1(__rem_pio2+788)(86bed4865a3ab1368370b92fd7f496bb)#02 pc 00000000000b3fd0 /system/lib/ld-musl-aarch64.so.1(sin+192)(86bed4865a3ab1368370b92fd7f496bb)#03 pc 00000000002ddb94 /data/storage/el1/bundle/libs/arm64/libentry.so(d3470c557518f4f8633b0b935e5d3206e01fbb7c)#04 pc 00000000002de100 /data/storage/el1/bundle/libs/arm64/libentry.so(TriggerBusinessBusySync(napi_env__*, napi_callback_info__*)+140)(d3470c557518f4f8633b0b935e5d3206e01fbb7c)#05 pc 00000000000722cc /system/lib64/platformsdk/libace_napi.z.so(panda::JSValueRef ArkNativeFunctionCallBack<true>(panda::JsiRuntimeCallInfo*)+1004)(f1cff79e287c9e8c76fb45a6edf15268)#06 pc 0000000000e86b98 /system/lib64/module/arkcompiler/stub.an(RTStub_PushCallArgsAndDispatchNative+40)#07 pc 0000000000d29818 /system/lib64/module/arkcompiler/stub.an(BCStub_HandleCallthis0Imm8V8StwCopy+396)#08 at TriggerBusinessBusy_sync entry (entry/src/main/ets/pages/page_second/page_third_appfreeze/appfreeze_threadblock.ets:262:12)#09 at anonymous entry (entry/src/main/ets/pages/page_second/page_third_appfreeze/appfreeze_threadblock.ets:898:19)

复制代码

THREAD_BLOCK_6S 快照

Tid:38843, Name:xample.dfx_teststate=R, utime=875, stime=19, priority=10, nice=-10, clk=100#00 pc 00000000000b381c /system/lib/ld-musl-aarch64.so.1(log+0)(86bed4865a3ab1368370b92fd7f496bb)#01 pc 00000000002de064 /data/storage/el1/bundle/libs/arm64/libentry.so(d3470c557518f4f8633b0b935e5d3206e01fbb7c)#02 pc 00000000002de14c /data/storage/el1/bundle/libs/arm64/libentry.so(TriggerBusinessBusySync(napi_env__*, napi_callback_info__*)+216)(d3470c557518f4f8633b0b935e5d3206e01fbb7c)#03 pc 00000000000722cc /system/lib64/platformsdk/libace_napi.z.so(panda::JSValueRef ArkNativeFunctionCallBack<true>(panda::JsiRuntimeCallInfo*)+1004)(f1cff79e287c9e8c76fb45a6edf15268)#04 pc 0000000000e86b98 /system/lib64/module/arkcompiler/stub.an(RTStub_PushCallArgsAndDispatchNative+40)#05 pc 0000000000d29818 /system/lib64/module/arkcompiler/stub.an(BCStub_HandleCallthis0Imm8V8StwCopy+396)#06 at TriggerBusinessBusy_sync entry (entry/src/main/ets/pages/page_second/page_third_appfreeze/appfreeze_threadblock.ets:262:12)#07 at anonymous entry (entry/src/main/ets/pages/page_second/page_third_appfreeze/appfreeze_threadblock.ets:898:19)

复制代码

初步分析两次快照

两次快照，状态均为 R(Runing)，且两次堆栈不一致，说明应用主线程没有完全卡住不动，是在执行繁忙任务，单仅凭两次快照无法判断具体哪个环节耗时过长，需要引入增强日志中的多帧采样统计来寻找"热点"。

第二步：深入挖掘（增强采样栈分析）

开启增强日志后，查看采样频率最高的热点函数，在日志文件中可以看到增强日志。

增强日志中最多可抓到 10 次采样栈，分析采样栈，提取热点函数

[Hotspot #1] - Frequency: 40% (4/10)

#00 pc 000000000018c4fc /system/lib/ld-musl-aarch64.so.1(86bed4865a3ab1368370b92fd7f496bb)#01 pc 000000000018b8b0 /system/lib/ld-musl-aarch64.so.1(86bed4865a3ab1368370b92fd7f496bb)#02 pc 00000000000b3fd0 /system/lib/ld-musl-aarch64.so.1(sin+192)(86bed4865a3ab1368370b92fd7f496bb)#03 pc 00000000002ddb94 /data/storage/el1/bundle/libs/arm64/libentry.so(d3470c557518f4f8633b0b935e5d3206e01fbb7c)#04 pc 00000000002de100 /data/storage/el1/bundle/libs/arm64/libentry.so(TriggerBusinessBusySync(napi_env__*, napi_callback_info__*)+140)(d3470c557518f4f8633b0b935e5d3206e01fbb7c)#05 pc 00000000000722cc /system/lib64/platformsdk/libace_napi.z.so(panda::JSValueRef ArkNativeFunctionCallBack<true>(panda::JsiRuntimeCallInfo*)+1004)(f1cff79e287c9e8c76fb45a6edf15268)#06 pc 0000000000e86b98 /system/lib64/module/arkcompiler/stub.an(RTStub_PushCallArgsAndDispatchNative+40)#07 pc 0000000000d29818 /system/lib64/module/arkcompiler/stub.an(BCStub_HandleCallthis0Imm8V8StwCopy+396)#08 at TriggerBusinessBusy_sync (entry|entry|1.0.0|src/main/ets/pages/page_second/page_third_appfreeze/appfreeze_threadblock.ts:228:14)#09 at anonymous (entry|entry|1.0.0|src/main/ets/pages/page_second/page_third_appfreeze/appfreeze_threadblock.ts:1808:25)

复制代码

[Hotspot #2] - Frequency: 40% (4/10)

#00 pc 00000000000b3374 /system/lib/ld-musl-aarch64.so.1(cos+172)(86bed4865a3ab1368370b92fd7f496bb)#01 pc 00000000002de038 /data/storage/el1/bundle/libs/arm64/libentry.so(d3470c557518f4f8633b0b935e5d3206e01fbb7c)#02 pc 00000000002de13c /data/storage/el1/bundle/libs/arm64/libentry.so(TriggerBusinessBusySync(napi_env__*, napi_callback_info__*)+200)(d3470c557518f4f8633b0b935e5d3206e01fbb7c)#03 pc 00000000000722cc /system/lib64/platformsdk/libace_napi.z.so(panda::JSValueRef ArkNativeFunctionCallBack<true>(panda::JsiRuntimeCallInfo*)+1004)(f1cff79e287c9e8c76fb45a6edf15268)#04 pc 0000000000e86b98 /system/lib64/module/arkcompiler/stub.an(RTStub_PushCallArgsAndDispatchNative+40)#05 pc 0000000000d29818 /system/lib64/module/arkcompiler/stub.an(BCStub_HandleCallthis0Imm8V8StwCopy+396)#06 at TriggerBusinessBusy_sync (entry|entry|1.0.0|src/main/ets/pages/page_second/page_third_appfreeze/appfreeze_threadblock.ts:228:14)#07 at anonymous (entry|entry|1.0.0|src/main/ets/pages/page_second/page_third_appfreeze/appfreeze_threadblock.ts:1808:25)

复制代码

关键线索提取

1. 分析栈顶特征：栈顶高频出现 cos 和 sin，表明主线程在做公式计算；

2. 业务层定位：明确指向 libentry.so 中的 TriggerBusinessBusySync 方法，这是问题的入口函数；

3. 根因类型：属于“循环处理计算任务”故障模式。

第三步：锁定根因（代码审查）

根据日志定位到具体入口函数，查看源码。问题代码片段如下：

ArkTs 侧调用

function TriggerBusinessBusy_sync() {  console.log('TriggerBusinessBusy_sync start');  testNapi.TriggerBusinessBusySync();  console.log('TriggerBusinessBusy_sync run');}

复制代码

c++侧实现

napi_value TriggerBusinessBusySync(napi_env env, napi_callback_info info) {    OH_LOG_INFO(LOG_APP, "[%s@%d] TriggerBusinessBusySync start - simulate business busy operation blocking main thread for 7 seconds", __func__, __LINE__);    double result = 0;    for (int i = 0; i < 100000000; i++) {        result += sqrt(i) * sin(i);        for (int j = 0; j < 10; j++) {            result += cos(j) * log(j + 1);        }    }    for (int k = 0; k < 50000000; k++) {        result += tan(k) * atan(k);        for (int l = 0; l < 5; l++) {            result += exp(l) * log(l + 2);        }    }    OH_LOG_INFO(LOG_APP, "[%s@%d] TriggerBusinessBusySync end", __func__, __LINE__);    napi_value jsResult;    napi_create_double(env, result, &jsResult);    return jsResult;}

复制代码

根因总结

1. 高频计算密集型操作：连续循环执行 sqrt/sin/cos/log/tan/atan/exp 等数学函数，无 IO 等待，持续占用 CPU 资源。

2. 同步阻塞设计：在主线程同步调用承担耗时计算任务的接口，主线程一直在等待计算结果返回，导致用户 UI 交互得不到及时响应。

3. 解决方案与最佳实践

优化策略

优化方案一：异步化改造，使用 async_work 将同步计算移至后台线程，主线程快速返回。

优化方案二：使用 FFRT 提交异步任务，利用系统线程池管理长时任务。

下面具体展开说明优化方案一。

优化方案一：使用 async_work 将同步计算移至后台线程

ArkTs 侧调用

async function TriggerBusinessBusy_sync() {  try {    console.log('TriggerBusinessBusy_sync start');    await testNapi.TriggerBusinessBusySync();    console.log('TriggerBusinessBusy_sync run');  } catch (error) {    console.error(`Failed to TriggerBusinessBusy_sync. Message: ${error.message}`);  }}

复制代码

c++侧实现

// 异步工作上下文结构typedef struct {  napi_env env;  napi_deferred deferred;  double result;} AsyncWorkContext;// 执行阶段：在子线程中运行static void ExecuteBusyWork(napi_env env, void* data) {    AsyncWorkContext* context = (AsyncWorkContext*)data;    OH_LOG_INFO(LOG_APP, "[%s@%d] TriggerBusinessBusySync start - running in worker thread", __func__, __LINE__);    double result = 0;    for (int i = 0; i < 100000000; i++) {        result += sqrt(i) * sin(i);        for (int j = 0; j < 10; j++) {            result += cos(j) * log(j + 1);        }}for (int k = 0; k < 50000000; k++) {        result += tan(k) * atan(k);        for (int l = 0; l < 5; l++) {            result += exp(l) * log(l + 2);        }}context->result = result;OH_LOG_INFO(LOG_APP, "[%s@%d] TriggerBusinessBusySync end - worker thread completed", __func__, __LINE__);}// 完成阶段：在主线程中运行，返回结果static void CompleteBusyWork(napi_env env, napi_status status, void* data) {    AsyncWorkContext* context = (AsyncWorkContext*)data;    napi_value jsResult;    // 创建返回结果    napi_create_double(env, context->result, &jsResult);       // 通过 Promise resolve 返回结果    napi_resolve_deferred(env, context->deferred, jsResult);    // 释放上下文内存    free(context);}// 主入口函数napi_value TriggerBusinessBusySync(napi_env env, napi_callback_info info) {    // 分配异步工作上下文    AsyncWorkContext* context = (AsyncWorkContext*)malloc(sizeof(AsyncWorkContext));    if (context == NULL) {        OH_LOG_ERROR(LOG_APP, "[%s@%d] Failed to allocate memory for context", __func__, __LINE__);        napi_value error;        napi_value msg = nullptr;        napi_create_string_utf8(env, "Memory allocation failed", NAPI_AUTO_LENGTH, &msg);        napi_create_error(env, nullptr, msg, &error);        return error;    }context->env = env;context->deferred = NULL;context->result = 0;// 创建 Promisenapi_value promise;napi_status status = napi_create_promise(env, &context->deferred, &promise);// 创建异步工作napi_async_work asyncWork;status = napi_create_async_work(env,NULL,// asyncResourcepromise,// resourceHint (用于调试)ExecuteBusyWork,// execute callbackCompleteBusyWork,// complete callbackcontext,// data  &asyncWork);// 队列化异步工作status = napi_queue_async_work(env, asyncWork);// 返回 Promisereturn promise;}