今天来写一波内存泄漏工具LeakCanary的分析，也整理一下之前的笔记，废话不多说，源码整起来。
我用的1.5.1版本。
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页面上。
最后还是弱引用基础知识的应用，所以说为什么大厂喜欢问基础知识，其实很多东西都是构建在基础知识之上。
关于gc的补充点
这里补充一点东西，也是之前被某厂问到了，当时没答出来的，主要是之前没看那么细，后面又翻了一下源码。
当时问的是上面gc的时候，是怎么gc的？第二次removeWeaklyReachableReferences是什么时候触发的？
当时想的是gc不都是System.gc嘛，还能有什么骚操作？回来打开一下源码，咦，发现还真有。。
那从GCTrigger入手了。
发现runGc里面不是直接调用System.gc的，用了一个Runtime.getRuntime().gc(),这是啥？
然后看见上面一堆注释还贴了源码url，觉得事情很重要，静下心来用我多年修炼来的四级的英语阅读能力扫了一遍。
简单来说就是，作者从AOSP那里Ctrl+c来了一段代码，因为System.gc()不能保证每次gc而Runtime.gc()会相对更可靠。
然后调用了enqueuReferences方法，里面就直接sleep了100ms，简单粗暴。。作者对于此的解释是没有很好能够获取到对象真正加入到队列的时机，所以直接等100ms让回收，100ms后执行runFinalization，然后就可以去第二次remove。
好家伙一个类就解答了两个问题，核心流程写完了，这次先写到这里，第一次用掘金，不知道掘金文章支不支持后续编辑，后续再补充一波
谢谢，朋友们
