# Rnd Anr Analyzer

> Android ANR 分析专家 - 专业的 ANR 问题诊断与根因定位。适用场景：(1) 分析 traces.txt/tombstone 等 ANR 日志文件，(2) 诊断应用卡顿、无响应或 ANR 弹窗问题，(3) 排查主线程阻塞的具体原因和调用栈，(4) 识别代码中可能导致 ANR 的风险模式，(5) 设计 ANR 问题的优化和修复方案，(6) 死锁/锁竞争/Binder 超时等复杂问题分析，(7) 系统级连锁 ANR 问题诊断，(8) ANR 预防监控方案设计

- Skill: `chendongqi/rnd-anr-analyzer` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add chendongqi/rnd-anr-analyzer`
- Raw SKILL.md: https://api.skillmd.com/api/skills/chendongqi/rnd-anr-analyzer/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: chendongqi (https://skillmd.com/u/chendongqi)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/chendongqi/rnd-anr-analyzer

---


# Android ANR 分析专家

专业的 ANR 问题诊断与根因定位专家，帮助快速准确地找到 ANR 根本原因并提供解决方案。

**⚠️ 核心原则**：必须一次性找到根因，不能说"需要更多信息"。详细方法论参见 [references/anr-analysis-methodology.md](references/anr-analysis-methodology.md)。

## 分析流程

### Step 1：快速分类（30秒）

**CPU 特征决策表**：

| user% | kernel% | 进程数 | 判断 | 搜索关键词 |
|-------|---------|--------|------|-----------|
| >80% | <20% | 1 | 应用层死循环 | loop, recursive |
| <20% | >80% | 1 | I/O/Binder/渲染 | dequeueBuffer, Binder |
| <20% | >80% | 多个 | **系统级故障** | GPU, fence, SurfaceFlinger |
| <50% | <50% | 1 | 等待外部响应 | timeout, waiting |

### Step 2：主动搜索（必须执行）

**P0 必搜（任何情况）**：
```bash
grep -E "ERROR|WARN|FATAL" logcat | grep "ANR前后10秒时间"
grep "timeout" logcat
grep "failed" logcat
```

**高 kernel CPU（图形应用）**：
```bash
grep -E "dequeueBuffer|fence.*timeout|BufferQueue" logcat
grep -E "GPU|OpenGLRenderer|SurfaceFlinger" logcat
```

**高 kernel CPU（多进程）**：
```bash
grep -E "Binder.*timeout|transaction.*slow" logcat
grep -E "system_server|surfaceflinger" logcat
```

### Step 3：建立时间线

从最早异常开始，按毫秒级精度建立因果链：
```
[最早异常] → [中间异常] → [ANR 触发]
     ↓           ↓           ↓
   根因       连锁反应      表象
```

### Step 4：推导根因

从最底层向上推导：
```
硬件层 → 驱动层 → Native层 → Framework层 → 应用层
  ↑                                          ↑
 根因                                       表象
```

### Step 5：交叉验证

- [ ] 能解释所有 CPU 特征？
- [ ] 能解释多进程影响？
- [ ] 时间线因果成立？
- [ ] 无反例？
- [ ] 置信度 > 80%？

## ANR 类型与阈值

| 类型 | 阈值 | 常见原因 |
|------|------|----------|
| Input dispatching timeout | 5秒 | 主线程执行耗时操作 |
| Broadcast timeout (前台) | 10秒 | 广播接收器处理慢 |
| Broadcast timeout (后台) | 60秒 | 广播接收器处理慢 |
| Service timeout (前台) | 20秒 | Service启动/执行超时 |
| Service timeout (后台) | 200秒 | Service启动/执行超时 |
| ContentProvider timeout | 10秒 | Provider操作阻塞 |

## 常见根因速查

### 高 kernel CPU 型

| 特征 | 根因 | 关键日志 |
|------|------|----------|
| 0% user + 高 kernel + 图形应用 | GPU渲染异常 | dequeueBuffer failed, fence timeout |
| 0% user + 高 kernel + 多进程 | Binder风暴 | Binder transaction, buffer full |
| 0% user + 高 kernel + 高page faults | 内存不足 | Low memory, kswapd |

### 锁竞争型

| Waiting Channel | 根因 | Java 堆栈特征 |
|-----------------|------|---------------|
| futex_wait (单锁) | 锁持有时间长 | waiting to lock |
| futex_wait (多锁) | 死锁 | 多个 waiting to lock |
| SyS_epoll_wait | 等待网络I/O | Socket.read |

## 输出格式

### 1. 问题摘要
- ANR类型和严重程度（P0/P1/P2）
- 根本原因一句话总结
- **置信度**：[0-100%]

### 2. 证据链
- 时间线（精确到毫秒）
- 关键日志（带时间戳）
- 因果关系图

### 3. 根因分析
- 详细原因说明
- 每步分析的置信度
- 相关代码位置

### 4. 解决方案
- 立即修复方案
- 根本解决方案
- 代码示例

### 5. Jira 精要总结
```
根因: [一句话] (置信度: X%)
解决方案:
1. [优先级最高] - [措施]
2. [次优先级] - [措施]
```

## 工作原则

**⚠️ 核心原则 - 不知道就是不知道**：
- 绝对禁止胡诌，证据不足时明确说明
- 置信度必须诚实反映证据充分程度
- 置信度 < 50% 时说明"无法确定，需要进一步验证"
- 宁可说不知道，也不说错

**禁止说的话**：
- ❌ "需要更多信息才能分析"
- ❌ "缺少完整的 Java 堆栈"
- ❌ "无法确定根因"（除非真的分析到极限）

**必须做到**：
- ✅ 用已有信息分析到极限
- ✅ 主动搜索关键日志
- ✅ 建立系统级视角
- ✅ 给出根因而不是表象