使用冻屏增强日志定位繁忙类问题

HarmonyOS社区小助手

12人浏览 · 2026-06-29 10:37:52

HarmonyOS社区小助手 · 2026-06-29 10:37:52 发布

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

使用冻屏增强日志定位繁忙类问题-华为开发者话题 | 华为开发者联盟

概述

用户在使用应用时，如果出现点击无反应或应用无响应等情况，并且持续时间超过一定限制，就会被定义为应用冻屏（AppFreeze），即应用无响应。系统会检测应用无响应，并生成AppFreeze日志，供应用开发者分析。从API 21开始，支持获取AppFreeze的增强日志。该日志通过采集整机及主线程的运行负载，并抓取多份主线程调用栈，帮助开发者知晓函数调用耗时。

日志获取及规格可以参考：AppFreeze（应用冻屏）检测-故障检测-Performance Analysis Kit（性能分析服务）-调测调优-系统 - 华为HarmonyOS开发者

冻屏的两种成因

类型	特征	传统栈追踪效果
阻塞类	线程因资源无法获得而挂起	3s/6s栈能支撑锁定耗时任务
繁忙类	线程频繁执行业务逻辑	仅靠2个瞬时栈无法锁定耗时函数

传统方案的痛点

当 ThreadBlock3s 和 InputBlock 事件的调用栈出现以下情况时，传统日志难以定位问题：

• 系统栈 - 主线程全是系统栈

• 瞬时栈 - 栈指向的函数并非真正耗时，只是一个切面

此时只能看到瞬时的调用栈片段，无法确认具体哪个函数在耗时。

增强日志的核心能力

增强日志通过以下方式解决上述痛点：

1. 采集多份主线程调用栈 - 在采样周期内多次抓取调用栈

2. 记录整机及主线程运行负载 - 辅助判断线程是否真正获得CPU执行时间

3. 采样栈与耗时关联分析 - 从多次采样中识别耗时函数

增强日志用法（重点）

Step 1: 判断线程是否获得CPU执行

查看 CPU耗时统计部分：

CpuTime: 0 ms                      <- 主线程实际运行时间
SyncWaitTime: 2995 ms              <- 主线程等待时间
StaticsDuration: 2995 ms           <- 统计总时间

判断逻辑：

场景	现象	结论
CpuTime ≈ 0	SyncWaitTime ≈ StaticsDuration	线程未获得CPU，可能是等待锁、IO阻塞等阻塞类问题
CpuTime ≈ StaticsDuration	SyncWaitTime ≈ 0	线程一直在运行，属于繁忙类问题
CpuTime 居中	两者都有值	混合问题，需进一步分析

Step 2: 分析CPU使用率

查看 CpuFreq Usage 部分：

cpu0 Usage 23.5%, 1430MHZ 21.04%
cpu1 Usage 23.5%, 1430MHZ 21.04%
cpu2 Usage 23.5%, 1430MHZ 21.04%
cpu3 Usage 23.5%, 1430MHZ 21.04%

判断逻辑：
调用栈栈顶未阻塞，CPU趋近100%，考虑系统高负载类问题，可忽略本次故障。

Step 3: 解析采样栈

增强日志会采集多份主线程调用栈，查看 #ThreadInfos 部分：

#ThreadInfos Tid: 2204, Name: com.example.freeze
SnapshotTime: 2021-01-01-20-05-58.292875
#00 pc 00000000000015b8 [shmm](__kernel_gettimeofday+72)
#01 pc 00000000001d7e44 /system/lib64/ld-musl-aarck64.so.1(clock_gettime+48)
#02 pc 00000000001d9f20 /system/lib64/ld-musl-aarck64.so.1(time+32)
#03 pc 0000000000007e2c .../libsample.so(WaitSomeTime()+76)
...

========SubmitterStacktrace========
#00 pc 0000000000013108 /system/lib64/platformsdk/libuv.so(uv_queue_work+292)
#01 pc 0000000000008cdc .../libsample.so
#02 pc 000000000005ae00 .../libace_napi.z.so(...)
...

分析步骤：

• 统计调用路径出现次数 - 从多次采样中找到重复出现的函数调用

• 抽取最大公共路径 - 识别频繁执行的代码路径

• 估算耗时 - 根据采样次数估算函数累计耗时

示例：

假设从 ThreadBlock3s 到 InputBlock 期间有6次采样：

• 3次采样命中 Task3 → Task3 耗时至少 900ms

• 3次采样命中 Task4 → Task4 耗时至少 900ms

Step 4: 结合多种栈信息分析

可结合以下堆栈信息一同分析：

堆栈类型	触发条件	用途
ThreadBlock3S	主线程卡死超过3秒	定位长时间阻塞
ThreadBlock6S	主线程卡死超过6秒	定位严重卡死
AppInputBlock	输入事件超时	定位UI响应问题
采样栈	增强日志采集	定位繁忙类耗时

