3. ANR 故障树构建：从现象到根因的逐层分解、判断节点、概率权重
ANR 治理的第一步并非直接修复，而是建立系统化的故障树。只有将模糊的“应用无响应”现象逐层拆解为可观测、可触达的判断节点，研发人员才能精准定位阻塞根因，并依据概率权重分配排查优先级。本章围绕“现象识别 → 数据采集 → 原因定位 → 修复动作 → 复测 → 预防”完整闭环，构建一株可直接复用至日常开发的 ANR 故障树。
核心认知：ANR 故障树不是理论推导的产物，而是基于数十万条实际 Trace 与日志的统计归纳。每一个分支节点都对应一个可执行的判断规则，概率权重则来自生产环境大数据。
3.1 故障树构建方法论
故障树以 ANR 被用户感知作为顶事件，逐层下探至可被代码 Log 或 Trace 明确捕获的判断节点。每一条路径都遵循 “观测 → 判断 → 归类” 三步走：
- 层1 — 现象识别：用户报告“卡死”或系统弹出 ANR 弹窗，人工确认输入事件处理超时 5s 或 Broadcast 超时 10s。
- 层2 — 主线程阻塞判定：通过
traces.txt或dumpsys activity processes确认主线程处于 Runnable（长时间未发出调度）或 Native（内核态等待）状态。 - 层3 — 场景归属：根据 Trace 中 Stack Frame 第一调用栈判断属于 同步锁、Binder 通信 还是 文件 IO / 资源锁。
- 层4 — 根因定位：深入分析锁名、Binder 事务码、文件描述符状态，输出精确根因。
实战建议：在故障树每一层都绑定一个 判断规则 和 排查动作。例如层2的规则是“主线程连续 2 次采样（间隔 1s）均处于 Runnable，且无 yield”，排查动作是“抓取连续 Trace 并计算线程时间分配”。
3.2 概率权重与排查优先级
| 阻塞场景 | 概率权重 | 典型堆栈关键字 | 排查优先级 |
|---|---|---|---|
| Binder 通信 | 40% | IPCThreadState::waitForResponse / binder_transaction |
高 🔴 |
| 同步锁 / 死锁 | 35% | pthread_mutex_lock / Object.wait |
高 🔴 |
| 文件 IO / 资源锁 | 25% | file_read / fsync / epoll_wait |
中 🟡 |
概率权重直接影响排查顺序：应优先排查 Binder 主线程同步调用，因为其在生产环境中占比最高，且通常有明确的 Binder 服务端堆栈可追溯。同步锁场景虽次之，但死锁可能导致 ANR 持续时间更长、严重度更高；文件 IO 场景往往和环境（磁盘压力、加密分区）相关，排查链路在其他两种场景之后。
3.3 判断节点卡片：可执行的排查动作
每个故障树节点都配套一张“判断卡片”，包含 现象 → 日志命令 → 判定逻辑 → 下一步。以下为 Binder 通信场景判断卡片示例：
判断卡片 B-01：主线程是否在等待 Binder 回复？
命令：
下一步：记录 Binder 事务 code 与目标服务，检查服务端响应是否存在死锁或缓慢。
命令：
adb shell dumpsys activity processes | grep -A 5 "main"
adb shell cat /data/anr/traces.txt | grep "Binder:0x" -A 10IPCThreadState::waitForResponse，并且该事务等待时间超过 2.5s（ANR 阈值的一半），则进入 Binder 分支。下一步：记录 Binder 事务 code 与目标服务，检查服务端响应是否存在死锁或缓慢。
同步锁场景判断卡片参考：
注意：死锁的判断不能仅靠一次 Trace。建议连续抓取 3 次 Trace（间隔 1s），确认锁持有线程始终未释放，且等待线程集合不变化。
3.4 从故障树到修复动作的闭环映射
故障树的每一片叶子（根因）都对应一个或多个修复动作。下表展示部分映射关系：
| 故障树叶节点 | 概率权重 | 修复动作 | 复测手段 | 预防措施 |
|---|---|---|---|---|
| 主线程同步调用未设超时 | 40% | 加入 timeout=5s，使用 Future.get(5, TimeUnit.SECONDS) 或 Binder 带 timeout 接口 |
压力测试下检查超时回退是否生效 | Code Review 禁止主线程无超时 IPC |
| 锁竞争导致线程挂起 | 35% | 减小锁粒度 / 替换为 ReentrantLock + 超时 |
并发测试验证锁争用下降 | 静态死锁检测工具集成到 CI |
| 文件 IO 在慢磁盘上阻塞 | 25% | 主线程文件操作移至异步线程，使用 StrictMode 兜底 |
慢磁盘模拟 + ANR 监控采集 | 建立主线程禁止大文件 IO 规则 |
故障树一旦建立，便成为 ANR 治理的“认知地图”。后续章节将分别深入每个场景的具体数据采集（第 4~6 章）、Trace 分析技巧（第 7~10 章）以及修复与预防工程化（第 15~20 章）。
实操入口：从第 4 章开始，我们进入“数据采集”环节——用 Shell 与 ADB 命令捕获 ANR 故障树最底层的叶子证据。