内存泄漏与 LeakCanary：从问题定位到修复思路

为什么内存泄漏值得单独关注

Android 应用运行在内存有限的移动设备上。一次小泄漏可能暂时看不出问题，但使用者频繁打开页面、旋转屏幕、切换账号或长时间停留在应用里时泄漏对象会不断堆积。最终表现为页面卡顿、图片加载失败，严重时直接触发 OutOfMemoryError。

内存泄漏的本质很简单：一个本该被释放的对象。仍然被某条引用链持有，导致垃圾回收器无法回收它。

例如 Activity 已经执行了 onDestroy按理说页面相关的 View、Bitmap、Adapter 都应该一起释放。如果某个全局单例、静态变量、后台任务或回调还持有这个 Activity，它就不会被回收。 Activity 一旦泄漏。通常不是只泄漏一个对象，而是一整棵页面对象树。

先理解引用链

垃圾回收器判断对象是否可回收时不是看对象有没有“用处”，而是看它能不能从 GC Roots 访问到。常见 GC Roots 包括：

• 当前运行线程的栈变量
• 静态字段
• JNI 引用
• 程序类加载器持有的对象
• 正在运行的线程对象

如果一个销毁后的 Activity 还能通过类似下面的链路被访问到，它就泄露了：

GC Root -> Singleton.instance -> callback -> MainActivity

实际案例痛点 - 使用者反馈：“每次返回首页都要重启APP才能解决卡顿” - 测试发现：“连续切换5个Fragment后内存使用翻倍” - 开发同学困惑：“为什么一样的代码有时会OOM有时不会？”

匿名内部类和延迟任务

注册监听后忘记反注册

协程作用域用错

定位泄漏的实战流程

什么时候可以忽略报告

预防比排查更关键