LeakCanary 入门：零基础跑通第一个内存泄漏检测示例

简介：这是一份面向Android开发者的LeakCanary入门实践资料，聚焦内存泄漏检测这一性能优化关键环节。相比Android Profiler、MAT等PC端工具，LeakCanary可直接在手机端运行，帮助开发者在真机上快速定位泄漏对象与引用链，适合刚接触内存优化、需要动手验证的中初级开发者。压缩包共54个文件，约596KB，以png截图、xml配置、java源码及gradle构建脚本为主，另含properties、lock等工程配置与jar依赖，完整呈现一个可运行的Demo工程结构。资源已有1918人学习下载，说明其在入门场景中具备一定参考价值。读者可借助其中的示例代码与工程配置，理解LeakCanary的接入方式、依赖引入与基本使用流程，并对照截图观察泄漏提示信息，为后续排查真实项目中的内存问题积累直观经验。

1. 从一次手机变卡说起：LeakCanary 到底是什么

你有没有遇到过这种情况：刚打开某个 App 时还挺流畅，来回切几个页面、点几轮按钮之后，手机开始发烫、滑动变卡，最后干脆闪退。很多人第一反应是“手机老了”“内存不够”，但真相往往藏在代码里——某个本该被回收的对象，被别的东西一直拽着不放，内存越占越多，这就是内存泄漏。LeakCanary 就是专门帮你抓这种“赖着不走”的对象的一个 Android 开发工具，它会在应用运行时自动盯着内存，一旦怀疑有对象泄漏，就弹出通知告诉你：谁泄漏了、是谁拽着它不放。对刚入门 Android 开发、还没搞懂内存分析工具的新手来说，它最大的价值是“不用学一堆命令，装上就能看到结果”，把原本玄学一样的内存问题，变成一条能看懂的通知。这篇就带零基础的你，从“它是什么”一路走到“第一个例子跑起来”。

2. 为什么新手也该早点用上它：先建立内存直觉

很多新手觉得内存泄漏是“高级话题”，等项目大了再说。可现实是，泄漏往往就是新手期埋下的：Activity 里写了个匿名内部类、静态变量顺手存了个 Context、监听器注册了忘了注销。这些问题在测试机上可能一时看不出来，等用户反馈“用久了就卡”，排查成本已经翻了好几倍。LeakCanary 的好处是它把“看不见的内存”变成“看得见的通知”，让你在写代码的当下就能建立直觉：哦，原来这样写会泄漏。这一章先讲清楚它为什么值得学、它在背后替你做了什么，再讲怎么把它接进项目。

2.1 它到底在替你做什么：一个“内存保安”的类比

你可以把 App 的内存想象成一间办公室，对象就是办公室里的人。正常情况下，一个人下班了（不再被使用），工位就该腾出来给下一个人。内存泄漏就是：某人已经下班了，但有人还攥着他的工牌不撒手，导致工位一直空占着。LeakCanary 干的事，就是定期巡查：发现某个“已经该走的人”过了好久工位还没腾出来，就顺着“谁还攥着工牌”这条线一路查下去，最后给你一份报告——是谁、通过什么引用链，把那个对象留住了。

它在技术上依赖的是 Android 里一个叫ObjectWatcher的机制：对某个本该被回收的对象做一次“弱引用”观察，过一段时间触发 GC 后再看这个弱引用还在不在。如果还在，说明对象没被回收，就判定为“疑似泄漏”，然后 dump 堆内存、分析引用链，最终生成一条可读的泄漏轨迹。你不需要懂这些细节也能用，但知道它在“观察 + 分析”这两步上干活，后面看报告时就不会一头雾水。

2.2 为什么它比“凭感觉优化”靠谱

新手优化内存最常见的做法是“感觉这里可能有问题，改改试试”，改完也不知道有没有效果。LeakCanary 把这件事变成了可验证的闭环：改之前它报泄漏，改之后通知消失，你就知道改对了。这种“有反馈”的学习方式，对建立正确的编码习惯特别重要。我第一次用的时候，就是靠它发现自己在一个静态工具类里存了 Activity 的引用，当时完全没意识到那是个坑。

另外它几乎零配置，接入成本低到可以“先装上再说”。对零基础的人来说，最怕的是工具还没用起来就先被配置劝退，而 LeakCanary 恰好属于“加几行依赖就能跑”的那一类，非常适合作为你接触内存问题的第一个工具。

2.3 它适合谁、不适合谁

