第3章 ANR日志采集方法

现象识别：ANR触发条件

当主线程执行Room数据库操作（如查询、插入、事务）超过5秒时，系统会弹出“应用无响应”对话框，并生成ANR日志。核心现象包括：

• 界面卡死超过5秒，用户无法操作
• 系统提示“xxx应用未响应，是否关闭？”
• Logcat中出现 ANR in 关键日志行

数据采集：三种核心方法

方法详解

3.1 使用 adb pull /data/anr/ 获取trace文件

在ANR发生后，立即连接设备并执行以下命令：

adb shell ls /data/anr/
adb pull /data/anr/ ./anr_logs

注意：需要设备已root或应用为debuggable版本。若权限不足，可尝试 adb root 后再执行。产出的trace文件中包含所有线程的堆栈，是定位主线程阻塞的根本依据。

3.2 Logcat过滤“ANR in”

使用以下命令捕获系统ANR通告：

adb logcat -b events -b main -b system | grep -E "(ANR in|am_anr)"

输出示例：

01-23 14:32:10.456   789   789 I am_anr  : [0,12345,com.example.app,13579,Input dispatching timed out (Window...)]

从中可提取PID、进程名、ANR子类型（输入dispatch超时 / 广播接收器超时 / 服务超时）。

3.3 提取CPU负载与等待锁

在trace文件中搜索锁相关关键字：

grep -E "(held by|waiting to lock|Blocked)" traces.txt
grep -A 5 "main" traces.txt | grep -E "cpu|load|lock"

重点关注主线程堆栈中 waiting to lock <0x...> 及该锁的 held by thread id，结合CPU负载（CPU usage 字段）判断是否因高负载导致锁长时间无法释放。

ANR日志采集流程

排查表：关键信息提取指引

初步定位：从采集数据中快速锚定问题

1. 在trace文件中定位主线程（线程名 main），查看其堆栈最后部的 waiting to lock 行。
2. 向上查找该锁地址所在的 held by thread，确认持有锁的线程ID和名称。
3. 检查持有锁线程的堆栈，看它是否长时间停留在Room的写操作（如 RoomDatabase 的 beginTransaction / executeInsert 方法）。
4. 结合Logcat中的 ANR in 时间戳，确认该时间段内CPU负载是否过高（通常高负载会放大锁竞争）。