4. 日志系统与诊断数据源

Android 的稳定性诊断本质上是一场“证据链重建”。崩溃、重启、ANR、Native 异常往往发生在毫秒级，现场无法复现，唯一能依赖的就是系统在事发前后留下的各类日志与转储。理解每个数据源的产生位置、覆盖范围、持久化能力和时效边界，才能在排障时快速锁定正确的“第一现场”，而不是在几十万行日志里盲目搜索。

一、核心原理：数据源的分层与生命周期

Android 日志体系可以按“产生层—缓冲层—持久层”来理解。产生层包括用户态进程、Native 库、内核、Bootloader；缓冲层是 logd、kmsg、pstore 等内存或硬件保留区；持久层则是 dropbox、tombstone 文件、bugreport 压缩包等落盘产物。关键区别在于：内存缓冲会随进程重启或设备重启丢失，而持久层能跨越重启保留证据。因此诊断重启类问题必须优先看 pstore/ramoops 与 dropbox，诊断运行时崩溃则先看 logcat 与 tombstone。

二、各数据源定位与关键命令

不同数据源解决不同问题，混用会导致效率低下。下表给出常用数据源的核心特征与采集方式：

三、方法流程：从现象到证据的排查路径

面对“设备重启”或“应用闪退”，建议按以下顺序推进，避免遗漏关键证据：

1. 先判断是否跨重启：若设备重启，优先读取 pstore/ramoops 与 dropbox 中的 SYSTEM_RESTART、SYSTEM_LAST_KMSG 条目。
2. 再定位崩溃类型：Java 崩溃看 logcat 的 FATAL EXCEPTION；Native 崩溃看 tombstone 的 signal 与 backtrace；ANR 看 /data/anr 的 traces 文件。
3. 关联时间线：用 bugreport 中的 events log 与 system log 对齐时间戳，确认崩溃前是否有 OOM、Watchdog、Binder 超时。
4. 固化证据：将 tombstone、ANR trace、dropbox 条目与 bugreport 一并归档，避免设备再次重启后丢失。

# 典型采集组合
adb logcat -b all -d > logcat_all.txt
adb shell dmesg > dmesg.txt
adb shell dumpsys dropbox --print > dropbox.txt
adb pull /data/tombstones ./tombstones
adb pull /data/anr ./anr
adb shell ls -l /sys/fs/pstore
adb bugreport bugreport.zip

四、案例与场景：一次重启问题的证据链

某设备在待机时偶发重启。排查时先看 logcat，发现重启前无 FATAL，说明不是应用崩溃；接着读取 pstore，发现 console-ramoops-0 中存在 Kernel panic - not syncing: Watchdog detected hard LOCKUP，定位到某驱动在中断上下文中长时间持锁。再结合 dmesg 中该驱动的中断风暴记录，确认根因。若当时只抓了 logcat，就会完全错过内核侧证据。

五、误区与复盘

• 只看 logcat：logcat 不包含内核 panic 与 Native 信号细节，重启类问题必须结合 pstore 与 tombstone。
• 忽略时间基准：logcat 使用 uptime，dmesg 使用 monotonic，dropbox 可能带 RTC 时间，未对齐时间戳会导致因果误判。
• 缓冲区覆盖：logd 与 kmsg 都是环形缓冲，高频率日志会冲掉旧记录，复现问题后应第一时间抓取。
• tombstone 权限：部分版本 /data/tombstones 需要 root 或 userdebug 才能读取，user 版本应通过 dropbox 或 bugreport 获取。
• bugreport 过大：bugreport 包含大量冗余信息，建议先解压查看 bugreport-*.txt 中的 VM TRACES、SYSTEM LOG、EVENT LOG 段落，再决定深入方向。