做Android开发这些年内存泄漏是我在面试里问得最多、也是线上问题里排查起来最磨人的一类问题。它不像崩溃那样直接弹窗报错而是悄无声息地侵占你的堆内存等到App开始频繁GC、启动变慢、列表滑动掉帧时你才意识到内存已经被一点点“偷”走了。更麻烦的是这种问题往往只出现在长时间使用时测试阶段很难暴露。这篇文章我不会只讲结论而是试图把“内存泄漏”这件事从JVM底层原理讲到Android实战把背后的机制拆开揉碎再配合典型的泄漏场景和排查工具给你一条可以直接照着去定位问题的路径。无论你是刚装好Android Studio准备进入内存优化大门的初学者还是已经被线上OOM折磨过几轮的开发者这篇文章应该都能给你一些新的思路。1. 先看底层JVM内存模型到底分了哪几块1.1 从一块内存的分配讲起运行时数据区全景要知道内存为什么会泄漏首先得搞清楚内存平时是放在哪里的。JVM的运行时数据区可以类比成一间公司不同区域负责不同职能。程序计数器是“当前在排队叫号的小票”每个线程手上都有一张记录下一步要执行的字节码指令地址Java虚拟机栈是“每个线程的私人储物柜”里面放着一个个栈帧栈帧里有局部变量表、操作数栈、动态链接和方法出口信息每调用一个方法相当于往柜子里塞一个格子方法调完就弹出去本地方法栈和虚拟机栈的角色类似只不过服务于native方法。堆和方法区才是我们最需要关心的两个公共区域。堆是对象和数组的家所有通过new创建出来的对象基本都住在堆里方法区存储已被虚拟机加载的类信息、常量、静态变量、即时编译后的代码等数据。在JDK 8之后方法区被彻底搬到本地内存中叫作元空间这算是一次比较大刀阔斧的改动解决了之前永久代容易内存溢出的问题。对于Android环境的ART/Dalvik虚拟机来说基础思路和JVM规范基本一脉相承只是实现细节上做了裁剪和优化比如Android早期没有分代的概念后来ART时代才引入了类似的分代回收机制。1.2 堆的分代设计新生代与老年代堆是GC的主战场。为了让回收效率更高JVM在逻辑上将堆划分为新生代和老年代两片区域。新生代又细分为Eden区、From Survivor区、To Survivor区比例默认大致是8:1:1。绝大多数对象出生在Eden区比如你在Activity的onCreate里new了一堆临时对象它们大多死在Eden去也就是Minor GC发生的时候。Minor GC的频率很高范围很小所以停顿也短。Survivor区是干嘛的它的存在是为了让那些熬过几次GC的对象有地方中转。每次Minor GC后Eden区和上次的From Survivor区里存活下来的对象会被搬到To Survivor区然后交换角色。如果对象在Survivor区里反复搬家年龄计数超过阈值默认15次它就会被晋升到老年代。还有一种情况也会触发提前晋升就是相同年龄的所有对象大小总和超过Survivor空间的一半或者大对象直接进入老年代。老年代的空间更大回收频率更低发生Major GC或者Full GC时通常会有明显的停顿这也是我们在Android上做性能优化时最怕的事情之一。1.3 GC的三种基础算法标记-清除、标记-复制、标记-整理想要判断一块内存能不能回收得先给堆里的对象做标记。最简单直接的做法就是“标记-清除”从GC Roots出发把所有能到达的对象标记为存活没有标记到的直接清除。问题是这种方式会产生大量不连续的内存碎片以后要分配一个大对象时可能找不到足够大的连续空间提前触发Full GC。“标记-复制”的改进思路是把内存分成大小相等的两块每次只用其中一块。用完这一块后把存活对象全部复制到另一块然后把原来那块整体清掉。这种算法分配内存时只需要移动指针不需要考虑碎片但代价是浪费了一半空间。新生代里使用这种思路只是优化成了Eden加两个Survivor不需要按1:1去浪费空间。“标记-整理”则更适合老年代。它先把存活对象标记好然后让它们向内存的一端移动最后清理掉边界以外的所有空间。这样做既能回收空间又不会产生碎片代价是移动对象的成本高需要在GC停顿期间完成对象的引用更新。这三种算法我当年学的时候容易搞混后来记了一个口诀清除不管碎片复制浪费空间整理保序但慢。2. 内存泄漏的本质GC想收却收不掉的对象2.1 可达性分析与GC Roots从“根”寻找所有存活对象GC判断对象是否存活靠的是可达性分析。这个算法的核心是从一组叫GC Roots的根节点出发像蜘蛛网一样往下搜索引用关系走过的路径叫引用链。只要对象在引用链上GC就认为它还被需要不回收如果对象与GC Roots之间没有任何引用链相连那这个对象基本可以宣告死亡。那哪些对象能作为GC Roots常见的有四种虚拟机栈中局部变量表引用的对象也就是当前正在执行的方法里的变量指向的对象方法区中静态属性引用的对象比如static修饰的成员变量方法区中常量引用的对象例如字符串常量池里的引用JNI本地方法栈中引用的对象。Android里还有一个很特殊的根就是系统的Root Activity或正在运行的Activity组件相关对象它们被系统服务持有生命周期由系统来管理。搞懂GC Roots之后内存泄漏的定义就变得非常清晰了一个对象已经完成了它的使命业务上不再需要它了但因为还有别的存活对象持有指向它的引用链导致它依然能从GC Roots出发被遍历到于是GC只能眼睁睁看着它留在堆里久而久之就堆积成灾。这就是很多开发者说的“对象把根给抓住了GC剪不断这条线”。2.2 强引用、软引用、弱引用与虚引用对象的四种“宿命”Java里引用的强度不同回收策略也不同。强引用是最常见的引用类型比如Object obj new Object()只要强引用还在GC永远不可能回收这个对象。软引用描述“有用但非必需”的对象用一个SoftReference包装起来系统在内存充足时不去动它在内存即将溢出之前才尝试回收。弱引用比软引用更短命WeakReference引用的对象只能活到下一次GC之前不管内存够不够只要GC执行它就会被干掉。虚引用最特殊它等同于没有引用唯一的作用是在对象被回收时收到一个系统通知常用于管理直接内存的释放。这里有一点容易被绕进去就是Soft和Weak的差异在Android高版本上的表现Android从API 14之后开始越来越倾向于直接用LRU缓存替代软引用因为软引用在Android的ART/Dalvik上回收时机其实并不完全可控用它缓存大对象反而容易造成内存浪费或者提前触发GC。实际开发中如果想要缓存图片这类大内存资源更稳妥的方案是使用LruCache让缓存大小受控而不是依赖JVM的软引用语义。2.3 四种引用在开发里的应用场景强引用平时写的绝大多数代码注意它也是内存泄漏的主要元凶。软引用可以作为内存敏感的缓存比如一些不重要的临时数据但Android里更推荐用LruCache。弱引用Handler、线程回调、静态内部类持外部引用时经常用常见写法是WeakReference 。虚引用一般只能配合ReferenceQueue使用用于对象回收后的资源清理Android开发里接触不多。这里需要提醒一下弱引用并不是“免死金牌”。有些场景下被弱引用包装的对象生命周期很短一旦GC运行你后续再访问可能拿到null。所以用弱引用时要提前做好判空避免出现逻辑上的NPE。我在项目里见过有人把关键业务对象包进WeakReference结果页面一退后台回来再点按钮核心对象已经被GC收走了线上崩溃率直接翻倍这就是典型的误用。3. Android实战那些年我们踩过的典型泄漏坑3.1 非静态内部类隐式持有外部Activity的隐形锁链Android里最常见的泄漏永远是从非静态内部类开始的。Activity里写一个Handler这是多少年前的老写法了但依然能在不少项目里看到public class MainActivity extends AppCompatActivity { private final Handler mHandler new Handler() { Override public void handleMessage(Message msg) { // 更新UI mTextView.setText(done); } }; Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_main); mHandler.postDelayed(() - doSomething(), 10 * 60 * 1000); } }问题出在哪Handler是非静态内部类的实例它在编译期就持有外部类MainActivity的引用。当postDelayed一个长时间任务时这个Message会被放进主线程的消息队列中Message里持有Handler的引用Handler又持有Activity的引用。如果用户在任务还没执行前就销毁了ActivityActivity的onDestroy已经跑完了但消息队列里还有这个Message导致Activity无法被GC回收。这条引用链是主线程Looper - MessageQueue - Message.target - Handler - MainActivity。解决办法通常是改成静态内部类加WeakReference或者在onDestroy里移除所有待处理的消息。我自己的标准写法是public class MainActivity extends AppCompatActivity { private static class SafeHandler extends Handler { private final WeakReferenceMainActivity mActivityRef; SafeHandler(MainActivity activity) { mActivityRef new WeakReference(activity); } Override public void handleMessage(Message msg) { MainActivity activity mActivityRef.get(); if (activity null || activity.isFinishing() || activity.isDestroyed()) { return; } // 正常处理 } } private final SafeHandler mHandler new SafeHandler(this); Override protected void onDestroy() { super.onDestroy(); mHandler.removeCallbacksAndMessages(null); } }注意两个细节一是静态内部类不持有外部引用这是根除问题的关键二是移除所有回调时要传null表示移除这个Handler下对应的所有Message和Runnable。如果不判空或者不移除该泄漏还是会以其他形式出现。3.2 Activity Context被长生命周期对象持有单例与静态字段的锅第二种高发场景是单例模式持有Activity Context。很多开发者为了方便直接在某个工具类里写一个static的Context引用或者在单例初始化时传入Context结果这个Context是Activity的Context那么整个单例的存活期间都牵制着Activity不能释放。比如public class ToastUtils { private static Toast mToast; private static Context mContext; public static void init(Context context) { mContext context; // 如果传进来的是Activity就泄漏了 } }单例类的生命周期和应用进程一样长而Activity从创建到销毁只是短时间的事情。当Activity已经被用户finish掉单例中的mContext还死死抓着它内存怎么都释放不了。解决办法是无脑传ApplicationContext或者干脆在init方法内部做一层转换context.getApplicationContext()。但要记住不是所有场景都能无脑替换成ApplicationContext比如涉及样式主题、Toast、Dialog这类需要挂载在当前Activity上显示的东西就不能用ApplicationContext。这里的原则是能短不长能专用不全局。3.3 注册、监听、回调忘记注销的代价Activity里注册一个BroadcastReceiver、给某个库设置Listener、订阅EventBus、给系统服务添加传感器监听这些都是常见的操作。如果你只register了、subscribe了、add了而忘了在onDestroy里做相反的注销操作就会让Activity被系统服务或事件总线持有。我有一个习惯就是把“注册/注销”成对写在onStart/onStop或者onResume/onPause里这样即使忘了也能在代码review时一眼看出来。EventBus的典型操作是在onStart中register在onStop中unregisterBroadcastReceiver在onStart中register在onStop中unregister传感器监听在onResume中注册在onPause中注销。千万别它们都堆在onCreate和onDestroy里因为系统组件的生命周期和Activity的可见状态并不完全对等。3.4 资源对象泄漏Cursor、IO流与Bitmap这一类在新项目里不那么常见了但仍然有踩坑的价值。早期的Coding规范会要求使用Cursor后必须closeIO流用完后必须flush和close。在实际操作中很多人打开了Cursor之后只做了遍历没有在finally中关闭一旦遍历中抛出异常Cursor就一直开着底层桥接的内存和文件句柄也一直占着。Bitmap的情况有点特殊。在Android 2.3API 9以前Bitmap的像素数据位于native内存必须要手动recycle才能释放但之后的版本Bitmap的像素数据已经跟着对象一起放到了堆上GC可以直接回收。所以现在你手动调用recycle反而可能带来使用上的风险。如果用了Glide或Coil这类图片加载库内存管理大都是由它们自己完成的不要在不知情的时候又去手动回收。如果你确实自己管理了Bitmap比如做图片编辑器这类重度图像应用可以配合图片复用inBitmap来控制堆内存占用。4. 排查工具如何一步步定位内存泄漏4.1 Android Studio Memory Profiler先看内存曲线再Dump Heap排查内存泄漏最好的切入点就是观察内存曲线。打开Android Studio的Profiler面板连上真机跑一遍业务流程如果内存曲线只增不减而且每次退出某个页面后都不回落到之前的水平就很可能是泄漏了。如果曲线像锯齿一样反复升降但总体趋势平稳那大概率是正常的GC行为。接下来选择Memory选项的Dump Java Heap它会生成一个当前堆的hprof快照。Android Studio会帮你初步分析这个快照展示所有类的实例数量。重点看那些和Activity相关的类如果已经退出的Activity实例数量不为0说明有泄漏的嫌疑。双击类名还可以看到具体实例点击实例能看到它的引用链。顺着引用链找就能定位到是哪个对象持有它比如某个静态字段、某个单例、某条消息队列。这个方法虽然手工但它能找出那些还没被LeakCanary覆盖的隐藏泄漏。4.2 LeakCanary自动化泄漏检测谁泄漏抓谁LeakCanary是Square开源的一个内存泄漏检测库现在已经更新到了2.x版本。它的核心思路是在合适的时机主动触发GC然后利用一个弱引用去观察目标对象是否已经被回收。如果没有就说明对象被泄漏了然后它会自动分析hprof并给出怀疑的泄漏链。接入方式非常简单在build.gradle里加依赖debugImplementation com.squareup.leakcanary:leakcanary-android:2.14LeakCanary会自动注册一个ContentProvider完成初始化只需要在Debug依赖里加上正常运行不需要写任何初始化代码。它只在Debug环境生效Release包不包含这些逻辑所以不用担心性能损耗。触发泄漏检测后会用通知栏提示点进去可以看到完整的引用链比如“MainActivity - mHandler - Message - MessageQueue - Looper”这个链就是问题的答案。LeakCanary唯一的问题是它无法主动发现所有类型的泄漏因为它观察的是Activity和Fragment等特定生命周期对象。对于自定义ViewModel、第三方SDK内部持有、全局缓存的泄漏它不一定能覆盖。所以我的策略是“LeakCanary保底Memory Profiler深挖”以一主一辅的思路配合使用。4.3 MAT与Heap Dump分析从主导树看真凶如果LeakCanary给不出结论或者问题出在非Activity对象上就需要更偏原生的分析手段。先让Android Studio Dump一个hprof文件再把它转换成Eclipse MAT能识别的格式Android Studio上可以直接用自带分析器但MAT的功能更强大。MAT的Histogram视图可以看到各类型实例的数量和Shallow Heap/Retained Heap。Retained Heap就是某个对象被回收后连带能释放的内存大小排个序就能快速找到大块头。Dominator Tree主导树是MAT里非常重型的利器。它展示的是“如果我想回收这个对象这个对象能干倒哪一片”。基本上一旦你看到某个Activity的Retained Heap非常高那它就是整个泄漏链的终端节点。在Thread Details中还能看到后台线程的堆栈信息有助于定位是哪个线程持有了这个对象。分析时建议先找马再找线也就是先看谁占的内存最多再顺着引用链去看是谁在抓它。不要一上来就扎进大量实例的海洋里。5. 实战案例复盘三个典型泄漏场景的完整排查记录5.1 案例一Handler造成MainActivity迟迟不回收有一次我们线上监控到一个现象用户反复进入一个商品详情页18次之后内存曲线直接从200MB涨到500MB以上在低端机上出现了OOM。由于页面比较重型图片、图表、弹窗组件很多。但问题集中在一个十分不起眼的Handler上。定位过程是这样先用LeakCanary做一次回归测试按原始路径反复进出详情页等到通知栏弹出LeakTrace时看到的链路是“MainActivity - Leaking - Handler mHandle - Message target - MessageQueue mMessages”。也就是说Activity已经销毁但消息队列里还躺着这个Activity的Handler所post的任务。我们在代码里找到了这个Handler它不是主线程的Handler而是一个后台线程的Handler在线程池里反复提交延时任务。修复方式并不复杂把原先匿名内部类改成静态内部类WeakReference同时在onDestroy里调用handler.removeCallbacksAndMessages(null)并且在线程池的线程执行完任务后主动打断循环。改完之后再做回归测试内存曲线明显平稳不再持续爬升。这个案例最有价值的地方是它提醒了我们不要只盯着主线程的Handler线程池里面的Handler同样会持有Activity引用因为内部类持有外部类的原因和线程没关系。5.2 案例二单例里藏着一个Activity Context另一个项目里崩溃统计平台发现首页在低端机频繁出现OOM。我们一开始怀疑是图片问题把图片加载框架的配置调低以后好转了一阵但问题依然存在。后来在Dump Heap时发现首页Activity掉到后台以后实例数始终不为0而且用MAT的Dominator Tree看首页的Context被一个叫AppShareManager的类一眼顶住。查看代码后发现AppShareManager是一个单例它初始化时需要传入一个Context当时写代码的同事直接从某个Activity里传了this然后保存在了一个静态字段里。虽然单例本身逻辑不复杂但这个静态field让整个Activity都吊在了应用进程的生命周期上。修复方法非常简单把这个Context传入改为context.getApplicationContext()或者将单例的初始化方法改为内部持有Application的Context问题就彻底消失了。这种问题之所以容易忽略是因为它不像Handler那样有明显的任务队列可以看出来。单例模式下只要一个入口传错了Context后面的调用全部被污染。建议在团队规范里约定工具类、SDK初始化所使用的Context统一从Application获取业务页面里的Context不要外传出自己所在的生命周期范围。5.3 案例三Activity中的静态View泄漏第三个案例稍微冷门一点有个开发者为了快速实现“双击返回键退出”的功能在Activity里维护了一个静态的Toast或者一个静态的View变量。为了省事他直接在代码里写了private static TextView sErrorView;这个sErrorView持有的是Activity布局内的TextView而TextView又持有Activity的Window和Context。一旦这个Activity被销毁sErrorView依然通过静态字段存活那么整个Activity的View树都会挂在静态字段上导致Activity无法回收。这类静态字段泄漏在处理相机预览、播放器View、图表View时特别容易出现。分析下来发现这个模式本质上是用静态变量延长了View的生命周期让它“看起来像是一个全局变量”。但View系统本身的生命周期是跟着Activity走的强行分开就会在内部形成强引用链。修复方式也很直接去掉static修饰改为实例变量如果确实需要在多个页面共享同一个View那也应该把它挂在Application级别的容器中或者使用独立的Window样式来承载而不是从一个已销毁的Activity中拿View。这个案例的教训是内存泄漏不一定都来自复杂的框架交互有时候就是写代码时图一时方便留下一个坑。6. 避坑指南从代码习惯上远离内存泄漏6.1 生命周期感知绑定与解绑永远是成对的做Android开发一定要把“生命周期”刻在脑子里。无论是Handler还是Listener还是BroadcastReceiver只要你在onCreate或者onResume里做了绑定就必须在对应的onDestroy或onPause里做解绑。我个人的习惯是使用AndroidX提供的Lifecycle组件让组件自己去感知生命周期。比如用LifecycleEventObserver在ON_DESTROY时自动清理这样就不容易遗漏。还有一个常见的误区和Lifecycle有关很多人以为onDestroy执行了Activity就一定会被回收。这不对onDestroy只是一个生命周期回调它执行完只代表视图被剥离不代表Java对象可以被GC。只有没有外部引用链时对象才会被回收。所以onDestroy里如果不做清理只靠系统自己释放就会给内存泄漏留下机会。6.2 善用ViewModel与协程用官方组件减少手动管理Google推出的ViewModel组件对内存泄漏是一个很大的帮助。ViewModel的生命周期天然和Activity/Fragment的实例分离在配置变更时会挺过Activity的销毁重建在业务不需要时自动清理。它内部使用持有者模式在ViewModelStore层面管理生命周期可以避免一部分因异步任务持有Activity引用导致的泄漏。对于网络请求和后台任务尽量使用Kotlin协程并且把协程的作用域绑定到ViewModel的viewModelScope或Lifecycle的repeatOnLifecycle上。页面销毁时协程会被统一取消不会出现线程跑到一半还抓着Activity引用的问题。我自己从HandlerThread迁移到协程之后内存泄漏相关的线上问题数量少了一大半这算是最直接的体会。6.3 建立常态化检测机制让问题在开发阶段就暴露千万不要等线上OOM爆发了才开始排查那个成本太高了。我的建议是在项目的Debug模式下强制集成LeakCanary并且在CI流水线里加上内存泄漏的检测任务。比如每次合并代码前跑一遍内存泄漏回归用例发现新的泄漏就fail掉构建。LeakCanary本身提供了LeakCanary.config来配置分析回调可以配合穿山甲、Bugly等监控体系把泄漏Trace上报到后台方便集中分析。团队内部还可以维护一个“泄漏黑名单文档”把历史上的每一个泄漏案例、根因、修复方式、涉及类名都记录在案。新的开发者接手项目后先看这份文档能有效避免重复踩坑。我见过很多团队在LeakCanary报出泄漏后只是简单改掉一个字段却没有追溯根因结果过阵子换个写法又出现同类问题。这不叫修复只能叫表面应付。最后再分享两个很实用的排查小技巧第一在用Memory Profiler的Dump Java Heap时记得先强制触发一次GC然后再Dump。原因是堆里可能还残留着一些已经不可达但尚未被清理的对象这些对象会干扰你的判断。操作路径是Profiler面板里点击“Force Garbage Collection”按钮等曲线回落后再点“Dump Java Heap”。第二很多泄漏排查不出来是因为复现路径不固定。建议写一个自动化的“泄漏复现测试”用Espresso或者Compose Test遍历页面打开-退出-再打开-再退出循环操作二十几次同时记录内存趋势。这个方法能快速把偶发问题变成必现问题后面定位的效率会高很多。根据我个人的经验内存泄漏排查最花费时间的往往不是找根因的过程而是复现路径的确认和堆快照的解读。只要思路清晰、工具得当绝大多数泄漏其实都能在短时间内定位出来。希望这篇文章能帮你在内存优化的路上少踩一些坑。
