第4章：日志采集工具链——adb logcat、dumpsys、traces.txt、bugreport 抓取

4.1 现象识别：什么时候必须抓日志？

并非所有卡顿都需要完整日志链。以下 3 类现象 必须立即启动日志采集，否则现场容易丢失：

• 连续 ANR：同一页面在 3 分钟内出现 ≥2 次 "应用无响应" 弹窗。
• 关键路径 ANR：启动、跳转、支付、消息发送等核心流程发生 ANR。
• 偶发 ANR：无法稳定复现，但线上监控上报率 > 0.1%。

4.2 数据采集：四类日志工具详解

下面按 采集顺序 和 信息密度 排列四类工具。实际排查时建议 一次性全部抓取。

4.2.1 adb logcat —— 实时流水，锁定时间窗口

在 ANR 弹窗出现后 立即 执行，注意加上 -v threadtime 以显示线程 ID 和时间戳：

# 清空旧缓存，只保留后续日志
adb logcat -c
# 开始采集（建议同时输出到文件）
adb logcat -v threadtime *:V > anr_logcat.txt

关键检索字段：

• ANR in —— ANR 发生入口
• Input dispatching timed out —— 输入事件超时
• Reason: —— 系统给出的 ANR 原因描述
• CPU usage —— ANR 时刻 CPU 负载分布

4.2.2 dumpsys —— 进程快照，查负载与线程

ANR 发生后 尽快 执行下面两条，用于分析 CPU 竞争和线程状态：

# CPU 使用率快照
adb shell dumpsys cpuinfo

# 目标进程的线程信息（以 com.example.app 为例）
adb shell dumpsys meminfo com.example.app
adb shell dumpsys activity processes | grep "com.example.app"

核心判断规则：

• CPU 总体 > 90% 且 主线程占比 > 30% → 主线程自身 CPU 密集型阻塞
• CPU 总体 > 90% 但 主线程占比 < 10% → 主线程被其他线程/进程争抢 CPU
• CPU 总体 < 50% → 主线程在等待锁、I/O 或 Binder 调用

4.2.3 traces.txt —— ANR 堆栈铁证

系统在 ANR 发生时自动生成，位于 /data/anr/traces.txt。每个进程会 dump 出 所有线程的堆栈，主线程栈顶就是卡住的那一行代码。

# 拉取 traces.txt（需要 root 或 非生产环境）
adb root
adb remount
adb pull /data/anr/traces.txt .

主线程堆栈解读范例：

----- pid 12345 at 2025-01-15 10:30:00 -----
Cmd line: com.example.app
"main" prio=5 tid=1 Blocked
  | group="main" sCount=1 dsCount=0 flags=1 obj=0x...
  | sysTid=12345 nice=0 cgrp=default sched=0/0 handle=0x...
  at java.lang.Object.wait(Native Method)
  - waiting on <0x03a4c1e0> (a java.lang.Object)
  at com.example.data.local.DatabaseHelper.query(DatabaseHelper.java:45)
  - locked <0x03a4c1e0> (a java.lang.Object)
  at com.example.ui.MainActivity.loadData(MainActivity.java:78)
  at com.example.ui.MainActivity.onCreate(MainActivity.java:35)

线程状态速查表：

4.2.4 bugreport —— 全量诊断，一次搞定

如果时间允许，优先执行 bugreport，它会打包 logcat、dumpsys、traces.txt、系统配置等全部信息：

# 生成 bugreport 压缩包（耗时约 30~60 秒）
adb bugreport bugreport_anr_$(date +%Y%m%d_%H%M%S).zip

解压后的目录结构：

• bugreport-*.txt —— 汇总报告，包含所有 dump 信息
• logs/ —— 包含 logcat、dumpsys 等原始文件
• FS/data/anr/traces.txt —— ANR 堆栈文件

4.3 原因定位：日志交叉分析三步法

单一日志往往只能看到表象，交叉分析 才能定位根因。下面以故障树形式给出排查流程：

4.4 修复动作：基于日志类型的精准施策

交叉分析锁定根因类型后，对应修复动作如下：

4.5 复测：验证修复是否有效

修复后使用同样的工具链做 前后对比：

1. 复现验证：按原步骤触发场景，确认 ANR 不再出现。
2. logcat 对比：检查 ANR in 字段是否消失，CPU usage 中主线程占比是否下降。
3. traces.txt 对比：修复前的主线程栈顶状态为 Blocked/Waiting，修复后应为 Runnable 且耗时合理。
4. dumpsys 对比：线程总数是否减少，锁等待时间是否归零。

4.6 预防：日志采集自动化规范

避免每次 ANR 都靠人工手动抓取，建立以下机制：

• 自动化触发：在 Application 中注册 ANRWatchDog 或系统 ANRRecoveryHandler，当检测到 ANR 时自动执行 adb bugreport 并上传。
• 日志保留策略：本地保留最近 3 次 ANR 的 traces.txt + logcat 片段，循环覆盖。
• 关键字段告警：监控 logcat 中 Input dispatching timed out、ANR in、Reason: 等关键字，触发即时通知。