4. traces.txt 文件结构深度解读

当 ANR 发生时，Android 系统会生成一份 traces.txt 文件，这是排查 ANR 的“第一现场”。本章将从文件结构、时间戳、线程状态、锁信息、CPU 时间片和关键线程标记六个维度，系统拆解 traces.txt 的解读方法。

现象识别：App 卡死后抓取的 traces.txt 体积可能从几十 KB 到数 MB 不等。若原始文件超过 5 MB，往往是大量线程堆积或同一线程反复 dump 造成，此时需要优先关注 main 线程和 Binder 线程。

4.1 文件整体结构

一份标准的 traces.txt 由三部分组成：

区域 内容 排查优先级
文件头 ANR 触发时间、进程名、pid、系统负载摘要 高
线程栈主体 按线程组排列的调用栈，每组以 ----- pid xxx at yyy ----- 开头 最高
全局信息 内存堆摘要、FD 泄露情况、全局锁等待队列 中
避坑：不要跳过文件头直接看线程栈。文件头中的“CPU 总使用率”和“进程 CPU 时间”常能揭示系统侧还是应用侧的瓶颈。

4.2 时间戳与线程状态

每个线程栈的第一行包含关键时间戳和状态标记：

Thread[“main”,5,main] tid=1  Native
  at com.example.MyActivity.onCreate(Native Method)
  at android.app.Activity.performCreate(Activity.java:8054)
  ... (7 more calls)
  “main” prio=5 tid=1  Blocked
  at com.example.MyTask.run(MyTask.java:45)
  - waiting to lock <0x0bba5e60> (a java.lang.Object)
  at java.lang.Thread.run(Thread.java:920)

状态字段对照速查：

状态 含义 常见原因
Native 线程正在执行 JNI 调用或系统调用 Binder 驱动、文件 I/O、sleep 在底层
Blocked 线程等待锁释放 死锁、锁竞争、同步方法卡顿
Waiting 线程处于无限期等待（如 wait()） notify() 未调用、Condition 超时
TimedWaiting 线程处于有限期等待（如 sleep(ms)） 超时时间过长、定时任务堵塞
Runnable 线程正在运行或等待 CPU CPU 密集型任务、GC 频繁
判断规则：main 线程长期处于 Blocked 或 Waiting 时，优先级最高；若 main 线程为 Runnable 但 CPU 时间片极短，则需检查 CPU 调度（4.4 节）。

4.3 锁信息与 Monitor

traces.txt 中的锁信息通常以缩进方式出现在调用栈下方：

at com.example.api.DataFetcher.fetch(DataFetcher.java:88)
  - waiting to lock <0x0f8c1234> (a java.lang.Object)
  at com.example.api.DataFetcher.run(DataFetcher.java:132)
  - locked <0x0f8c1234> (a java.lang.Object)

锁块解读要点：

  • waiting to lock：当前线程正在等待锁释放，锁地址唯一
  • locked：当前线程已持有该锁
  • waiting on <0x...>：线程调用了 wait()，正在等待其他线程调用 notify()

锁冲突排查表：

锁场景 栈特征 根因示例
两锁交叉等 Thread-A 锁 X 等 Y；Thread-B 锁 Y 等 X 经典死锁
单个锁被长时间持有 Thread-A locked 后卡在 IO 或 sleep；Thread-B 等同一锁 锁住的大文件写操作
Monitor 等待超时 waiting on <0x...> 且状态为 TimedWaiting 条件变量未及时通知

4.4 CPU 时间片

文件头的 CPU 统计信息是判断系统侧问题还是应用侧问题的核心依据：

CPU usage: 85% total, 30% user, 55% kernel
  foreground: com.example.myapp (pid=12345): 12% user + 3% kernel = 15% total
  background: system_server (pid=789): 5% user + 10% kernel = 15% total

解读规则：

  • 应用 CPU 占比低（< 10%）且 main 线程阻塞：大概率是锁等资源，非 CPU 瓶颈
  • 应用 CPU 占比高（> 30%）且 main 线程 Runnable：CPU 饥饿，检查循环/频繁 GC
  • kernel 占比 > user 占比：可能是 I/O 等待（磁盘、Binder）、内存回收或驱动问题
实战技巧：若 traces.txt 文件头包含“Load average: 6.5 4.2 3.1”，且 num_cpus=8，说明系统负载较高。此时即使应用 CPU 正常，ANR 也可能是系统调度延迟导致。

4.5 关键线程标记

traces.txt 中常见四类关键线程，每种都有自己的排查优先级：

线程名/标记 作用 排查优先级
main UI 线程，处理布局绘制和用户交互 最高
Binder:xxx_1 进程间通信线程，承载跨进程调用 高
FinalizerDaemon Java 对象终结线程，执行 finalize() 中
ReferenceQueueDaemon 引用队列清理线程 低
HeapTaskDaemon GC 后台任务（ART 环境） 高

排查原则：

  • main 线程阻塞或卡住 => 直接定位到 ANR 发生栈
  • Binder 线程集中等待 => 检查对端服务是否超时或死锁
  • FinalizerDaemon 堆积 => 大量未释放的 JNI 对象或文件描述符
  • HeapTaskDaemon 长时间运行 => 频繁 GC，内存压力大
traces.txt 解读故障排查流程图 接收 traces.txt 解析文件结构 检查时间戳与线程状态 分析锁信息 / Monitor 分析 CPU 时间片 识别关键线程标记 定位 ANR 根因 ① main 线程状态优先 ② 锁地址跨线程交叉验证 ③ CPU 总使用率 > 80% 时查系统负载 ④ 同时存在多个等待锁时查死锁

4.6 实战排查步骤

  1. 定位 main 线程：搜索 "main" prio=，记录其状态和锁等待信息
  2. 检查 Binder 线程：搜索 Binder:，确认是否有线程阻塞在 waiting to lock
  3. 计算锁等待链：将 locked <0x...> 和 waiting to lock <0x...> 的地址两两对照，画出锁依赖图
  4. 读取 CPU 统计：文件头中的应用与系统 CPU 占比，判断瓶颈域
  5. 扫描 Finalizer 和 HeapTask：若线程数异常增多，检查 GC 频率和对象引用
复测建议：在修复后，使用 adb shell dumpsys activity processes | grep "app" 触发一次模拟 dump，对比修复前后 traces.txt 中 main 线程的调用栈深度和锁等待次数。若 main 线程栈长度减少 30% 以上，说明优化有效。

4.7 预防措施

  • 在关键锁区域内添加 systrace 标签，便于可视化锁竞争
  • 对 Binder 调用设置超时（默认 1s），防止无限等待
  • 定期监控 /proc/[pid]/sched 中“nr_involuntary_switches”指标，间接检测线程抢占
  • 在 CI 流程中集成 traces.txt 自动解析脚本，输出锁等待图
← 上一章 📖 返回目录 下一章 →