ANR 现象识别与分类

ANR（Application Not Responding）是 Android 系统对主线程超时阻塞的最终裁决。无论应用架构多优秀，ANR 一旦发生，用户体验直接归零。本章聚焦于现象识别与分类边界，在动手优化前，先建立一套可执行的判断规则，确保每一个 ANR 都能被正确归类。

1.1 四类 ANR 的核心特征

系统根据触发场景将 ANR 分为四个主要类型：启动 ANR、输入 ANR、广播 ANR 和服务 ANR。不同类型对应不同的超时阈值与堆栈特征，以下是判定清单：

1.2 故障树：快速判定 ANR 类型

当 ANR 发生时，不要直接看堆栈，先按以下故障树定位分类：

1.3 排查表：从日志到分类

以下排查表列出每种 ANR 在 event log 中的典型模式，以及对应的堆栈位置：

adb logcat -b events -d | grep "am_anr" | tail -1
# 典型输出示例：
# I/am_anr(  985): [0,60000,com.example.app,7329,keyDispatchingTimedOut]

1.4 判断规则：防止误分类

以下规则用来处理边界情况，避免将系统 ANR 误判为应用 ANR，或在不同类型间来回切换：

• 规则 1： 如果堆栈顶部是 nativePollOnce 且 event log 没有 am_anr，
  这不是 ANR，是系统采样延迟，直接跳过。
• 规则 2： 广播 ANR 如果 reason 包含 forced 后缀，说明系统主动杀进程，
  需要配合 lowmemorykiller 日志分析，不单独做主线程优化。
• 规则 3： 输入 ANR 中如果检测到 InputDispatcher::notifyANR 但主线程堆栈为 binder transaction，
  优先定位前台服务的 Binder 调用超时，而非主线程自身。
• 规则 4： 同一进程连续触发多类 ANR 时，以首次 ANR 类型为准，
  后续 ANR 可能是连锁反应，修复主因即可。

1.5 数据采集：明确取证范围

在进入原因定位前，先完成以下数据采集清单，确保分类依据充足：

1. 必选： traces.txt 文件（ANR 发生时自动生成，位于 /data/anr/traces.txt）。
2. 必选： adb logcat -b events -d | grep am_anr 提取事件日志。
3. 必选： adb logcat -d | grep -E "ANR|am_anr|watchdog" 获取系统日志摘要。
4. 可选： 如果问题可复现，开启 strict mode 抓取主线程违规记录：

   StrictMode.setThreadPolicy(new StrictMode.ThreadPolicy.Builder()
           .detectAll()
           .penaltyLog()
           .penaltyDeath()  // 严重阻塞可设为 ANR 前触发
           .build());

1.6 修复方向与预判

一旦完成分类，直接进入修复动作预判：