Android---内存泄漏的优化

内存泄漏是一个隐形炸弹，其本身并不会造成程序异常，但是随着量的增长会导致其他各种并发症：OOM，UI 卡顿等。

为什么要将 Activity 单独做预防？

因为 Activity 承担了与用户交互的职责，因此内部需要持有大量的资源引用以及与系统交互的 Context，这会导致一个 Activity 对象的 retained size 特别大。一旦 Activity 因为被外部系统所持有而导致内存泄漏，会牵连导致其他对象的内存泄漏也会非常多。

造成 Activity 内存泄漏的场景

1)将 Context 或者 View 置为 static

View 默认会持有一个 context 的引用，如果将其设置为 static，将会照成 view 在方法区中无法被快速回收，最终导致 Activity 内存泄漏。上图中的 ImvageView 会造成 ActivityB 无法被 GC 回收。

2）未解注册各种 Listener

在 Activity 中可能会注册各种系统监听器，比如广播。运行上述 ActivityC 然后按下返回键，控制台将会显示如下 log，提示有内存泄漏发生。

3）非静态 Handler 导致 Activity 泄漏

上述代码中的 Handler 也会造成 ActivityD 发生内存泄漏。一般需要将其置为 static，然后内部持有一个 Activity 的弱引用来避免内存泄漏。如下所示

4）第三库使用 Context

在项目中经常会使用各种第三方库，有些第三方库的初始化需要我们传入一个 context 对象。但是第三方库中很有可能一直持有此 context 的引用。上述代码中，将ActivityE 本身当做了一个 context 传递给了一个模拟的第三方库 ThirdParty 中。但是，在第三方库中将传入的 context 重新置为一个静态的 static 类型。这种情况是一个隐形的 Activity 泄漏，在我们自己的项目中很难查出。所以，在开发过程中尽量使用 Context.getApplicationContext，不要直接将 Activity 传递给其它组件。

内存泄漏检测

在开发阶段可以直接使用 Android Studio 来查看 Activity 是否存在内存泄漏，并结合 MAT 来查看发生内存泄漏的具体对象。详细使用过程可以参考：Android Studio 和 MAT 结合使用来分析内存问题

LeakCanary

除了 Android Studio，另一检测内存泄漏的神器就是 LeakCannary。LeakCanary 是 Square 公司的一个开源库，通过它可以在 App 运行过程中检测内存泄漏。当内存泄漏发生时会生成发生泄漏对象的引用链，并通知程序开发人员。LeakCanary 主要分2大核心部分：

1）如何检测内存泄漏；

2）分析内存泄漏对象的引用链。

如何检测内存泄漏---JVM理论知识

Java 中的 WeakReference 是弱引用类型，每当发生 GC 时，它所持有的对象，如果没有被其它强引用持有，那么它所引用的对象就会被回收。比如以下代码

上述代码执行过后，打印如下

可以看出，BigObject 并没有被其它强引用所持有，所以在 GC 回收后，WeakReference 所持有的 BigObject 对象被回收了。

WeakReference 的构造函数可以传入一个 ReferenceQueue，当 WeakReference 指向的对象被垃圾回收器回收时，会把 WeakReference 放入 ReferenceQueue 中，如下所示

上述代码调用 WeakReference 的构造器时传入一个自定义的 ReferenceQueue，那么打印结果如下

可以看出，当 BigObject 被回收之后，WeakReference 会被添加到所传入的 ReferenceQueue 中。

在修改一下上述代码，模拟一个内存泄漏。如下代码所示

BigObject 是一个强引用，导致 new BigObject 的内存空间不会被 GC 回收。最终打印结果如下

LeakCanary 实现思路

LeakCanary 中对内存泄漏检测的核心原理就是基于 WeakReference 和 ReferenceQueue 实现的

$\bullet$ 当一个 Activity 需要被回收时，就将其包装到一个 WeakReference 中。并且在 WeakReference 的构造器中传入自定义的 ReferenceQueue；

$\bullet$ 给包装后的 WeakReference 做一个标记 Key，并且在一个强引用 Set 中添加相应的 Key 记录；

$\bullet$ 主动触发 GC，遍历自定义 ReferenceQueue 中所有的记录，并根据获取的 Reference 对象将 Set 中的记录也删除。

经过上面3步，还保留在 Set 中的就是：应当被 GC 回收，但实际还保留在内存中的对象，也就是发生泄漏的对象。

源码分析

在上面原理介绍的例子里，一个可回收的对象在 System.gc() 之后就应该被 GC 回收。可是，在 Android App 中，我们并不清楚系统何时会回收 Activity。按照正常流程，当 Activity 调用 onDestory 方法时就说明这个 Activity 就已经处于无用状态了。因此需要监听到每一个 Activity 的 onDestory 方法的调用。

ActivityRefWatch

LeakCanary 中监听 Activity 生命周期是由 ActivityRefWatch 来负责的。主要是通过注册 Android 系统提供的 lifecycleCallbacks 来监听 Activity 生命周期方法的调用。如下所示

lifecycleCallbacks 的具体代码如下

可以看出当监听到 Activity 的 onDestory() 方法后，会将其传给 refWatcher 的 watch() 方法

RefWatcher

RefWatcher 它是 LeakCanary 的一个核心类，用来检测一个对象是否会发生内存泄漏。主要实现是在 watch() 方法中，如下代码所示

图中1处生成一个随机的字符串 key，这个 key 就是用来标识 WeakReference 的，就相当于给 WeakReference 打了一个标签。图中2处将一个被检测对象包装的 WeakReference 中，并将其标识为步骤1中生成的 key。图中3处调用 ensureGoneAsync 开始执行检测操作，因此关键代码就是在 ensureGoneAsync 中。代码如下

通过 WatchExecutor 执行了一个重载的方法 ensureGone。ensureGone中实现了内存泄漏的检测

图中1处会遍历 ReferenceQueue 中的所有元素，并根据每个元素中的 key 相应的将集合 retainedKeys 中的元素也删除；图中2处判断集合 retainedKeys 是否还包含被检测对象的弱引用。如果包含，说明被检测对象并没有被回收，也就是发生了内存泄漏。图中3处生成 heap 堆信息，并生成内存泄漏的分析报告，上报给程序开发人员。

removeWeaklyReachableReferences() 方法如下