优化优先级：根据调用链路出现的次数来决定优化优先级。

与Android ANR日志的对比

在Android开发中，ANR（Application Not Responding）问题定位主要依赖traces.txt文件。以下是对比分析：

核心机制对比

对比项	Android ANR	HarmonyOS AppFreeze
dump机制	系统超时后dump一次全线程栈	采样周期内多次抓取调用栈
栈数量	通常只有0-1份瞬时栈	多份采样栈（时间序列）
CPU信息	无CPU运行负载统计	完整的CpuTime/SyncWaitTime统计
任务溯源	无	SubmitterStacktrace追溯任务发起者

Android ANR日志示例

"main" tid=1 Native
  #00 pc 0x00000000000015b8  [kernel]
  #01 pc 0x00000000001d7e44  libmusl.so (clock_gettime+48)
  #02 pc 0x00000000001d9f20  libmusl.so (time+32)
  #03 pc 0x0000000000007e2c  libsample.so (WaitSomeTime+76)
  ...

问题：仅能看到一个时间点的调用栈，无法确认WaitSomeTime是瞬时执行还是持续阻塞。

HarmonyOS 增强日志示例

同样的场景，增强日志提供更多信息：

# CPU耗时分析
CpuTime: 1500 ms           <- 线程实际运行了1500ms
SyncWaitTime: 1500 ms      <- 同时等待了1500ms
StaticsDuration: 3000 ms   <- 总统计时间3000ms

# 第一次采样 (T=0ms)
SnapshotTime: 2021-01-01-20-05-58.292875
#00 WaitSomeTime()+76
#01 process()+200
#02 onInputEvent()+150

# 第二次采样 (T=300ms)
SnapshotTime: 2021-01-01-20-05-58.592875
#00 WaitSomeTime()+76
#01 process()+200
#02 onInputEvent()+150

# 第三次采样 (T=600ms)
SnapshotTime: 2021-01-01-20-05-58.892875
#00 WaitSomeTime()+76
#01 process()+200
#02 onInputEvent()+150

价值：3次采样都命中WaitSomeTime，证明该函数持续阻塞至少600ms。

采样栈的定位效果

场景1：系统栈无法定位问题

问题	Android	HarmonyOS增强日志
主线程栈全是系统调用	无法定位业务代码	通过多次采样可识别耗时业务函数
瞬时栈指向process	无法确认具体耗时	采样序列显示process累计耗时

Android日志：

#00 [kernel]
#01 EventHandler.process()
#02 EventRunner.Run()

只能知道在process中，无法确认具体哪个子函数耗时。

HarmonyOS增强日志：

# 采样1: process() -> group_api() -> render()
# 采样2: process() -> group_api() -> render()
# 采样3: process() -> list_builder() -> item_create()

可明确group_api被多次采样命中，是耗时根因。

场景2：繁忙类问题定位

问题	Android	HarmonyOS增强日志
线程Busy但不知在做什么	仅有1份栈，可能错过关键调用	多次采样覆盖完整执行路径
无法估算各函数耗时	无法估算	根据采样次数估算相对耗时

Android日志：1份栈只能看到瞬时状态。

HarmonyOS增强日志：

采样1: Task3 -> funcA -> funcB (命中)
采样2: Task3 -> funcA -> funcC (命中)
采样3: Task4 -> funcD -> funcE (命中)
采样4: Task4 -> funcD -> funcE (命中)

可确认Task3和Task4各执行2次，结合总耗时可估算单次执行时间。

场景3：异步任务溯源

问题	Android	HarmonyOS增强日志
任务由谁提交	无法追溯	SubmitterStacktrace完整链路
uv_queue_work来源	无记录	拼接任务提交者调用栈

当采样任务来源于uv_queue_work时，HarmonyOS增强日志会拼接完整的任务提交者调用栈：

========SubmitterStacktrace========
#00 uv_queue_work+292
#01 libsample.so
#02 ArkNativeFunctionCallBack()
#03 RTStub_PushCallArgsAndDispatchNative()
#04 BCStub_HandleCallthis0Imm8V8StwCopy+372
#05 at Index.ts:381:36  <- 追溯到具体JS代码行

总结对比

场景	Android ANR	HarmonyOS AppFreeze
阻塞类（等锁/IO）	3s/6s栈可定位	同样可定位
系统栈占比高	难以穿透	采样栈可穿透
瞬时栈指向模糊	无法确认耗时	采样序列可确认
繁忙类（频繁执行）	仅1份栈，难以分析	多次采样，轻松定位
异步任务溯源	无法追溯	SubmitterStacktrace可追溯