LeakCanary核心源码解析

---

看源码还是那句话，先找入口，顺着入口看主流程。

LeakCanary监听Activity的onDestory方法，然后介入，所以从这里开始

发现入口在RefWatcher.watch方法里，这个RefWatcher是核心类，跟进去watch方法。

可以看出这里开始搞事情了，先解释一下这些变量的意义

这样就可以解释，上图watch方法里面的操作了

使用randomUUID生成一个随机数key，并加到了一个set中，这个key跟当前监控的activity是一一对应的，这个很关键，watchedReference就是当前关闭的activity对象，然后包装成KeyedWeakReference对象，KeyedWeakReference继承了WeakReference。

后续就是就操作这个KeyedWeakReference这个弱引用。

到了这里就不得不提一下，强软弱虚这四个东西，如果还有不懂的小伙伴，还是要去看一下的，这里只提一下弱引用，简单来说就是。

弱引用持有的对象被回收了，那么弱引用就会放到与之关联的引用队列中。

？？？

讲人话！那举个栗子

就是上面watch方法的watchedReference(就是那个被监测的activity)被KeyedWeakReference弱引用持有了，当activity被回收了，RefWatcher#queue里面就会有这个KeyedWeakReference。

反之如果一顿操作之后queue都没有这个KeyedWeakReference，说明activity没有被回收，那么就判定为内存泄漏。

这也是LeakCanary的核心思想。

好，接着watch方法往下走，ensureGoneAsync方法跟进去到一个ensureGone的核心方法里

红框这里是核心中的核心。看起来很短，但浓缩才是精华。

removeWeaklyReachableReferences方法里就是遍历把引用队列queue里的对象，在retainsKeys这个set里面移除掉。

讲了半天，还记得开头这个retainsKeys放的什么吗？是那个UUID生成的与每个activity一一对应的key，可以理解为activity对应的一个值。当队列有一个弱引用了，说明有一个对应activity被回收了。

gone方法里判断retainsKeys集合里还有没有这个activity对应的值，没有说明正常回收了。

ensureGone的整个流程基本就清楚了，理一下ensureGone的流程。

首先根据队列的对象，移除对应set里对应的key值，gone判断是否移除成功，成功返回DONE，没有泄露结束流程，gone判断还存在，原谅ta再给一次机会，调用runGc触发回收，再次移除key值，gone判断还存在，不好意思，没有机会了，使用heapDumper.dumpHeap出调用链，showNotification展示到通知栏，最后展示到DisplayLeakActivity页面上。

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化学习资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

dn.net/topics/618156601)**

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！