parsing-android-anr-expert

Android ANR 深度解析（通用核心 + Thunder 适配）

核心原则

• 结论必须基于证据链：内核等待态 -> 线程栈 -> 业务帧/系统交互。
• 不能仅凭单一关键词下结论（例如看到 epoll_wait 就判死锁）。
• 输出时必须给出“置信度”和“不足证据说明”。
• 首要异常点优先：整份结论必须以「证据等级最高、且与 ANR 类型/主线程最相关」的那一条作为第一节焦点；禁止把低置信猜测放在最前面。

仓库联动（在 Cursor 工程内分析时的强约束）

当用户把 ANR 放在当前可访问的工作区/仓库中分析时，凡栈里出现可定位符号（例如 com.thunder.*、com.xxx 业务类、本仓库模块路径），必须：

1. 先在本仓库内自行检索：用文件名/类名 grep、语义搜索、按包路径浏览，定位对应类与方法，再对照栈判断是否存在主线程阻塞、同步 I/O、过大锁域等问题。
2. 禁止默认让用户「贴类源码」：只有在满足下列任一条件时，才可请用户补充材料，且须写明「已在仓库内检索未果」：
   • 符号被混淆/裁剪，仓库内无匹配；
   • 栈帧落在闭源三方 SDK（仅有 aar，无 Java/Kotlin 源码）；
   • 栈中只有 native 符号且无映射表，无法对应业务模块。
3. 用户口头指定也要验证：即使用户说「去看某某类」，仍应先打开/搜索仓库确认实现，再结合 trace 判断，避免复述用户猜测。

不在仓库场景（仅有纯文本 trace、无代码）时：只做 trace 级结论，并明确「无法做代码侧验证」。

输入契约（先判定再分析）

最小可分析输入（满足其一）

1. ----- pid N at ... + Cmd line: ... + 至少一段线程栈；或
2. DALVIK THREADS + "main" 线程块；或
3. Waiting Channels + 可匹配到同 pid 的线程信息。

可选增强输入

• Subject: / Reason: / ANR in
• Load: / CPU usage from ...
• Binder transaction 或 lock 文本（waiting to lock / held by tid）
• Perfetto 系统 trace（.perfetto-trace）：与栈文本 互补（调度、log、时间线）；采集流程见本仓库 android-perfetto-capture（含 ANR 不定时 的长看守配置）；本 skill 仍以 bugreport / traces.txt 栈与锁链 为主证据。

降级策略

• 缺 Reason/CPU：允许分析，但必须在结论中标注“仅基于 stack 证据”。
• 缺主线程块：只输出候选根因，不输出确定性根因。
• 无法完成 pid 对齐：先输出“输入不足”，列出需补充字段。

通用分析流程（必须按顺序）

1. 锁定目标进程

   • 先从 ANR in/Subject/Reason（若存在）找目标包名或 pid。
   • 再用 ----- pid N at 与 Cmd line 交叉确认，避免误把 system_server 当主因进程。

2. 定位主线程与状态

   • 在目标 pid 范围内找 "main" 或主线程对应 sysTid。
   • 提取状态：Runnable / Native / Blocked / Waiting。
   • 记录栈顶 5~15 帧中的关键调用路径（框架层 + 业务层）。

3. 建立阻塞链

   • 锁链：waiting to lock <obj> -> held by tid -> 持锁线程栈。
   • Binder 链：binder_thread_read / IPCThreadState -> 对端进程/服务线程。
   • I/O 链：read/write/open/ioctl + JNI/业务方法，判断是否在主线程路径。

4. 环境压力校验

   • 若有 Load/CPU usage，区分“系统级算力饥饿”与“业务线程阻塞”。
   • 无 CPU 段时，不得给出“CPU 饱和”确定结论。

5. 根因归类

   • Input：输入分发/绘制/主线程消息循环路径被阻塞。
   • Broadcast/Service：ActivityThread 的 receiver/service 处理超时路径。
   • Watchdog：系统关键线程长时间无响应（常见于系统进程）。
   • 类型判断若证据不足，输出 Unknown(证据不足)。