Activity内存泄漏时包含的view还有没有的救？

Activity泄漏会导致该Activity引用到的Bitmap、DrawingCache等无法释放，对内存造成大的压力，兜底回收是指对于已泄漏Activity，尝试回收其持有的资源，泄漏的仅仅是一个Activity空壳，从而降低对内存的压力。做法也非常简单，在Activity onDestory时候从view的rootview开始，递归释放所有子view涉及的图片，背景，DrawingCache，监听器等等资源，让Activity成为一个不占资源的空壳，泄露了也不会导致图片资源被持有。

…
 …
 Drawable d = iv.getDrawable();
 if (d != null) {
 d.setCallback(null);
 } 
 iv.setImageDrawable(null);
 ...
 ...

在不保证项目不出现内存泄漏的问题的情况下，保底回收Activity或者Fragment中的所有drawable，内存这个东西嘛，能救回来一点是一点。

这里的题外话，不是说内存泄漏的检测不重要，在聊起来的时候总有人跟我说起来不是应该去解决内存泄漏吗？为什么要搞这个。如果你能保证你的项目在经过多年迭代、重构、不同水平层次的开发人员维护、后半夜上线不清醒的情况下修改点什么东西等等等等，这样的情况下保证一点内存泄漏的问题都没有的话，那当然当我没说。

这里做的处理是检测到Activity或者Fragment leaking之后，遍历所有持有的子view，释放占内存大户也就是view持有的图片背景资源，当然不限于drawable，如果还持有一些其他的该释放但是未释放的比如播放器资源，文件句柄文件流网络流也是可以根据情况来释放掉的。

说道这里其实我们可以提出一些疑问：

上述方案是在确定泄露的情况下做的，如何检测内存泄漏？
为什么不直接释放view而是释放掉drawable？

如何检测内存泄漏

说起检测内存泄漏就不能不提leakcanary，腾讯的Matrix的内存泄漏也是借鉴的它的原理。这里只简单剖析原理并实现一个最简单的leaking检测，不涉及到hprof的获取与分析。

leakcanary的原理

onDestroy的时候通过ReferenceQueue创建WeakReference，并为它设置一个Key，存到Set中。
等待5s后尝试从ReferenceQueue中查找此WeakReference，找到就从Set中移除，不成功则GC后再试一次。
查看此Key是否还在Set中存在，如果存在则认为是泄漏。

上述的步骤就是它检测内存泄漏的工作原理，使用了带ReferenceQueue的WeakReference的构造方法来创建弱引用，当目标对象只有WeakReference持有的情况下就可以被GC回收，回收之后会放到ReferenceQueue中。所以只要检测会不会出现在ReferenceQueue中就知道有没有被回收。

最简单的leakcanary工程

根据上面的leakcanary的原理，我们可以实现一个最简单的leakcanary，用来检测某个对象的内存泄漏，这个对象可以不止是activity，也可以是其他的对象比如包含的view或者drawable是否有泄漏，这样一个工具可以对我们本篇文章中的内容做实践上的支持。
主要的核心代码如下：

public class RefWatcher {
    private final GcTrigger gcTrigger;
    private final Set<String> retainedKeys;
    private final ReferenceQueue<Object> queue;

    public RefWatcher() {
        retainedKeys = new CopyOnWriteArraySet<>();
        queue = new ReferenceQueue<>();
        this.gcTrigger = GcTrigger.DEFAULT;
    }

// Activity destory的时候调用此方法，用来观察目标对象是否回收
    public void watch(Object watchedReference, final String referenceName) {
        final long watchStartNanoTime = System.nanoTime();
        String key = UUID.randomUUID().toString();
        retainedKeys.add(key);
        final KeyedWeakReference reference = new KeyedWeakReference(watchedReference, key, referenceName, queue);
        new Handler().postDelayed(new Runnable() {
            @Override
            public void run() {
                ensureGone(reference, referenceName, watchStartNanoTime);
            }
        }, 5000);
    }

    void ensureGone(final KeyedWeakReference reference, String referenceName, final long watchStartNanoTime) {
        long gcStartNanoTime = System.nanoTime();
        long watchDurationMs = NANOSECONDS.toMillis(gcStartNanoTime - watchStartNanoTime);

        removeWeaklyReachableReferences();

        if (gone(reference)) {
            return;
        }
        gcTrigger.runGc();
        removeWeaklyReachableReferences();
        if (!gone(reference)) {
            //do HeapDump, HeapAnalyzer
        }
        return;
    }

