第1章：ANR现象识别与场景分类

1.1 现象识别：用户与研发的“第一现场”

ANR（Application Not Responding，应用程序无响应） 是 Android 系统为保障用户交互流畅性而设立的一道“生死线”。当应用的主线程（UI 线程）被阻塞超过特定阈值时，系统会判定该应用已失去响应能力，并向用户弹出强制对话框。

1.1.1 用户侧感知特征

• 系统弹窗：屏幕中央出现“应用 X（无响应）”对话框，提供【等待】和【关闭应用】两个选项。这是最直接的可见特征。
• 交互冻结：弹窗出现前，用户触摸屏幕无反馈，点击事件丢失，页面无法滑动或跳转。
• 界面残影：部分情况下，对话框下方会透出应用页面的运行残影，但无法操作。

1.1.2 研发侧数据采集标志

1. Logcat 日志：通过 adb logcat | grep "ANR in" 可直接捕获 ANR 发生时间点与进程名。
2. Traces 文件：系统自动 dump 主线程及所有线程堆栈至 /data/anr/traces.txt（高版本可能按进程拆分）。
3. EventLog 埋点：系统埋点 am_anr 会记录 ANR 类型、CPU 负载及等待锁信息。

# 采集 ANR 日志的典型命令
adb logcat -b events | grep "am_anr"
adb shell ls -l /data/anr/
adb pull /data/anr/traces.txt ./anr_debug/

1.2 场景分类：四种 ANR 触发条件与判断规则

ANR 并非单一类型，根据触发组件的不同，系统拥有完全独立的超时监控器和处理逻辑。准确判断 ANR 类型是定位问题的第一步。

1.3 ANR 触发场景与系统响应流程

下图为 ANR 从发生到记录完成的完整故障响应链路，帮助开发者理解系统在不同超时场景下的处理方式。

1.4 用户感知与埋点数据采集

仅凭用户反馈“手机卡了”无法精确定位。必须建立自动化数据采集机制，将用户感知转化为可量化的性能指标。

• Dialog 展示埋点：在 AppNotRespondingDialog 弹出时，记录当前页面栈与用户操作轨迹。
• 进程状态监控：通过 ActivityManager.getProcessMemoryInfo() 采集 ANR 发生时的 CPU 与内存水位。
• 冷启动与后台唤醒：广播超时多发生在设备锁屏或低电量状态下，需结合 BatteryHistorian 分析电源干扰因素。

# 通过 logcat 解析 ANR 类型判断规则
# 若日志包含 "Input event dispatching timed out" → 输入超时
# 若日志包含 "Broadcast of Intent timed out" → 广播超时
# 若日志包含 "Timeout executing service" → 服务超时
# 若日志包含 "ContentProvider not responding" → Provider 超时

1.5 预防性基础设施搭建

问题排查的最终目标是预防。在项目初期应建立以下机制，从根源减少 ANR 发生概率：

1. 主线程监控：使用 Looper.getMainLooper().setMessageLogging() 监控主线程消息处理耗时。
2. 异步改造清单：对 I/O 读取、网络请求、数据库操作、Bitmap 解码强制要求运行在子线程。
3. 初始化优化：ContentProvider 的 onCreate() 中禁止执行耗时同步操作，支持懒加载或异步初始化。