当前位置：首页 > news >正文

【稳定性】system_app_anr@1760693457221.txt和anr_2025-10-17-17-30-35-009有什么区别

news 2025/11/13 8:08:05

我明白你现在的疑问，其实你遇到的是 同一次 ANR 事件，系统生成了两份日志文件 的情况。这在 Android 系统里是正常的，并不是重复抓错，而是两种不同“来源/用途”的 ANR记录。下面我拆开解释一下：

1. 两个文件的区别

① system_app_anr@1760693457221.txt

来源：通常是 system_server 里的 ActivityManagerService (AMS) 在处理 ANR 时主动输出的分析文件。
内容：会包含：
- ANR原因（Input dispatching timed out 等）
- 目标进程信息（PID, UID,包名）
- /proc/pressure/* 等系统运行压力信息
- CPU使用情况（短时间采样）
- 目标进程的线程堆栈（尤其是主线程）
- 某些额外的 dump（比如 logcat 部分）
作用：更贴近 系统框架分析视角，也就是 system_server 自己记录“为什么它判定这个进程 ANR”。

你贴的第一段长长的日志就是这一类文件的内容。

② anr_YYYY-MM-DD-HH-MM-SS-SSS

来源：由 tombstone/ANR 机制生成（类似崩溃时的 tombstone），通常由 debuggerd 或 system_server dump机制 统一产出。
内容：
- 面向开发调试的进程级 dump
- 更完整的进程内所有线程堆栈（不仅主线程）
- 内存映射、寄存器状态、锁持有情况
- 这部分是系统把目标进程的现场“冻”下来，方便开发者单独分析。

这种文件的名字模式是：

anr_YYYY-MM-DD-HH-MM-SS-SSS

表示发生时间。它会保存在 /data/anr/ 目录或 OEM 的 ANR 日志目录。

2. 为什么一次 ANR 会有两份日志

在 Android 里，ANR 检测和日志生成是两个不同的逻辑模块：

检测判定：ActivityManagerService 在 system_server 中维护一些超时监控，比如：
- 输入事件（InputDispatcher）
- 前台广播
- Service 执行
  如果超时，就判定为 ANR，并打印一份 system_app_anr@timestamp.txt。
现场抓取：在判定 ANR 后，AMS 会调用 appNotResponding() 逻辑去抓目标进程的详细现场，这一步会调用 dumpStackTraces()，可能直接触发 debuggerd。
- debuggerd 会对该进程进行全量 native & java 堆栈采集，并生成 anr_YYYY-MM-DD-xxx 这样的文件。

🔹 所以：

system_app_anr@ → 框架层报告，带系统状态分析。
anr_2025-10-17-… → debug/tombstone层的进程级全量 dump。

它们是一前一后产生的，但针对同一次事件。

3. 谁在触发两份日志的生成

通常流程如下：

ActivityManagerService (system_server)↓
检测到ANR超时↓
写 system_app_anr@timestamp.txt （自己分析）↓
调用 dumpStackTraces()↓
触发 debuggerd 抓目标进程堆栈↓
写 anr_YYYY-MM-DD-HH-MM-SS-SSS

或者在某些 OEM（比如 TCL、华为、小米）里，会有额外的 ANR 收集服务 hook 在 appNotResponding() 中，同时输出一个厂商定制格式的 ANR 日志，用来上传到异常分析平台（如 Bugly、iManager、HiCrash），所以就自然是多份文件。