第1章 ANR现象识别：用户卡顿、系统弹窗、导航响应超时、关键特征信号

导航操作是 Android 应用中最常见的高频交互场景。当用户点击底部导航栏、侧滑返回或执行 Fragment 切换时，系统必须 在 5 秒内 完成输入事件分发与 UI 刷新。一旦主线程被阻塞超过阈值，系统就会触发 ANR（Application Not Responding）。本章建立从用户感知到系统信号的完整识别体系，帮助开发者第一时间捕获 ANR 的四种核心表现。

1. 现象识别

ANR 不是单一表现，而是一组可观测的用户态与系统态信号的集合。以下是四种典型识别维度：

下表是 导航操作 ANR 判断规则，可快速对照当前现象定位所属类别：

2. 数据采集

确认 ANR 现象后，需在 30 秒内 采集以下三类数据，避免现场丢失：

1. Logcat 内核日志： 捕获 ANR 发生时系统输出的堆栈与 CPU 负载信息。
2. /data/anr/traces.txt： 系统自动生成的 ANR trace 文件，包含所有线程状态。
3. Systrace / Perfetto 记录： 用于分析主线程与 Binder 线程的时间线。

采集命令示例：

# 实时抓取 ANR 日志（过滤关键字段）
adb logcat -v threadtime *:E | grep -E "ANR|am_anr|CPU:"

# 导出系统 ANR trace 文件（需 root 或系统权限）
adb shell cat /data/anr/traces.txt > ./anr_traces_$(date +%Y%m%d_%H%M%S).txt

# 抓取 10s 的 Systrace（聚焦导航操作窗口）
adb shell atrace --async_start -b 16384 sched freq am freq
# 复现导航操作后停止
adb shell atrace --async_dump > ./nav_anr_trace.txt

3. 原因定位

从 trace 文件中提取以下关键线索，快速定位阻塞源头：

4. 修复动作

根据定位结果执行以下紧急修复措施（第 5~10 章会深入每种方案）：

• I/O 异步化： 将导航路径中的文件读写、DB 查询放入子线程，通过 LiveData 或 Flow 回调主线程。
• 锁降级： 用 ReadWriteLock 或 StampedLock 替代同步块，减少主线程持锁时间。
• 延迟加载： 导航目标 Fragment 使用 ViewStub 或 Lazy 方式加载非首屏视图。
• Binder 超时保护： 为远程调用设置 timeout 参数，超时后降级返回缓存或默认值。

// 示例：Binder 调用超时降级（伪代码）
fun fetchUserProfile(): UserProfile? {
    return withTimeout(2000) {
        userService.getProfile()  // 可能 ANR 的远程调用
    } ?: run {
        Log.w("NavANR", "Binder timeout, use cache")
        cacheRepo.getLastProfile()
    }
}

5. 复测

修复后需在 相同导航场景 下执行三轮验证复测：

1. 功能复测： 连续 20 次快速切换导航 Tab，记录每次跳转耗时，确保无 > 3s 的卡顿。
2. 压力复测： 使用 adb shell monkey 在导航区域发送 1000 次随机点击事件，监测 ANR 发生率。
3. Trace 对比： 重新抓取 Systrace，确认主线程连续 Runnable 时长 < 200ms，无 BLOCKED 状态。

# Monkey 复测命令（限定导航包名）
adb shell monkey -p com.example.navapp --pct-touch 70 --throttle 100 -s 42 1000

6. 预防

在开发阶段建立以下三道防线，从源头拦截导航 ANR：

• 编译期检查： 在 CI 中集成 Lint 规则或自定义 Gradle 插件，禁止在主线程调用 get()、query() 等阻塞 API。
• 运行时监控： 使用 BlockCanary 或 AnchorTask 检测主线程耗时任务，超过 2s 即告警。
• 导航链路压测： 每次版本发布前，对核心导航路径执行 200 次连续切换的自动化压测，输出 ANR 报告。