第2章 ANR分类与触发条件：输入事件超时、广播超时、服务超时、ContentProvider超时

阶段一：现象识别

ANR 在用户端的表现并不完全相同。排查的第一步是通过 现象特征 快速缩小范围，判断属于哪一类超时。下表列出了四类 ANR 的用户感知差异与系统弹窗特征。

阶段二：数据采集

确认 ANR 现象后，需要立刻采集三类证据：系统 trace、logcat、dropbox 记录。不同 ANR 类型在日志中的标记位置不同。

2.1 采集命令与路径

# 获取 ANR trace 文件（需 root 或 adb 权限）
adb pull /data/anr/traces.txt
adb pull /data/anr/anr_*.txt

# 过滤 ANR 相关 logcat 日志
adb logcat -b all | grep -E "ANR|Timeout|InputDispatcher|BroadcastQueue|ServiceRecord|ProviderRecord" > anr_log.txt

# 查看 dropbox 系统级 ANR 记录
adb shell dumpsys dropbox --print ANR

2.2 各类 ANR 的日志特征

阶段三：原因定位

拿到日志与 trace 后，使用 故障树分析法 逐层判断 ANR 类型。以下故障树展示了从根节点到具体触发条件的排查路径。

3.1 触发条件判断规则

使用以下规则表配合 trace 日志，可以快速锁定 ANR 类别：

3.2 trace 日志实例分析

以下是一段真实的输入事件超时 trace 摘录展示主线程卡在布局加载上：

----- pid 12345 at 2025-01-20 14:23:45 -----
Cmd line: com.example.myapp
"main" prio=5 tid=1 Native
  at android.os.MessageQueue.nativePollOnce(Native Method)
  at android.os.MessageQueue.next(MessageQueue.java:325)
  at android.os.Looper.loop(Looper.java:142)
  at android.app.ActivityThread.main(ActivityThread.java:6934)
  at java.lang.reflect.Method.invoke(Native Method)
  at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:493)
  at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:858)
  
  // 主线程正在执行 inflate 操作 —— 典型耗时场景
  at android.view.LayoutInflater.inflate(LayoutInflater.java:540)
  at com.example.myapp.MainActivity.onCreate(MainActivity.java:45)
  ...

若日志中主线程堆栈停在 BroadcastReceiver.onReceive() 或 ContentResolver.query()，则可据此直接定位到对应的 ANR 类型。

阶段四：修复动作

根据定位到的 ANR 类型，采取对应的修复策略。下表汇总了四类超时的典型修复方案与代码级操作：

4.1 广播超时修复示例（goAsync）

public class SafeReceiver extends BroadcastReceiver {
    @Override
    public void onReceive(Context context, Intent intent) {
        final PendingResult pendingResult = goAsync();   // 关键：转为异步
        new Thread(() -> {
            try {
                // 耗时操作：数据库写入 / 网络请求
                handleBackgroundWork(context, intent);
            } finally {
                pendingResult.finish();   // 必须在 10s/60s 内调用
            }
        }).start();
    }
}

4.2 服务超时修复示例（IntentService）

public class LightweightService extends IntentService {
    public LightweightService() {
        super("LightweightService");
    }
    @Override
    protected void onHandleIntent(Intent intent) {
        // 此方法运行在子线程，不会导致 ANR
        processTask(intent);
    }
}

阶段五：复测

修复后需要按照 原始触发路径 重新验证，并辅以压力测试确保问题闭环。

• 输入事件超时： 快速连续点击按钮、滑动列表、多次旋转屏幕，使用 adb shell dumpsys input 检查事件响应延迟。
• 广播超时： 使用 adb shell am broadcast -a com.example.TEST_ANR 发送测试广播，观察 logcat 是否还有 Timeout。
• 服务超时： 使用 adb shell am startservice 或绑定服务重复启动，检查 ServiceRecord 超时日志。
• ContentProvider 超时： 使用 adb shell content query --uri content://... 模拟大数据量查询，验证是否超时。

每轮测试后检查 /data/anr/traces.txt 是否生成新的 ANR 记录，同时监控 logcat 中 Timeout 关键字出现次数。

阶段六：预防

将以下预防机制纳入开发流程与 CI 门禁，从源头减少 ANR 风险：