应用冻屏检测与主线程超时检测差异
应用冻屏检测与主线程超时检测是两种不同层面的性能问题检测机制。本文档对比两者的核心差异,帮助开发者理解何时关注应用冻屏检测,何时关注主线程超时检测。
简介
应用冻屏检测与主线程超时检测是两种不同层面的性能问题检测机制。本文档对比两者的核心差异,帮助开发者理解何时关注应用冻屏检测,何时关注主线程超时检测。
说明:
本文仅适用于Stage模型下的应用。在根据本文分析日志前,开发者需要具备JS在系统中运行情况、C++程序堆栈信息的相关基础知识。
核心差异对比
检测机制对比
| 对比项 | 应用冻屏检测 | 主线程超时检测 |
| 检测发起方 | 系统侧自动检测,无需开发者适配 | 开发者可主动配置检测,也可使用默认检测 |
| 检测阈值 | 秒级(3s/6s) | 毫秒级(150ms/450ms) |
| 检测目的 | 发现用户可感知的严重卡顿问题 | 发现影响流畅度的性能问题 |
| 故障后果 | 系统杀死应用进程 | 仅生成日志,不影响应用运行 |
| 检测对象 | 主线程阻塞、输入响应超时、生命周期超时 | 主线程单次事件处理耗时 |
检测类型对比
应用冻屏检测类型
应用冻屏检测是系统级检测机制,检测主线程长时间阻塞、输入响应超时、生命周期切换超时等问题。
| 检测类型 | 触发条件 | 说明 |
| THREAD_BLOCK_3S | 主线程执行任务超过3s | 应用冻屏告警事件,用于提前预警主线程阻塞风险 |
| THREAD_BLOCK_6S | 主线程执行任务超过6s | 应用冻屏故障事件,系统会杀死应用进程 |
| APP_INPUT_BLOCK | 用户输入响应超时 | 点击事件超过5s(log版本8s)未得到响应 |
| LIFECYCLE_TIMEOUT | 生命周期切换超时 | UIAbility生命周期切换未在指定时间内完成,Load超时10s,Foreground超时5s |
主线程超时检测类型
主线程超时检测是性能监控机制,检测主线程单次事件处理耗时,帮助开发者发现性能瓶颈。
| 检测类型 | 触发条件 | 说明 |
| 堆栈采集 | 150ms < 主线程处理时长 < 450ms | 采集主线程调用栈,用于分析性能热点 |
| trace采集 | 主线程处理时长 > 450ms | 采集trace文件,用于详细分析任务执行情况 |
重要说明:
主线程超时检测与应用冻屏检测的THREAD_BLOCK_3S/6S是两种独立的检测机制:
• 主线程超时检测关注的是单次事件处理耗时(毫秒级),用于性能优化和流畅度分析。
• THREAD_BLOCK_3S/6S关注的是主线程长时间阻塞(秒级),是系统保护机制,用于检测应用无响应问题。
• 主线程超时检测不会触发应用冻屏事件,两者互不影响。
日志获取方式对比
| 获取方式 | 应用冻屏检测 | 主线程超时检测 |
| HiAppEvent订阅 | 支持 | 支持 |
| DevEco Studio | 支持(FaultLog) | 不支持 |
| hdc命令 | 支持(需打开开发者选项) | 不支持 |
日志存储位置对比
| 对比项 | 应用冻屏检测 | 主线程超时检测 |
| 日志存储路径 | /data/log/faultlog/faultlogger/ | 应用沙箱目录/data/storage/el2/log/watchdog/ |
| 日志文件格式 | appfreeze-进程名-进程UID-毫秒级时间.log | MAIN_THREAD_JANK_秒级时间_进程PID.txt/.trace |
| 日志文件大小 | 较大(包含完整进程信息) | 堆栈文件:7-10KB;trace文件:1-5MB |
何时关注应用冻屏检测
适用场景
开发者在以下场景应重点关注应用冻屏检测:
1. 用户投诉应用无响应:用户反馈应用点击无反应、界面卡死等问题时,应优先排查应用冻屏日志。
2. 应用被系统强制终止:应用在运行过程中被系统杀死,且没有明确的崩溃日志时,应排查应用冻屏日志。
3. 生命周期切换异常:应用在启动、切前台、切后台等生命周期切换过程中出现异常,应关注LIFECYCLE_TIMEOUT事件。
4. 输入响应延迟:用户点击或触摸操作无响应,应关注APP_INPUT_BLOCK事件。
问题定位思路
| 故障类型 | 问题定位思路 |
| THREAD_BLOCK_6S | 检查主线程是否有耗时操作、死循环、同步锁等待等。重点关注EventHandler dump中的任务执行时间和堆栈信息。 |
| APP_INPUT_BLOCK | 检查点击事件处理逻辑,是否在主线程执行了耗时操作,是否有多线程竞争问题。 |
| LIFECYCLE_TIMEOUT | 检查UIAbility生命周期回调(onCreate、onForeground等)中是否有耗时操作。 |
关键日志字段
应用冻屏日志中重点关注以下字段:
| 字段 | 说明 |
| Reason | 应用无响应原因,对应检测类型 |
| MSG | 故障时间及EventHandler信息 |
| Current Running | 当前正在执行的任务信息 |
| 堆栈信息 | 故障进程调用栈,定位阻塞代码 |
何时关注主线程超时检测
适用场景
开发者在以下场景应重点关注主线程超时检测:
1. 应用流畅度优化:在优化应用流畅度时,主线程超时检测可以帮助发现影响帧率的性能瓶颈。
2. 性能压测分析:在性能测试过程中,需要分析主线程的任务执行情况,找出耗时操作。
3. 帧率问题定位:应用出现掉帧、卡顿等流畅度问题时,应关注主线程超时日志。
4. 开发阶段性能监控:开发阶段可主动接入HiCollie检测,监控关键业务逻辑执行时长。
问题定位思路
| 检测类型 | 问题定位思路 |
| 堆栈采集(150ms~450ms) | 关注频繁出现的堆栈帧,可能是性能热点;检查是否需要将耗时操作移至后台线程。 |
| trace采集(>450ms) | 使用HiSmartPerf工具分析trace文件,查看CPU调度、任务执行时间等详细信息。 |
关键日志字段
主线程超时日志中重点关注以下字段:
| 字段 | 说明 |
| 采样次数 | 堆栈帧前的数字,表示该帧被采样到的次数,次数越多表示该函数执行时间越长 |
| 帧调用层级 | 树型展示的缩进层级,帮助理解调用关系 |
| 函数路径 | JS帧包含源码路径和行列号,便于定位代码位置 |
两者关系说明
演进关系
主线程超时检测与应用冻屏检测存在演进关系:
1. 主线程超时检测是应用冻屏检测的前置告警机制。当主线程处理时长超过150ms时,会触发主线程超时检测的堆栈采集;当超过450ms时,会触发trace采集。
2. 应用冻屏检测是主线程长时间阻塞的严重后果。当主线程阻塞超过3s时会触发告警,超过6s时会生成应用冻屏事件并杀死应用进程。
互补关系
两者互为补充,形成完整的性能监控体系:
| 监控层面 | 检测机制 | 作用 |
| 轻度卡顿 | 主线程超时检测 | 及时发现性能问题,避免演变为严重故障 |
| 重度卡顿 | 应用冻屏检测 | 捕获严重阻塞问题,保障系统稳定性 |
AppFreeze增强日志(采样栈)与主线程超时检测堆栈采集对比
AppFreeze增强日志(采样栈)
从API version 21开始,支持获取AppFreeze的增强日志。该日志通过采集整机及主线程的运行负载,并抓取多份主线程调用栈,帮助开发者分析问题根源。
实现原理:
1. 应用进程在运行时发生THREAD_BLOCK_3S或LIFECYCLE_HALF_TIMEOUT时,会开启采集主线程调用栈流程。
2. 应用进程在运行时发生THREAD_BLOCK_6S、LIFECYCLE_TIMEOUT或APP_INPUT_BLOCK时,会停止采集流程,并计算周期内的CPU信息。一般情况下,会抓取1~10次堆栈日志。
日志内容:
| 信息类型 | 说明 |
| CPU总体耗时信息 | ProcessCpuTime、DeviceRuntime、CpuTime、SyncWaitTime、OptimalCpuTime、SupplyAvailableTime等 |
| 主线程堆栈信息 | 多次抓取的主线程调用栈,包含SnapshotTime、Stack、SubmitterStacktrace等 |
对比分析
AppFreeze增强日志(采样栈)与主线程超时检测的堆栈采集均通过采样方式获取主线程调用栈,但存在以下差异:
| 对比项 | AppFreeze增强日志(采样栈) | 主线程超时检测堆栈采集 |
| 触发条件 | THREAD_BLOCK_3S或LIFECYCLE_HALF_TIMEOUT触发,THREAD_BLOCK_6S等故障发生时停止 | 主线程处理时长150ms~450ms |
| 采样周期 | 故障发生期间(3s~6s) | 触发后每隔150ms采样一次 |
| 采样次数 | 1~10次 | 10次 |
| 日志格式 | 独立文件,包含CPU信息和多次堆栈 | 聚合展示,树型结构 |
| 日志位置 | /data/log/faultlog/freeze_ext/ | 应用沙箱/data/storage/el2/log/watchdog/ |
| 分析工具 | 人工分析或聚类工具 | 可用聚类分析 |
互斥关系说明
注意:
AppFreeze增强日志的采样栈会与MAIN_THREAD_JANK冲突:
• 如果应用接入MAIN_THREAD_JANK的setEventConfig接口自定义配置采集堆栈的个数,AppFreeze增强日志的采集堆栈个数会与应用当前配置一致。
• 开发者在分析应用冻屏问题时,如需详细的堆栈信息,可同时参考AppFreeze增强日志(采样栈)和主线程超时检测的堆栈文件。
选择建议
| 场景 | 推荐使用的日志 |
| 分析应用冻屏问题 | 优先使用AppFreeze增强日志(采样栈),包含故障期间的完整CPU和堆栈信息 |
| 分析主线程性能热点 | 使用主线程超时检测堆栈文件,采样频率固定,便于分析任务执行情况 |
| 需要详细trace分析 | 使用主线程超时检测trace文件(触发条件>450ms) |
最佳实践建议
开发阶段
1. 主动接入主线程超时检测,监控关键业务逻辑执行时长。
2. 使用HiCollie设置自定义超时阈值,提前发现性能问题。
3. 定期分析主线程超时日志,优化热点代码。
测试阶段
1. 在性能测试中关注主线程超时日志,分析帧率和流畅度问题。
2. 在稳定性测试中关注应用冻屏日志,排查严重阻塞问题。
发布阶段
1. 应用冻屏检测作为系统级保护机制,无需额外适配。
2. 主线程超时检测日志可帮助分析用户反馈的卡顿问题。
—————————————————————————————————–
🔗 官网开发者学堂视频:https://developer.huawei.com/consumer/cn/training/result?type2List=201783644516849879&orderBy=1&courseType=5

🔗 社区DFX专题文章: https://developer.huawei.com/consumer/cn/forum/subject/2101218731402391001


【扫码加入 HarmonyOS DFX 技术交流群】
本文由 @华为开发者联盟 授权发布于人人都是产品经理。未经作者许可,禁止转载
题图来自Unsplash,基于CC0协议
该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务
- 目前还没评论,等你发挥!

起点课堂会员权益