适合的人群很明确：正在学 Android、能跑起一个简单 App 的新手；项目里已经出现“用久了变卡”但不知道从哪查的开发者；想养成良好内存习惯、但不想一上来就啃复杂分析工具的人。它不适合的场景也要说清楚：如果你要做的是深度的内存占用统计、或者需要精确到字节的堆分析，那得配合更专业的工具一起看；LeakCanary 的定位是“发现泄漏并指出引用链”，不是万能的性能分析平台。入门阶段先用它建立感觉，后面再扩展工具箱，这个顺序是对的。

3. 第一个例子怎么跑：从加依赖到看见第一条通知

这一章是整篇最需要你动手的部分。下面按“建项目 → 加依赖 → 触发一次泄漏 → 看通知”的顺序走，每一步都给出可复制的代码和解释。你不需要提前懂内存分析，跟着做就行。入门的话建议先用一个空白的 Android 项目练手，别直接往正式项目里塞，避免干扰。

3.1 准备一个能跑的最小项目

先确认你有一个能正常编译运行的 Android 项目，语言用 Kotlin 或 Java 都行，本文示例用 Kotlin。项目里至少要有一个 Activity，能点按钮跳转或关闭。如果你还没有，就在开发工具里新建一个 Empty Activity 模板项目，包名随意，能跑起来即可。这一步的目的是保证后面加的依赖和代码有地方落，不至于卡在环境上。

3.2 加依赖：两行代码的事

在模块级（通常是app目录下）的build.gradle或build.gradle.kts里加依赖。以 Kotlin DSL 为例：

// app/build.gradle.kts dependencies { // 只在 debug 版本引入，release 包不会带上，避免影响线上 debugImplementation("com.squareup.leakcanary:leakcanary-android:2.14") }

这段的意思是：只在调试（debug）构建里引入 LeakCanary，正式发布（release）的包里不会包含它。这样做有两个好处，一是线上包体积不受影响，二是避免把调试工具带到用户手机上。版本号写你项目能拉到的稳定版本即可，如果拉取失败，先检查仓库配置和网络，别急着怀疑代码。加完依赖后同步一次项目，让构建系统把库下载下来。

提示：如果你用的是 Groovy 版的build.gradle，写法是debugImplementation 'com.squareup.leakcanary:leakcanary-android:2.14'，含义完全一样。

3.3 触发一次“故意”的泄漏

依赖加好后，LeakCanary 会自动初始化，你不需要写任何启动代码。接下来我们故意制造一个泄漏，看看它会不会报。新建一个 Activity，在它里面用一个静态变量把this存起来：

class LeakActivity : AppCompatActivity() { override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) // 故意把当前 Activity 存进静态变量，模拟“忘了释放”的泄漏 leakedActivity = this } companion object { // 静态引用会一直持有 Activity，导致它无法被回收 var leakedActivity: Activity? = null } }

这里的companion object里的静态变量会一直活着，它拽着LeakActivity的实例不放。当你关闭这个页面时，系统本该回收它，但因为静态变量还指着它，回收不了——这就是一次标准的泄漏。运行 App，打开这个页面，然后按返回键关掉它，回到上一个页面。接下来等几秒，让 LeakCanary 完成观察和 GC 触发。

3.4 看通知：第一条泄漏报告长什么样

如果一切正常，几秒到十几秒后，通知栏会出现一条 LeakCanary 的通知，点开能看到泄漏详情：哪个类泄漏了、引用链是怎样的。你会看到类似“LeakActivity is leaking”这样的结论，下面列出从 GC Root 到泄漏对象的引用路径，其中就能看到你写的那个静态变量。第一次看到这条通知，很多人会有点懵，其实只要抓住两点：第一行告诉你“谁泄漏了”，下面的链条告诉你“谁拽着它”。顺着链条找到你自己写的那行代码，问题就定位了。

如果没看到通知，先别慌，按顺序检查：依赖是否加在 debug 构建里、App 是否是 debug 包、有没有给通知权限、关闭页面后是否等了足够时间。这些是新手最常卡住的地方，下一章会专门展开。

3.5 修掉它，再验证一次

把静态变量那行删掉，或者改成在onDestroy里置空：

