泄漏检测工具选择：Android Profiler、LeakCanary、MAT、hprof分析器的适用场景

2.1 现象识别：从“泄漏感知”到“工具筛选”

当应用频繁 OOM、内存曲线持续上升或出现 OutOfMemoryError 时，工程师首先要回答：该用哪个工具挖掘根因？不同工具在开发阶段、集成测试、线上监控中的角色差异巨大。本章围绕以下判断维度帮助你在排查链路中快速锁定正确工具：

• 时机：开发调试 / 持续集成 / 线上灰度
• 颗粒度：对象引用链 / 整体堆概况 / 泄漏率统计
• 侵入性：是否需要代码插装 / 是否需要 Root 权限

2.2 数据采集：工具的核心能力与采集方式

每种工具在数据采集阶段产出不同类型的快照或日志。

2.3 原因定位：各工具的引用链分析能力

泄漏根因定位的核心是从 GC Root 到泄漏对象的最短引用路径。以下是各工具在该步骤的差异：

• Android Profiler：在 Memory 面板选中对象后，展开“Instance View”可查看引用链，但大型堆下响应缓慢，不适合深层嵌套的匿名内部类泄漏。
• LeakCanary：直接输出“Leak Trace”，自动跳转到可疑对象并显示引用链代码行号，对 Activity / Fragment 泄漏识别极其精准。
• MAT：提供“Leak Suspects”报告、“Path To GC Roots”以及“OQL”（对象查询语言），适合分析单例缓存、静态集合、线程死锁等复杂泄漏。
• hprof 分析器：作为底层文件，可被 MAT、VisualVM、JProfiler 等加载，也可通过自定义脚本提取哈希值按类型归并。

2.4 修复动作：工具如何辅助修复

定位到引用链后，不同工具提供的“修复指引”粒度不同：

// 以 LeakCanary 输出为例，典型修复动作是断开静态引用
// 泄漏摘要：
// ──────────────────────────────────
// GC Root: System Class
// ├─ com.example.cache.ImageCache
// │    └─ static mCache (HashMap)
// │         └─ key="photo_123"
// │              └─ value (Bitmap)
// │                   └─ mActivity (Activity)
// └─ Leaked: MainActivity
//
// 修复：ImageCache 中的 mActivity 改为 WeakReference<Activity>

2.5 复测：用工具验证修复是否生效

• LeakCanary：修复后重新运行相同操作，若不再弹出通知则通过。
• Android Profiler：手动执行 GC 并 dump 快照，检查目标 Activity 数量是否为 0。
• MAT：再次 dump 并运行相同 OQL 查询（如 select * from instanceof android.app.Activity），待查对象数量归零。
• hprof 分析器：使用脚本对比修复前后堆快照中对应类的实例数。

2.6 预防：将工具嵌入交付流程

选择工具后还需建立持续预防机制：

• 在 CI/CD 中集成 LeakCanary 的 LeakAssert，当测试中产生泄漏时使构建失败。
• 使用 Android Profiler 的 .hprof 导出脚本定期对关键功能走查。
• 将 MAT 的 OQL 脚本存入 CI 工具的自定义检查阶段。
• 线上环境通过 hprof 分析器 结合 failure.leakcanary.googlesource.com 等方案采集用户侧堆转储。