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

华为开发者联盟
0 评论 129 浏览 0 收藏 14 分钟

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

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

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

概述

       用户在使用应用时，如果出现点击无反应或应用无响应等情况，并且持续时间超过一定限制，就会被定义为应用冻屏（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可追溯

       核心优势：HarmonyOS增强日志的采样栈机制，将”瞬时切面”转化为”时间序列”，特别适合Android难以定位的繁忙类和系统栈密集类问题。如下图，可以完整的看出调用序列中的瓶颈在appfreeze_threadblock模拟函数中。

总结

       冻屏增强日志的核心价值在于：将”瞬时切面”转化为”时间序列”，让开发者能够追踪主线程在一段时间内的完整执行轨迹，从而精准定位繁忙类冻屏的根因。

       增强日志使用口诀：

   • 先看CpuTime – 判断是阻塞还是繁忙

   • 再看Cpu使用率 – 确认是否为调度问题

   • 后解析采样栈 – 找出耗时函数

   • 结合多栈分析 – 确定优化优先级

本文由 @华为开发者联盟 授权发布于人人都是产品经理。未经作者许可，禁止转载

题图来自Unsplash，基于CC0协议

该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务

更多精彩内容，请关注人人都是产品经理微信公众号或下载App
华为开发者联盟
生于云，长于云，让开发者成为决定性力量
524篇作品 2235593总阅读量
共享单车第八年：谁狂飙，谁躺平？
02-286692 浏览
共享单车第八年：谁狂飙，谁躺平？
案例研究 | 手把手教你建立健身类MVP产品
03-223130 浏览
案例研究 | 手把手教你建立健身类MVP产品
赴美上市传闻再起，SHEIN走到十字路口
12-131626 浏览
赴美上市传闻再起，SHEIN走到十字路口
AI时代下，硬件产品规划手册
10-226186 浏览
AI时代下，硬件产品规划手册
TikTok电商欧美跨境变天，砍掉商家，要做自营？
05-153680 浏览
TikTok电商欧美跨境变天，砍掉商家，要做自营？
评论
评论请登录
  1. 目前还没评论，等你发挥！