📚 课程目录第3章内存泄漏检测工具

内存泄漏检测工具：LeakCanary 基本原理与实践

内存泄漏这东西，听起来玄乎，说白了就是本该被回收的对象，因为被某些不该活着的引用拽着，死活回不去。

我在做性能优化的时候，碰到过最头疼的问题就是“哪里泄漏了”。日志不报错，堆栈又乱。后来用了 LeakCanary，真香。它会直接告诉你“XX 对象泄漏了，引用链是 A→B→C→D”。今天我们就来聊聊它的原理和实战用法。

LeakCanary 到底在做什么？

你想象一下：每个 Activity 销毁时，LeakCanary 都会偷偷拍一张快照（Java Heap Dump），然后检查这个 Activity 是否还被 GC Roots 引用。如果引用还在，它就沿着引用链一路回溯，最后把整条路径展示给你。

它的核心操作就三步：监听生命周期、触发 GC 检测、生成报告。

核心机制： WeakReference + ReferenceQueue。LeakCanary 对每个 Activity 创建一个弱引用，并把这个弱引用和一个队列绑定。如果 Activity 本该被回收，弱引用会被及时放入队列；如果超时后队列里没出现这个引用，说明 Activity 仍然被强引用持有，泄漏成立。

一幅图看懂 LeakCanary 工作流

下面这张图概括了 LeakCanary 从启动到出报告的完整链路。我习惯把它贴在项目 Wiki 里，方便团队新人理解。

如何接入 LeakCanary

在项目的 build.gradle 里加一行依赖，就搞定了。嗯，就这么简单。

dependencies {
    // debugImplementation 确保只在调试包生效
    debugImplementation 'com.squareup.leakcanary:leakcanary-android:2.12'
}

如果你用的是 Android 11 及以下，通常不需要额外配置。不过 Android 12 开始增加了“可见包”限制，记得在 AndroidManifest.xml 里加上下面这个权限（纯调试用，不影响上线包）：

<!-- 仅用于 debug 构建 -->
<uses-permission android:name="android.permission.FOREGROUND_SERVICE" />

LeakCanary 2.x 会自动通过 ContentProvider 完成初始化，连 Application 里的代码都不用写。我第一次用的时候也觉得太省事了，但注意一点——它默认只在 debug 包生效。千万别把 release 包里的 LeakCanary 留下，否则会泄漏堆转储文件。

实战：我遇到的一次典型泄漏

记得有个项目，用户反馈快速切换商品详情页时经常 OOM。我用 LeakCanary 跑了一遍，结果报了一个长引用链：

对象	引用类型	说明
DetailActivity	强引用	泄漏点
ImageLoader	静态字段	持有了当前 Activity 的 Context
BitmapCache	弱引用	实际强引用被 ImageLoader 持有

我一看就明白了：ImageLoader 里用了一个静态的 Handler，Handler 隐式持有了外部 Context。代码里写了 new Handler()，但在 Handler 的消息回调里用到了 Activity 的 View。Activity 退出后，Handler 还在主线程消息队列里挂着一条延迟消息，导致 Activity 无法被回收。

解决办法很简单：把 Handler 改成静态内部类+弱引用，或者使用 ApplicationContext。修复后再次跑 LeakCanary，绿标通过。

LeakCanary 的实用配置技巧

我习惯在 Application 里做少量定制，比如调整监控的延迟时间，或者过滤掉某些 Fragment（像 BottomSheetDialogFragment 有时候本身就是短命鬼）。

LeakCanary.config = LeakCanary.config.copy(
    watchDurationMillis = 5000L,          // 默认5秒，可以调短一点加快检测
    maxStoredHeapDumps = 5,                // 最多保留5个dump文件
    retainedVisibleThreshold = 3            // 同一个泄漏出现3次才告警，减少噪音
)

另外，你可以在 Android Studio 里直接双击 LeakCanary 的通知栏进入详情页。它会展示完整的引用链，每个节点都可以点击查看源码位置。我经常用这个来“钓鱼”——点开引用链，看看是哪个第三方库的静态字段把 View 拽住了。

小技巧： 如果引用的第三方库是闭源的，直接改不了？你可以在自己的代码里用一个 Application.ActivityLifecycleCallbacks 在 onDestroy 里主动清掉第三方库的静态引用。虽然有点 hacky，但应急的时候特别好使。

避坑指南

我曾经踩过的坑： 在 Android 7.0 以下的设备上，LeakCanary 的堆转储可能会因为权限问题失败。原因是 Debug.dumpHprofData() 需要往外部存储写文件，而旧版 Android 的动态权限处理不同。解决方案：在检测到 dump 失败时，降级使用 ActivityManager.getProcessMemoryInfo() 粗略估算内存大小，虽然精度低，但至少能给出一个“疑似泄漏”的信号。

还有一个常见误区：LeakCanary 报告的内存泄漏 ≠ 无法运行。有时候泄漏的对象只是几个整型数组，不影响 UI。但量变引起质变，累计的泄漏最终会导致 GC 频繁被触发，造成卡顿甚至 ANR。所以别等到 OOM 才处理，有报告就看一下。

简单说一下原理中的关键细节

LeakCanary 的核心是利用了 Java 的 ReferenceQueue 机制。它在每个 Activity destroy 时，创建一个包含该 Activity 的 WeakReference，并关联一个 ReferenceQueue。然后它启动一个后台线程，等 5 秒后触发一次 GC，再等 5 秒再触发一次 GC（双保险），最后检查那个 WeakReference 是否已经被放入队列。如果不在队列里，说明 Activity 仍然被强引用持有。

不过，这里有个细节：LeakCanary 并不会在发现一次泄漏后就立刻 dump 堆。它会先记录一个“怀疑泄漏”的标记，然后等 Activity 再次 destroy 时如果又检测到同一个类泄漏，才会触发堆转储。这样能有效避免误报（比如 Activity 被系统因为配置更改销毁后重建，中间短暂存活是正常的）。

我个人觉得这个设计非常聪明。你想想看，如果一个人刚关了页面，系统还没及时回收就报泄漏，用户会觉得「我明明退出了啊」。两次确认能过滤掉大量假阳。

总结 LeakCanary 的正确用法

不要在生产包留 LeakCanary —— 用 debugImplementation 隔离。
结合 Profiler 使用 —— LeakCanary 负责定位，Android Studio Profiler 负责看整体内存曲线。
定期跑一轮 —— 我每周跑一次 LeakCanary 全量检测（把常用页面都走一遍），效果比上线后堆满 crash 强多了。
重点留意静态集合类 —— 比如 static List<Activity>、static HashMap 等，这些是泄漏重灾区。

最后说一句：LeakCanary 是工具，不是万能药。有些泄漏是框架层面或者系统底层的（比如某些厂商 ROM 的 SurfaceFlinger 泄漏），它可能检测不到。但 80% 的普通泄漏 LeakCanary 都能一抓一个准。所以，装上它，跑起来，看到红字就修，你的应用内存情况会好得多。