第3章 ANR日志文件结构解析：traces.txt格式解读、CPU时间片、堆栈调用链、锁信息

3.1 现象识别：traces.txt 是什么？

当应用发生 ANR 时，系统会自动生成一份 /data/anr/traces.txt（低版本）或 /data/anr/anr_* 文件（高版本）。该文件记录了 ANR 发生时系统中所有线程的堆栈快照、CPU 使用统计、锁竞争信息等，是分析 ANR 根因的“第一现场”。

• 文件位置：通常位于 /data/anr/，可通过 adb pull /data/anr/traces.txt 导出。
• 文件内容：以“线程组”为单位，每个线程包含线程状态、CPU 时间片、调用栈、以及持有的锁/等待的锁。
• 排查入口：优先定位 "main" 线程（主线程），其状态和堆栈直接反映 ANR 直接原因。

3.2 数据采集：如何获取并理解 traces.txt 的关键字段

通过以下命令获取完整的 ANR 日志（需要在开发者模式、root 或系统级权限下执行）：

adb shell cat /data/anr/traces.txt > traces.txt
adb bugreport bugreport.zip  # 推荐全量 bugreport 包含 traces 及其他日志

一份典型的 traces.txt 片段如下（伪代码示意）：

----- pid 12345 at 2025-03-21 10:15:30 -----
Cmd line: com.example.myapp
Build fingerprint: 'google/...'
ABI: 'arm64'

"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...
  | state=S schedstat=( 123456 7890 567 ) utm=10 stm=5 core=4 HZ=100
  | stack=0x7f...
  at com.example.myapp.MainActivity.onClick(MainActivity.java:50)
  - waiting to lock <0x0b1c2d3e> (a java.lang.Object) held by thread 2
  at android.view.View.performClick(View.java:...
  ...

"AsyncTask #1" prio=5 tid=2 Runnable
  | group="main" sCount=0 dsCount=0 flags=0 obj=0x...
  | sysTid=12346 nice=0 cgrp=default sched=0/0 handle=0x...
  | state=R schedstat=( 789012 3456 234 ) utm=30 stm=10 core=2 HZ=100
  at com.example.myapp.DataLoader.loadData(DataLoader.java:20)
  - locked <0x0b1c2d3e> (a java.lang.Object)
  at com.example.myapp.DataLoader.run(DataLoader.java:15)
  ...

我们需要关注以下几个关键字段：

3.3 原因定位：通过 CPU 时间片、堆栈和锁信息推导根因

排查流程如下：

1. 定位主线程：找到 "main" 线程，查看其状态。若为 Runnable 且调用栈在框架方法（如 View.draw() 或 Choreographer），说明主线程正在执行大量 UI 操作，CPU 时间片可能被耗尽。
2. 检查 CPU 时间片：比较主线程的 schedstat 与其他线程。若主线程 utm 远小于其他活跃线程（如 10 vs 300），说明主线程被频繁抢占，或系统整体 CPU 负载高。
3. 解析堆栈调用链：主线程停滞在 waiting to lock → 标记锁地址；查找持有该锁的线程（locked <0x...>）；检查持有者线程是否在长时间执行（如 Runnable、IO 调用）。
4. 分析锁阻塞：若持有者线程是死循环、长时间同步网络请求或持锁后睡眠，则导致主线程永久阻塞。

下面是一张完整的排查路径流程图，帮助理清思路：

3.4 修复动作：针对锁竞争和 CPU 饥饿的代码示例

错误写法（持锁做耗时操作）：

// DataLoader.java
private final Object mLock = new Object();
public void loadData() {
    synchronized (mLock) {  // 持锁后做网络请求
        URL url = new URL("https://example.com/api");
        HttpURLConnection conn = (HttpURLConnection) url.openConnection();
        // ... 同步读取，耗时2秒
    }
}

修复方案：将耗时操作移出同步块，或使用异步回调/协程：

// 修复后：使用 Handler 回调主线程
public void loadData(final DataCallback callback) {
    new Thread(() -> {
        // 耗时操作不在锁内执行
        String result = fetchDataFromNetwork();
        synchronized (mLock) {
            // 仅保护共享数据更新，不做耗时操作
            mData = result;
        }
        if (callback != null) callback.onDataLoaded(mData);
    }).start();
}

针对 CPU 饥饿：检查主线程是否做了大量计算，将其移到后台线程；或使用 Choreographer 分帧处理。

3.5 复测验证：确认修复是否解决 ANR

• 复现原场景，使用 adb shell am start -W 观察启动时间；或触发原操作。
• 等待 5 秒以上，确认是否再次出现 ANR 弹窗。
• 再次获取 traces.txt，查看主线程状态是否变为 Runnable 且无 waiting to lock。
• 使用 systrace 或 Perfetto 抓取 Main Thread 调度情况，验证 utm 提升。

3.6 预防方案：代码规范与监控