简介这份资源是面向Android开发者的LeakCanary入门实践Demo聚焦内存优化中最关键的内存泄漏排查环节。相比Android Profiler、MAT等PC端工具LeakCanary可直接在手机端运行帮助开发者在真机调试中快速定位泄漏对象与引用链适合刚接触性能优化、需要上手内存泄漏检测的初中级开发者参考。压缩包共54个文件约596KB以png截图、xml配置、java源码、properties与gradle构建脚本为主另含jar、bat、lock等工程辅助文件完整保留了可导入Android Studio的Demo工程结构便于对照源码理解接入方式与运行流程。目前已有1918人学习下载。通过这份Demo读者可以了解LeakCanary在项目中的依赖配置、初始化与泄漏提示的触发过程结合截图与源码观察检测结果为后续在自有项目中排查内存泄漏积累可复用的实践思路。1. 内存泄漏排查的起点为什么 LeakCanary 值得先上手线上偶发 OOM、页面退出后内存不降、列表越滑越卡这类问题最烦的地方在于它不报错只在某个时刻突然把进程拖死。LeakCanary 就是干这件事的一个跑在 Android 应用进程里的内存泄漏检测库通过监听 Activity、Fragment 等对象的生命周期在对象该被回收却没被回收时主动触发堆转储再离线分析出引用链直接告诉你「谁持有谁、泄漏卡在哪一环」。它不解决泄漏但把「猜」变成了「看」。适合谁刚接手一个历史项目、需要快速定位内存问题的 Android 开发者以及想给团队建立内存回归防线的工程负责人。这篇按「接入 → 读懂引用链 → 排坑 → 进阶」的顺序拆新手能照着跑通熟手能看清它的边界和误报来源。2. 接入与配置从依赖到第一个泄漏报告LeakCanary 的接入成本低到有点反直觉——多数情况下你只需要加一行依赖剩下的初始化它自己在 ContentProvider 里做完了。但「能跑起来」和「跑得对」是两回事配置项没调好要么检测不到要么报告里全是噪音。2.1 依赖引入与版本选择常见做法是在模块级构建脚本里加调试依赖注意只放在 debug 变体别让它进 release 包// app/build.gradle dependencies { // 只在 debug 构建中引入release 包不包含检测逻辑 debugImplementation com.squareup.leakcanary:leakcanary-android:2.14 }逻辑说明用debugImplementation而不是implementation是因为 LeakCanary 会常驻监听生命周期并做堆转储放进线上包既增加体积又带来性能开销。参数上版本号建议跟项目里已有的 Okio、Kotlin 版本对齐——LeakCanary 2.x 依赖较新的 Okio如果项目里锁了老版本 Okio会出现运行时NoSuchMethodError这类冲突用./gradlew :app:dependencies查依赖树最快。2.x 相比 1.x 最大的变化是不再需要手动install()也不需要单独的leakcanary-android-no-oprelease 变体天然无副作用这一点省掉了不少历史项目里的初始化代码。2.2 关键配置项与自定义行为默认配置对大多数项目够用但有两类场景必须改一是你想控制检测范围二是你想把报告落到自己的存储或上报通道。配置通过res/values/leakcanary.xml或代码里的AppWatcher、LeakCanary对象完成// 在 Application.onCreate 中按需调整 class DemoApp : Application() { override fun onCreate() { super.onCreate() // 关闭对 Fragment 的自动监听减少无关报告 AppWatcher.config AppWatcher.config.copy( watchFragments false, watchFragmentViews false ) // 自定义堆转储的存储目录与保留数量 LeakCanary.config LeakCanary.config.copy( retainedVisibleThreshold 3, // 对象被持有超过 3 次 GC 才判定 dumpHeap true ) } }逻辑说明watchFragments关掉是因为很多项目用自定义 Fragment 容器自动监听会产生大量「视图已销毁但 Fragment 仍被 ViewPager 缓存」的误报先关掉再按需打开更省心。retainedVisibleThreshold是判定阈值默认 5调小会更敏感但误报增多调大则可能漏掉短命泄漏一般 3 到 5 之间试。dumpHeap控制是否真的落堆文件调试期保持 true做性能压测时可以临时关掉避免频繁 GC 干扰。存储目录默认在应用私有目录下报告文件是.hprof用 Android Studio 的 Profiler 也能打开对照看。2.3 触发一次检测并读懂报告接入后不需要你手动触发正常操作应用即可。当某个 Activity 执行onDestroy后经过若干次 GC 仍被强引用LeakCanary 会在通知栏弹出一条泄漏提示点开是引用链。报告结构分三段泄漏对象、引用链、GC Roots。读的时候从下往上找「第一个不该存在的引用」——比如一个静态 Map 持有 Activity链上会明确写出static field - HashMap - Activity。这一步的关键不是看长度而是看哪一环是业务代码自己写的框架层的引用如 InputMethodManager、系统服务通常是已知误报可以忽略。3. 引用链分析把「谁持有谁」翻译成代码问题拿到报告只是开始真正花时间的是把引用链映射回具体代码。这一章讲怎么读、怎么用工具辅助、以及怎么把一次分析沉淀成可复用的排查路径。3.1 引用链的三种典型形态实际项目里高频出现的泄漏形态就那么几类认出来能省一半时间。第一种是静态集合持有单例里的List、Map缓存了 Activity 或 View页面销毁后集合没清。第二种是匿名内部类与 Handler非静态内部类隐式持有外部 ActivityHandler的Message还在队列里排队时 Activity 就销毁了。第三种是监听器未注销广播接收器、传感器监听、第三方 SDK 的回调注册后没在onDestroy反注册。报告里对应的链分别是static field - collection - Activity、MessageQueue - Message - Handler - Activity、registered listener - Activity。看到这三种前缀基本可以直接去搜对应的注册/缓存代码。3.2 用 hprof 文件做二次确认LeakCanary 的分析是自动的但有时它给出的「泄漏对象」只是表象真正的持有者藏在更深层。这时把.hprof文件导出来用 Android Studio 的 Memory Profiler 或 MAT 打开做交叉验证# 从设备拉取 LeakCanary 生成的堆转储文件 adb shell run-as com.example.demo ls files/leakcanary/ adb exec-out run-as com.example.demo cat files/leakcanary/2024-xx-xx.hprof leak.hprof逻辑说明run-as用于访问 debug 包的应用私有目录exec-out保证二进制文件不被终端换行符破坏。拿到文件后在 Profiler 里按类名过滤看Instance Count和Retained Size重点找那些「实例数应该为 1 却出现多个」的类——比如某个 Activity 出现 3 个实例说明前两个没被回收。这一步的价值在于LeakCanary 告诉你「这个对象泄漏了」Profiler 告诉你「同类对象一共泄漏了几个、各自被谁持有」两者对照能排除掉单例误报。3.3 把一次排查固化成检查清单单次修完不算完团队里同类问题会反复出现。我的习惯是每修一个泄漏就在代码规范里补一条对应检查项比如「所有registerReceiver必须在onDestroy配对unregisterReceiver」「静态缓存必须提供clear()并在onLowMemory调用」。更进一步可以在 CI 里跑一轮 Monkey 测试后自动触发 LeakCanary 的检测把泄漏报告作为构建产物归档形成回归防线。这一步不需要额外框架LeakCanary 本身提供了LeakCanary.install()之外的编程式入口配合 instrumentation 测试即可。4. 避坑与排查那些报告没说清的事LeakCanary 好用但它的报告不是圣旨。下面几条是实际接入时最容易翻车的地方按「现象 → 原因 → 解决」记。4.1 报告里全是系统类的「泄漏」现象每次退出页面都弹报告引用链终点是InputMethodManager、AccessibilityManager或android.os.Binder。原因这些是 Android 框架自身的已知持有行为属于误报LeakCanary 内置了一份忽略列表但不可能覆盖所有机型。解决在LeakCanary.config里通过referenceMatchers追加自定义忽略规则把确认无害的类排除同时升级到较新版本官方忽略列表会持续补充。4.2 检测不到预期的泄漏现象明明代码里有个静态 List 持有 Activity报告却一直不弹。原因多半是retainedVisibleThreshold设太大或者对象在阈值内被别的路径释放了也可能是该 Activity 还在任务栈里没真正onDestroy。解决先把阈值调到 2 观察确认onDestroy确实执行打日志验证再检查是否被watchActivities false关掉了监听。4.3 堆转储导致应用卡顿甚至 ANR现象开启检测后页面切换明显变慢低端机上偶发无响应。原因堆转储会暂停应用线程堆越大耗时越长频繁触发就是灾难。解决调试期接受这个代价压测和性能测试时通过dumpHeap false关闭实际转储只保留监听生产环境绝不引入该库这一点靠debugImplementation保证。4.4 多进程应用只检测到主进程现象应用开了推送、后台等独立进程那些进程里的泄漏完全没报告。原因LeakCanary 默认只在当前进程初始化其他进程没有监听器。解决在每个需要检测的进程的Application.onCreate里判断进程名后分别初始化或者干脆只保留主进程检测把跨进程对象的生命周期交给更上层的架构约束。4.5 升级后旧报告打不开现象换了 LeakCanary 版本后之前保存的.hprof在新版分析器里解析失败或引用链错乱。原因堆转储格式与分析器版本存在兼容窗口跨大版本尤其明显。解决报告文件跟版本号一起归档分析时用生成它的同版本工具日常排查优先看通知栏的即时报告历史文件只作留档。5. 进阶把检测嵌进开发流程而不是靠人盯LeakCanary 真正的价值不在「弹一次报告」而在把它变成流程的一部分。我一般会做两件事一是给关键页面写 instrumentation 测试在onDestroy后主动触发一次 GC 并断言无 retained 对象二是把泄漏报告接入团队的构建归档每次提测自动收集。前者用AppWatcher.objectWatcher.expectWeaklyReachable()的思路后者靠自定义OnHeapAnalyzedListener把结果写到指定目录。// 自定义监听器把分析结果落到文件供 CI 收集 LeakCanary.config LeakCanary.config.copy( onHeapAnalyzedListener OnHeapAnalyzedListener { heapAnalysis - // 只记录确认泄漏的结果忽略无泄漏和误报 if (heapAnalysis is HeapAnalysisSuccess heapAnalysis.allLeaks.isNotEmpty() ) { File(filesDir, leak-report.txt).appendText( heapAnalysis.allLeaks.joinToString(\n) { it.toString() } ) } } )逻辑说明OnHeapAnalyzedListener是分析完成后的回调HeapAnalysisSuccess里allLeaks只包含被判定为泄漏的条目误报已在内部过滤。把结果写文件而不是弹通知是为了让 CI 能读取filesDir是应用私有目录测试结束后用adb pull取走即可。参数上注意别在回调里做重 IO否则会拖慢分析线程简单追加文本足够。验证方法也简单故意在某个页面写一个静态 List 持有this跑一遍测试确认报告文件里出现该页面类名再删掉泄漏代码复跑确认报告为空。这一正一反两次验证比看十篇文档都管用。从那以后我每次给新项目接 LeakCanary都强制先跑一遍这个正反验证确认检测链路真的通了再交给团队用——毕竟一个「看起来在跑但其实没生效」的检测工具比没有更耽误事。希望帮到你。本文还有配套的精品资源点击获取