override fun onDestroy() { super.onDestroy() // 页面销毁时解除静态引用，泄漏随之消失 leakedActivity = null }

重新运行，重复“打开页面 → 关闭 → 等待”的流程，这次通知不再出现，说明泄漏被修掉了。这个“制造 → 观察 → 修复 → 验证”的循环，就是 LeakCanary 最核心的使用方式，后面你遇到真实泄漏，走的也是同一条路。

4. 看懂报告与常见坑：新手最容易翻车的地方

能跑通第一个例子只是开始，真正让你少走弯路的是“看得懂报告”和“知道哪些坑别踩”。这一章先讲报告怎么读，再把新手高频翻车的几个点按“现象 → 原因 → 解决”拆开讲。血泪经验是：大部分“LeakCanary 没反应”的情况，都不是工具坏了，而是使用姿势不对。

4.1 报告里的三条关键信息

一条泄漏报告信息量不小，但入门阶段你只需要盯住三处。第一处是泄漏对象的类型和名字，它告诉你“谁没被回收”；第二处是引用链，从 GC Root 一路到泄漏对象，中间每一环都是一个引用，你要找的是其中“本不该存在”的那一环，通常就是你自己写的静态变量、单例、监听器；第三处是“Leaking: YES/NO”这类判定，它帮你确认这到底是不是真泄漏。把这三处看明白，80% 的常见泄漏你都能自己定位。

读链条时有个小技巧：从下往上看，先看离泄漏对象最近的那一环，往往就是“直接凶手”；如果那一环是系统类，再往上找你自己代码出现的位置。别一上来就从最顶上逐行读，容易看花眼。

4.2 常见问题一：装了却一直不弹通知

现象是依赖加了、App 也跑了，但怎么都不见通知。原因通常有三类：依赖加在了 release 配置里而跑的是 debug 包、App 没有通知权限、或者对象其实没泄漏只是你等的时间不够。解决办法是逐项核对：确认用的是debugImplementation、确认当前运行的是 debug 变体、到系统设置里给 App 打开通知权限，然后关闭页面后多等十几秒再观察。如果还不弹，可以主动触发一次 GC 再等，别频繁操作干扰观察。

4.3 常见问题二：报告里全是系统类，找不到自己代码

现象是引用链里一堆系统类名，看得人头皮发麻。原因是泄漏的“根”常常在系统框架里，比如某个系统服务持有了你的对象，而你的代码只是链条中间的一环。解决办法是别被系统类吓住，重点找链条里出现的你自己的包名和类名，那一环才是你能改的。如果确实找不到，把报告里的关键类名记下来，对照你最近改动的代码去匹配，通常能对上。

4.4 常见问题三：把“正常持有”误判成泄漏

现象是刚打开页面就报泄漏，或者某个对象明明还在用却被报。原因是 LeakCanary 的判定基于“对象应该被回收却没被回收”，如果你在对象还被正常使用时就触发观察，可能产生误报。解决办法是结合业务判断：这个对象此刻是否真的该被释放？如果它还在被使用，报告可以忽略；如果它确实该释放了却还在，那才是真问题。别看到通知就条件反射地改代码，先想清楚生命周期。

4.5 常见问题四：修完还报，以为没修对

现象是改了代码，通知还在。原因可能是旧进程还活着、报告是上一次的缓存、或者你改的地方不是真正的引用源。解决办法是先彻底杀掉 App 进程重跑，排除缓存干扰；再对照引用链确认你改的那一环是否真的在链条上；如果链条有多条路径，可能还有第二个引用没处理。修泄漏经常是“拔掉一根还有一根”，耐心顺着链条清干净就好。

5. 下一步学什么：把工具用成习惯的路线

跑通例子、看懂报告之后，你可能会问：接下来该往哪走？我的建议是别急着去啃底层原理，先把 LeakCanary 用成日常习惯，再逐步扩展。入门阶段的目标不是成为内存专家，而是让“写完一个页面就顺手验证一下有没有泄漏”变成肌肉记忆。下面给一条按周推进的路线，你可以照着走。

第一周，把本文的例子在自己的项目里复现一遍，重点是熟悉“制造 → 观察 → 修复 → 验证”的循环，做到不看教程也能独立完成。第二周，挑项目里一个真实的页面，主动用 LeakCanary 观察它关闭后有没有泄漏，哪怕没报也记录一下，培养“关页面就想验证”的意识。第三周，开始整理自己的“泄漏黑名单”：把遇到过的泄漏类型记下来，比如静态持有 Activity、监听器未注销、单例持有 Context，每类配一句修复口诀。这个清单比任何教程都贴身。

再往后，可以逐步了解几个相关概念：对象的生命周期、强引用与弱引用的区别、GC Root 是什么。不用一上来就啃文档，遇到报告里看不懂的类名再去查，带着问题学效率最高。工具层面，等 LeakCanary 用熟了，可以再接触更专业的堆分析工具，但那是后话，现在别贪多。

最后说个我自己的教训：刚开始用的时候，我总想着“等有空再统一排查”，结果泄漏越积越多，报告堆了一屏反而不敢看。后来我给自己定了个规矩——每写完一个带生命周期的页面，关闭时必看一眼有没有新通知，有就当场处理。从那以后我每次提交代码前都强制走一遍这个动作，泄漏再也没攒成堆。希望帮到你，从今天这个例子开始，把第一个通知跑出来。

本文还有配套的精品资源，点击获取