断点调试与证据文件工作流

上一章看了 profiler。这一章回答：断点调试怎么连，ANR、tombstone、bugreport 这些 证据文件怎么收集、怎么读，最终如何组合成一次完整排障？

JDWP 断点依赖 debuggable 进程，适合稳定复现和观察变量；ANR、tombstone、bugreport 更 适合保存难复现现场。文件采集要记录设备、构建版本、时间、复现步骤和对应日志窗口。

断点适合复现，文件适合保留现场

常见误解	正确理解
release 包也能断点	断点调试要求 debuggable，release 应用通常不可附加
bugreport 随时抓都行	要在问题现场抓，事后抓不到内存态
tombstone 只给开发者看	线上闪退同样要收集现场文件复盘

核心结论

1. 断点调试：应用必须 debuggable，通过 adb/JDWP 附加。
2. ANR 文件：/data/anr/，记录超时类型与主线程栈。
3. tombstone：/data/tombstones/，记录 native 崩溃现场。
4. bugreport：adb bugreport 一键收集整套现场。
5. 完整工作流：复现 → 抓现场 → 读文件 → 断点/时间线复核 → 修复回归。

调试与取证工作流

逐步解释：

1. 复现：问题可复现才有现场。
2. 封存：bugreport 一次打包现场。
3. 读证据：ANR/tombstone/logcat 交叉看。
4. 复核：断点或时间线验证假设。
5. 回归：修复后回到同一场景。

常用命令

环境：开发设备或模拟器；读取 ANR/tombstone 需要 root 或开发者权限。

adb bugreport
adb shell ls /data/anr/ /data/tombstones/
adb shell cat /data/anr/anr_* | head -100
adb shell run-as <包名> ls files/
adb shell dumpsys dropbox --print | grep -iE "anr|crash"

先 bugreport 封存，再读现场文件；debuggable 应用可以 run-as 进入私有目录。 现场证据优先于猜测。

源码证据

阅读目标：确认现场文件的来源。

正文指针：ActivityManagerService.java appNotResponding()（ANR 文件）； system/core/debuggerd/（tombstone）；system/core/adb/（JDWP 转发）。

// ActivityManagerService.java（伪代码，行号以 r75 为准）
void appNotResponding(ProcessRecord app, ...) {
    // 写 ANR 文件并触发弹窗
}

这段代码证明： ANR 文件由系统在超时判定时生成；tombstone 由 debuggerd 在 native 崩溃时生成。两者都是“系统替你记的现场”。

验证与排障

环境：开发设备或模拟器。

adb shell dumpsys dropbox | tail -20
adb shell ls -lt /data/anr/

排查流程：先确认有没有 ANR/tombstone，再读文件头确认类型，最后用 logcat 与时间线 还原。文件读不出或缺失时，先检查权限与收集时机，再考虑换方法。

常见误区

1. “release 也能断点”：需要 debuggable。
2. “bugreport 事后也能补”：要在现场抓。
3. “只看一种文件就够”：ANR、tombstone、logcat 要交叉看。
4. “现场文件只有开发者能读”：线上取证同样依赖它。

延伸问题

1. JDWP 在 adb 层如何被转发与保护？
2. bugreport 包含哪些主要文件，如何快速定位？
3. 线上 ANR 统计与现场文件如何对应？
4. 如何给应用设计“自动抓现场”的崩溃上报？

源码入口

文件	关键位置	作用
ActivityManagerService.java	appNotResponding()	ANR 文件
system/core/debuggerd/	tombstone	native 现场
system/core/adb/	JDWP 转发	断点调试
DropBoxManagerService.java	事件收集	现场关联

公共路径：frameworks/base/services/core/java/com/android/server/ 与 system/core/。行号以 r75 检索为准。

将这些证据用于完整系统问题时，见 系统调试与排障。