简介面向Android开发者的LeakCanary上手资料聚焦内存泄漏检测这一性能优化关键环节为需要在真机或模拟器上定位内存问题、分析泄漏路径的初中级开发者提供可直接运行的示例工程。资源共54个文件包含Java源码、gradle构建脚本、资源布局XML、配置文件及运行缓存文件等压缩包仅596KB结构精简便于快速导入Android Studio查看与调试。已有1906人学习适合想避开Android Profiler和MAT等PC端复杂操作、转而用开源库在手机端实时检测内存泄漏的开发者。通过该Demo可掌握LeakCanary的接入步骤、初始化配置、泄漏通知查看方式并了解如何在项目中利用其自动检测机制优化内存表现同时为后续排查复杂泄漏场景提供基础样例整体难度适中适合作为内存优化入门的第一份实践资料。1. LeakCanary 到底在帮你做一件什么事做 Android 开发的人多多少少都听过LeakCanary这个名字。它是 Square 团队开源的一款内存泄漏检测工具用一句话概括它能在你的 App 运行过程中自动盯着那些“本该被回收但实际还被引用着”的对象一旦发现不对劲就直接把当时的堆内存快照抓下来再用自研的分析引擎把引用链刨出来最后在手机通知栏和桌面图标里告诉你“哪个对象泄漏了、是谁拖着它不让走”。我最早接触 LeakCanary 是 1.x 时代当时还需要在 Application 里手动创建 RefWatcher然后自己在代码里调用watcher.watch()去盯着某个对象。到了 2.x 之后体验完全是两个物种依赖一加什么都不用写Activity、Fragment、ViewModel、RootView 全被自动监控。对团队来说这意味着接入成本和维护成本都压到了极低在 debug 包上跑一整天再去 Leaks 应用里翻一遍历史记录基本就能把大多数泄漏问题揪出来。这篇文章不是照着官方 README 给你翻译一遍而是从一个实际接入了 LeakCanary、并靠它清理过几轮内存问题的开发者的角度把它怎么用、怎么读报告、有哪些需要注意的坑一次说清楚。适合刚接手项目准备排查内存问题的人也适合把 LeakCanary 接上但平时不太看报告、不知道从哪下手的同学。2. LeakCanary 的工作原理你看懂几个关键点就能用好它2.1 它是怎么判定“这个东西泄漏了”LeakCanary 的核心机制并不复杂。它内部有一个ObjectWatcher专门负责监控那些生命周期已经结束的对象。以 Activity 为例它会往 Application 注册一个ActivityLifecycleCallbacks当某个 Activity 走到onDestroy之后LeakCanary 就会认为这个 Activity 的使命已经完成接下来的事只有一个——等系统把它回收掉。怎么确认回收没发生呢LeakCanary 会把 Activity 实例包装成一个弱引用同时保留一个强引用在内部持有它。然后等一个短暂的观察期默认 5 秒之后再触发一次Runtime.getRuntime().gc()去尝试回收接着检查那个弱引用是否已经被清空。如果对象能被回收弱引用指向的值就变成 null一切正常。如果过了 gc 之后弱引用里面还拿得到对象那基本可以判定有某个强引用链一直拽着它内存回收根本没机会下手。这套“弱引用 手动 GC 二次确认”的设计本质上是在避免误报。因为 Java 里对象回收时机不是一个精确的时间点你贸然说“这个对象泄漏了”很容易误伤。所以 LeakCanary 会做两次判定第一次是观察期过后查看弱引用情况第二次是主动 GC 后再看一次仍然被引用才进入下一阶段。这个细节大家在读它源码的时候可以留意一下。2.2 判定泄漏以后真正的重头戏才开始一旦某个对象被判定为“疑似泄漏”LeakCanary 并不会立刻给你推送结论。它需要证据链证据就是对当前进程做一次完整的内存堆转储heap dump然后交给分析引擎 Shark 去处理。注意这个 heap dump 过程和分析过程默认是在一个独立的:leakcanary进程里完成的而不是在你 App 的主进程里这是 2.x 一个非常聪明的设计。为什么因为堆转储的时候如果不能快速冻结住堆的状态整个 dump 就没有意义而在主进程里做这种事会直接把 App 卡死。独立进程的好处是 dump 期间 App 最多轻微卡顿不会“死给你看”。Shark 是 Square 自研的堆分析引擎专门替代了早期基于 MATEclipse Memory Analyzer的离线分析方案。它做的事情简单说就是从 heap dump 里找到那些已经被ObjectWatcher标记过的泄漏对象然后沿着对象的引用图一路往上找直到找到一个 GC Root把中间的每一条引用关系全部记录下来。最终展示给你的不是一句“有泄漏”而是一整条有头有尾的“引用链”告诉你泄漏对象是被谁通过哪个字段、哪个方法拽住的。这条链路就是整个 LeakCanary 最有价值的部分。你要是只想知道“有没有泄漏”那工具太多了但是你想知道“泄漏点在哪、该改谁”就得靠这条引用链一路顺藤摸瓜。2.3 默认自动监控哪几类对象2.x 对你盯得有多死你可以打开AppWatcher看它的默认配置里面默认开启了这几个维度的监控ActivityonDestroy之后是否被回收FragmentonDestroyView之后是否被回收ViewModelonCleared之后是否被回收RootViewDialog、Toast 等视图从窗口分离之后是否被回收就拿onDestroy这个时机来说很多初学者容易忽略一个边界情况onDestroy被调用不代表 View 相关的资源已经彻底解绑。Fragment 里如果onDestroyView之后还在某个地方持有着rootView的引用那这个 View 树也就跟着 Fragment 一起泄漏了。LeakCanary 把 Fragment、RootView 都纳入监控实际上就是在帮你盯住这层很容易被漏掉的引用。3. 接入流程从零配置到抓出第一个泄漏3.1 添加依赖我推荐你只写在 debug 包LeakCanary 的接入不是一般的简单在模块的build.gradle里加一行就够debugImplementation com.squareup.leakcanary:leakcanary-android:2.14注意我用的是debugImplementation不是implementation。原因有两个层面。第一内存泄漏分析本身比较吃性能线上用户手机不可能陪着你做 heap dump第二LeakCanary 在主进程里会注册各种监听还会在桌面给你加一个“Leaks”应用图标——这种东西出现在线上包目录里怎么看都不专业。有人可能会问那releaseImplementation里如果漏掉它到底会有什么后果这么说吧2.14 这个版本里 LeakCanary 的初始化是依靠一个自动生成的ContentProvider完成的只要这个库被编进 APK它就会在 App 启动早期自动初始化。release 包要是带上它等于每位线上用户都在帮你跑内存监控一旦触发 heap dump用户手机会卡顿、耗电、上传失败……这个锅你不想背。所以在 gradle 里用debugImplementation从根上阻断这个风险。3.2 为什么不用写初始化代码我遇到很多第一次接触 2.x 的同事加完依赖之后到处找LeakCanary.install()的调用找半天找不到。不用找了2.x 里这个 API 已经被移除初始化完全由ContentProvider自动触发。Android 系统在 Application 启动的时候会先实例化并调起所有注册的ContentProviderLeakCanary 在它的 manifest 里声明了AppWatcherInstaller这个ContentProvider所以 App 一冷启动它就被系统“顺手”拉起来了。这套自动初始化机制有利有弊。利是接入成本低不用改 Application弊是一些同学会因此忽略掉自己手动控制初始化的这套能力。其实 LeakCanary 提供了AppWatcher.config和LeakCanary.config两个静态配置对象你可以根据自己的需要修改监控开关、堆转储行为、事件监听等。真想要动态控制就写在自己的 Application 里在启动流程的某个节点直接改 config 即可。3.3 第一次抓泄漏我建议你先手动测试一个稳定复现的泄漏接入之后别急着跑整个项目。最理智的做法是先造一个必现的泄漏场景验证链路是否通畅。比如写一个 Activity里面用一个静态变量保存住自己的 contextclass LeakActivity : AppCompatActivity() { companion object { private var leakedContext: Context? null } override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) leakedContext applicationContext // 是 applicationContext不会泄漏先看看不用它 } }上面这种写法不会泄漏因为applicationContext是全局单例没有 Activity 依赖。正确的验证场景是持有 Activity 自身companion object { private var leakedActivity: Activity? null } override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) leakedActivity this }打开页面再退出然后等待观察期结束LeakCanary 大概率会在十几秒到半分钟内在通知栏弹出一条“Leak detected in xxx”。这时候你点击通知就会跳进 Leaks 应用看到那条泄漏的引用链。要是等了一两分钟还没看到通知先检查一下你是不是在 release 包上跑的或者桌面目录里有没有出现“Leaks”图标这两点是最常见的翻车原因。4. 读懂 LeakCanary 的泄漏报告引用链阅读手册4.1 一条引用链长什么样LeakCanary 给出的泄漏分析报告核心是一串引用链。我贴一条比较典型的报告片段来配合理解┬─── │ GC Root: System class │ ├─ com.example.Utils class │ Leaking: NO (a static class) │ ├─ static Utils.instance │ ↓ ├─ com.example.SessionManager instance │ Leaking: UNKNOWN │ ↓ SessionManager.context ├─ com.example.MainActivity instance │ Leaking: YES (Activity#mDestroyed is true)这条链子怎么读我从上往下给你拆。第一行说 GC Root 是System class也就是 Java 系统类层面对它有引用。往下走一个静态类Utils里有个静态字段instance指向一个SessionManager对象而这个SessionManager里保存了一个context字段这个字段指向的正是MainActivity——一个已经标记为mDestroyed true的页面。看到Leaking: YES和Activity#mDestroyed is true就可以确定它确实泄漏了而且泄漏源头就是Utils.instance这个静态字段。实际项目里引用链可能比这长很多中间会经过 Fragment、Adapter、第三方 SDK 内部一堆对象。但读法是一样的优先看最底部的Leaking: YES对象是谁再沿着箭头一层一层往上找第一处“不该持有它的地方”。通常你要修的不是底部那个对象本身而是链路上某个不恰当的持有者。4.2 GC Root 的几种常见类型你得熟悉分析报告头部一定会标出 GC Root 类型这有助于缩小排查范围。我见过比较频繁的有这么几类System class类本身是静态的通常意味着某个静态变量兜着一条链Java local本地变量还没出栈可能是异步任务还在执行中JNI globalNative 层持有 Java 对象引用thread某个线程还活着线程内部持有 Runnable、Handler 或 Looper 的消息对应到实际场景System class多是单例、静态设置器、静态 List 缓存把 Activity 存进去了thread多是 Handler、RxJava 订阅、协程任务未取消回调里还拿着外部引用。你看到 GC Root 类型之后再结合引用链中标注的字段名基本就能判断出泄漏是“全局静态持有”导致的还是“异步回调晚到”导致的。4.3 哪些情况会被标记为 Leaking: UNKNOWN不是每一条引用链都能直接告诉你“YES 或 NO”。有时候报告中间层某几个对象会显示Leaking: UNKNOWN。这意味着 Shark 在分析时无法推断该对象生命周期是否已结束。通常这不是什么坏事你只要关注链路的终端对象是不是YES就行。如果链路终端是UNKNOWN说明这个对象它也没把握有可能是框架内部对象被系统机制自然持有未必是业务代码的问题遇到这种报告可以先放一放不用追着改。真正需要警惕的报告是终端对象标记了YES而且引用链里出现了你自己的类、你的静态变量、你的单例。这才是你洁身自好的业务代码里冒出来的洞。5. 遇到高难度场景怎么办手动监控和 report 差异化配置5.1 手动监控一个自定义对象默认能盯 Activity、Fragment、ViewModel、RootView但是你自己写的一个单例、一个工具类、一个播放器实例不可能让 LeakCanary 凭空知道它什么时候该被回收。这种场景就要用手动 API。LeakCanary 的AppWatcher.objectWatcher提供了一个watch()方法你可以在确认对象生命周期结束时手动把它交给 watcher 盯住。比如某个视频播放器你有清晰的释放逻辑override fun release() { // 业务释放 player.stop() player.release() AppWatcher.objectWatcher.watch(player, VideoPlayer was not released properly) }这里的第二个字符串参数是“描述信息”会伴随泄漏报告一起出现帮你回忆当时监控它的业务意图。个人建议手动watch不要太随意否则全项目到处埋点报告噪音会很严重。只挑那些“曾经出过泄漏问题”或者“在架构上容易被外部持有”的关键对象去盯。5.2 给特定类“开后门”Exclusions 和筛选有些泄漏其实不是你的锅而是第三方 SDK 在特定版本上的历史问题。比如某个老版本 IM SDK 内部会用一个静态集合把登录回调对象保存到进程退出业务侧注册之后没法主动清除。这种被 LeakCanary 天天挂在报告里面看着非常烦但你又改不了 SDK怎么办LeakCanary 提供了过滤器。你要有能力区分“真正的泄漏”和“一个已知的、当前无法解决的残留引用”。在当前版本中可以通过修改AppWatcher.exclusionsFactory来自定义排除规则对指定类名的对象忽略监控AppWatcher.exclusionsFactory object : ExclusionsFactory { override fun create(heapDump: HeapDump, leaks: ListLeak): ListExclusion { return leaks.mapNotNull { leak - leak.leakTraces.firstOrNull()?.let { trace - Exclusion( rule known sdk issue, matching object : Exclusion.Matching { override fun matches(leakTraceElement: LeakTraceElement): Boolean { return leakTraceElement.className.contains(com.thirdparty.sdk.) } } ) } } } }这里的思路是分析结果出来之后LeakCanary 会遍历每条引用链凡是匹配上排除规则的就不再归入“should fix”列表。有这个能力之后你就可以把已知的、阻塞性不强的第三方泄漏“静音”让报告里剩下来的条目都值得投入精力。5.3 调整堆转储时机和监控开关LeakCanary 的默认观察等待时间是 5 秒但低端机上 gc 可能没那么及时报告来得慢。你可以在 Application 里调整AppWatcher.config AppWatcher.config.copy( watchDurationMillis 10_000 )同理如果你想临时关掉某个维度的监控比如在某个依赖 Fragment 巨多的页面上报告全都是 Fragment 假阳性也可以改watchFragments开关。原则上上线前我会把这类自定义保持默认只有出现明显的误报噪音时才去微调。6. 接入 LeakCanary 之后你一定要处理的 4 类常见问题6.1 报告很多但不敢改怕改坏功能这是 LeakCanary 用得最痛苦的一个阶段。报告列出 50 条但你越看越不敢动因为每一条都牵扯着业务。我的建议是不要一头扎进代码里改而是先把报告按“引用对象所属模块”分类。一般分类完会发现80% 的泄漏集中在那么几个模块启动页、登录页、某个商品详情页。先把每个模块的泄漏从引用链反推出“入口对象”和“退出行为”再判断它应该在哪里释放。多数泄漏本质上就三种单例或静态变量持有页面实例退出时没有置空回调注册了没反注册退出时被第三方对象继续持有异步任务/协程没有随页面销毁取消消息里夹带着外部引用想清楚这三种改起来就有方向了。LeakCanary 不是让你机械地修每一行代码而是给你一把照着检查的尺子。6.2 手动 GC 会影响性能吗LeakCanary 在 debug 包上每次检测到泄漏都会做 heap dump这个操作本身比较耗时低端机上可能会看到明显卡顿。这不是 bug而是 heap dump 的固有限制。如果你既要跑性能测试又要开 LeakCanary可以先把 dump 关掉只保留对象监控LeakCanary.config LeakCanary.config.copy( dumpHeap false )关闭之后LeakCanary 仍然会记录是不是有泄漏发生只是不生成完整的堆分析报告。这套组合适合拿来做快速回归确认新需求有没有引入明显泄漏等发现某条上报对象异常了再打开 dump 细查。6.3 通知栏迟迟没弹或者根本没有 Leaks 图标排查思路按下面这张表走现象可能原因处理方式通知没弹出用了 release 包运行切到 debug 包通知没弹出系统通知权限未开启在系统设置里允许通知通知没弹出监控对象并未走到生命周期结束确认 Activity 真的被 finish桌面没有 Leaks 图标没有触发过任何泄漏先手动造一个泄漏验证链路桌面有图标但列表空确实没检测到问题排除相关实现即可另外还有个细节桌面那个 Leaks 应用图标在部分定制 ROM 上可能被自动收进应用市场目录里找不到别慌去“应用列表”里翻一下。6.4 想把它加到 CI 上做自动化回归LeakCanary 提供了 JVM 端的堆审核接口用HeapAnalyzer这个类可以直接分析一个 dump 文件。实际团队落地中我见过比较稳定的一种方案是在 nightly build 的自动化测试流程里跑一遍主要路径用例测试结束后收集测试进程产生的堆 dump 文件批量丢到独立分析任务里跑 Shark。因为 LeakCanary 的 dump 跟项目 UI 解耦分析工具本身也能在纯 JVM 环境下工作所以这条路基本可行。不过说句实在话CI 自动分析的误报调试成本并不低如果你团队规模不大、内存优化需求也不紧急不如先把 LeakCanary 的日常人工巡检跑顺再考虑 CI 自动化。工具是死的适合自己节奏的才是好的。7. 最后再分享两个使用习惯第一个习惯是清理存量泄漏的时候每次只改一个改完跑一遍复现路径确认报告里那条链确实消失再做下一条。贪多求快的结果往往是引用链改了、新问题又冒出来到最后都不知道是哪个改动生效的。LeakCanary 的报告是客观的但排查节奏一定要把控在你自己的手里。第二个习惯是不要只盯着 wrapper 报告也要定期看 Leaks 应用里的历史趋势。Leaks 应用会按时间保存每一次泄漏记录翻一翻可以看到某些页面是不是反复泄漏、某些组件是不是在版本迭代中逐渐变差。这种“趋势”比单次泄漏报告更值得你重视因为单条泄漏可能改一下就没了趋势说明你的代码架构里有某种系统性的持有风险。LeakCanary 就是个放大镜它不能替你修代码但能帮你在最合适的时机看到最准确的问题点。用好了它你的 App 在内存稳定性上会有一个看得见的提升。本文还有配套的精品资源点击获取