    private boolean gone(KeyedWeakReference reference) {
        return !retainedKeys.contains(reference.key);
    }

    private void removeWeaklyReachableReferences() {
// 因为一旦一个对象只有当前类中的弱引用持有的情况下，gc的时候会回收掉这个对象并且对象会被放到queue中，如果queue中有对象说明此对象已经被回收了，从retainedKeys中移除掉。
        KeyedWeakReference ref;
        while ((ref = (KeyedWeakReference) queue.poll()) != null) {
            retainedKeys.remove(ref.key);
        }
    }
}

原理上面说的很清晰了，可以结合代码中的注释加深理解。
更加详细的代码可以查看 SimpleLeakCanary，可以直接clone下来run一下。

同样可以用来检测回收drawable代码是否有效，具体可以查看 DrawableRefWatcher 。针对activity中的某一个drawable，在加了上面回收drawable的代码和不加的情况下看针对drawable的内存泄漏是否有效。

为什么不直接释放view

上面的解决方案是在内存泄漏发生的时候回收释放activity中所有的drawable来实现的。其实我们很容易就想到，为什么不直接释放view而要去释放drawable呢？

我们盲猜，那肯定是因为释放drawable容易，因为drawable的引用链比较单一，无非是有个view引用了这个drawable导致它无法释放。
那如果是view呢？它的引用链是什么样的呢？我们怎么能看到一个view的GC引用链呢？

MAT的使用

MAT是个很好的工具，下载链接在 Memory Analyzer (MAT)，其实用过eclipse开发Android的年代，很多人应该对他都很熟悉，这里不详细介绍它的用法，更详细的用法可以来看 高爷的 Android 内存优化 (1) - MAT 使用入门 ，可以看到更多高阶的MAT的用法。

我这里只是抛砖引玉，针对使用MAT如何查看一个view的所有引用路径。

找一个目标view，我这里使用了一个自定义view叫TestLeakingView，这样可以更方便的在MAT中定位它。
dump一份内存快照，可以用AndroidStudio的profiler，在左侧点Capture heap dump，等一两秒会生成一份内存快照文件。

将AndroidStudio生成的hprof文件转换成MAT使用的标准格式，可以借助Android SDK下的hprof-conv工具来做转换，我mac下目录为/Users/yocn/Library/Android/sdk/platform-tools/hprof-conv，用法为 hprof-conv in.hprof out.hprof，得到的out.hprof就是标准的hprof文件

如果找不到自己的SDK目录，可以使用where命令来查找，能看到如下的结果：

使用MAT打开转换之后的标准hprof文件。

这也不展开MAT的用法或者兼容性问题，提醒mac最新版MAT需要java-11，在显示包内容 -> Contents -> Info.plist 文件中配置成自己的java11的路径。

<string>-vm</string><string>/Library/Java/JavaVirtualMachines/jdk-11.jdk/Contents/Home/bin/java</string>

这里打开dominator_tree，找到我们自定义的TestLeakingView，右键找到Merge Shortest Path to GC root，选择with all references可以看到下图：

RenderNode是硬件加速相关的类，可以参考 使用Android RenderNode加速绘制

可以看到单个view起码被以上的几条路径引用，包括window中的view树，上下文context的引用。这些都是framework控制和显示view的基础，所以还是很难做剥离的。

释放view的尝试

其实我看到上面的view的引用的时候也是尝试过一些view的释放。按照上面的引用路径做一些尝试：

从view树中移除
移除mContext引用

效果其实不是很理想，这里不赘述尝试的方法，尤其是高版本的Android做了一些hide的API和反射方法的限制之后，其实这些尝试没有什么意义，只是作为思路上的发散，做一些可能性上的探索，如此而已。

总结：

内存泄漏下兜底方案释放drawable是可行的，可以选择性的使用此方案
leakcanary借助了ReferenceQueue来做内存泄漏的检测
可以自己实现leakcanary用来做更小粒度的对象的内存泄漏的检测，比如view或者drawable
使用MAT来检测view的引用链，解释为什么释放drawable而不是view
是否可以做view的内存泄漏释放思路的发散及探索