LeakCanary分析，如何判定的内存泄漏说明

1.解决的问题

用来有效的检测出Android项目中的内存泄漏

2.大体框架结构

leakcanary-watcher: 这是一个通用的内存检测器，对外提供一个 RefWatcher#watch(Object watchedReference),它不仅能够检测Activity，还能监测任意常规的 Java Object 的泄漏情况。

leakcanary-android: 这个 module 是与 Android 的接入点，用来专门监测 Activity 的泄漏情况，内部使用了 application#registerActivityLifecycleCallbacks 方法来监听 onDestory 事件，然后利用 leakcanary-watcher 来进行弱引用＋手动 GC 机制进行监控。

leakcanary-analyzer: 这个 module 提供了 HeapAnalyzer，用来对 dump 出来的内存进行分析并返回内存分析结果AnalysisResult，内部包含了泄漏发生的路径等信息供开发者寻找定位。

leakcanary-android-no-op: 这个 module 是专门给 release 的版本用的，内部只提供了两个完全空白的类 LeakCanary 和 RefWatcher，这两个类不会做任何内存泄漏相关的分析。因为 LeakCanary 本身会由于不断 gc 影响到 app 本身的运行，而且主要用于开发阶段的内存泄漏检测。因此对于 release 则可以 disable 所有泄漏分析。

3.核心点是怎么实现的

原理：
LeakCanary的原理非常简单。正常情况下一个Activity在执行Destroy之后就要销毁，LeakCanary做的就是在一个Activity Destroy之后将它放在一个WeakReference中，然后将这个WeakReference关联到一个ReferenceQueue，查看ReferenceQueue是否存在Activity的引用，如果不在这个队列中，执行一些GC清洗操作，再次查看。如果不存在则证明该Activity泄漏了，之后Dump出heap信息，并用haha这个开源库去分析泄漏路径。

理解ReferenceQueue的作用： 使用ReferenceQueue清除失去了软引用对象的SoftReference 作为一个Java对象，SoftReference对象除了具有保存软引用的特殊性之外，也具有Java对象的一般性。所以，当软可及对象被回收之后，虽然这个SoftReference对象的get()方法返回null,但这个SoftReference对象已经不再具有存在的价值，需要一个适当的清除机制，避免大量SoftReference对象带来的内存泄漏。 在java.lang.ref包里还提供了ReferenceQueue。如果在创建SoftReference对象的时候，使用了一个ReferenceQueue对象作为参数提供给SoftReference的构造方法，如: 1. ReferenceQueue queue = new ReferenceQueue(); 2. SoftReference ref=new SoftReference(aMyObject, queue); 那么当这个SoftReference所软引用的aMyOhject被垃圾收集器回收的同时，ref所强引用的SoftReference对象被列入ReferenceQueue。也就是说，ReferenceQueue中保存的对象是Reference对象，而且是已经失去了它所软引用的对象的Reference对象。另外从ReferenceQueue这个名字也可以看出，它是一个队列，当我们调用它的poll()方法的时候，如果这个队列中不是空队列，那么将返回队列前面的那个Reference对象。