AppFreeze（应用冻屏）是一种看门狗机制。当应用主线程被长时间阻塞，无法及时响应用户输入或系统调度时，系统会强制终止该应用。
AppFreeze主要包含以下两种核心检测机制：
- THREAD_BLOCK_6S 应用主线程卡死超时。
- APP_INPUT_BLOCK 用户输入响应超时。
检测原理：当用户对设备进行操作（如点击屏幕、按键）时，多模输入服务（Multimodal Input Service）会将事件派发给应用。如果应用的主线程在收到输入事件后，超过5秒仍未反馈处理结果（即未完成事件分发回调），系统认为该应用无法响应用户输入，触发输入阻塞故障。
问题定位
获取appfreeze日志，请按照以下步骤定位：
日志获取方式：
- 将设备连接至PC。
- 使用DevEco Studio的FaultLog工具查看。
- 或使用命令行工具导出：hdc file recv /data/log/faultlog/faultlogger/<本地路径>。
[h2]步骤一：确认故障类型与时间差。
打开日志文件，首先查看日志头部的Reason字段，确认是上述哪种机制触发。
接着，在日志中搜索THREAD_BLOCK_6S（最常见）的日志段落，找到mainHandler dump区域。
对比Current Running: start at ...（当前任务开始时间）与EventHandler dump begin curTime: ...（日志抓取检测时间）。
- 若差值接近或超过6秒：说明是当前正在运行的任务耗时过长，直接导致卡死。请跳转步骤三。
- 若差值很小（如1秒内）：说明当前任务并未超时，需要排查主线程是否积压大量任务导致调度不及时，请执行步骤二。
[h2]步骤二：排查消息队列积压。
查看日志中Event runner下方的队列统计信息：
- 输入：检查Total size of High events（高优先级事件）、VIP events等数量。
- 输出：如果High events数量超过400或总事件数异常巨大（如上万），说明业务代码在短时间内发送了大量高优先级任务（例如在循环中频繁post任务），导致主线程被占满，无法响应系统检测。此时需审查业务逻辑中消息发送的频次。
[h2]步骤三：分析主线程堆栈（核心步骤）。
找到日志中的Tid与应用进程ID一致的线程堆栈（通常为第一个线程，即Main Thread），根据**栈顶（Stack Top）**函数判断卡死原因：
- 场景一：IPC通信阻塞。
- 现象：栈顶出现OHOS::BinderConnector::WriteBinder、WaitForCompletion等Binder通信相关函数。
- 定位：应用向系统服务或其他进程发起同步请求，对端未返回。需查看日志中的BinderCatcher字段，找到to server_pid对应的进程，并分析该对端进程的堆栈。
- 场景二：等锁卡死。
- 现象：栈顶出现__timedwait_cp、pthread_mutex_lock、ConditionVariable::wait等锁相关函数。
- 定位：主线程在等待锁释放。需排查代码中锁的使用逻辑，是否存在死锁，或持锁的子线程是否发生异常。
- 场景三：业务代码耗时/死循环。
- 现象：栈顶直接指向开发者的.ets或.ts文件代码行，或出现Calculate、Layout（布局计算）等函数。
- 定位：
- 若多次抓取的日志栈顶行号一致，且Hilog有大量重复打印，疑似死循环。
- 若栈顶涉及MarkDirty、Measure、ForEach等耗时操作，且页面包含List、Grid等组件，疑似渲染负载过重（如一次性加载大量数据）。
- 若栈顶涉及read、write、Open，说明在主线程进行了同步I/O操作。