1.x版本
使用
debugCompile 'com.squareup.leakcanary:leakcanary-android:1.3'
releaseCompile 'com.squareup.leakcanary:leakcanary-android-no-op:1.3'
public class MyApplication extends Application {
@Override
public void onCreate() {
super.onCreate();
LeakCanary.install(this)
}
}
源码
1.LeakCanary是怎么做到install之后自动监测Activity的？
调用install后，会注册一个Activity生命周期的回调监听，registerActivityLifecycleCallbacks，来绑定Activity生命周期，在Activity执行onDestroy时，调用watch方法开始检测当前页面是否存在内存泄漏，并分析结果（如果想要在非Activity如Fragment检测是否存在内存泄漏，需要手动添加，调用watch方法）
2.如何判定Activity是否发生了内存泄漏
KeyedWeakReference与ReferenceQueue联合使用，将onDestroy的Activity对象包裹成一个弱引用对象（KeyedWeakReference），开启异步线程，在弱引用关联的对象被回收后，会将引用添加到ReferenceQueue；通过这一点特性来判定对象是否被回收；先判断一次，如果对象未回收旧手动触发GC, 然后再次判断，采用双重判定来确保当前引用是否被回收的状态正确性；如果两次都未回收，则确定为泄漏对象。
3.内存泄漏轨迹是如何生成的
采用eclipse.Mat来分析泄漏详细，从GCRoot开始逐步生成引用轨迹。
4.内存分析是在单独的进程执行的吗，为什么？
内存分析模块是在独立进程中执行的，这么设计是为了保证内存分析过程不会对App进程造成消极的影响
5.检测是否发生泄漏是在主线程还是子线程
开启了一个子线程检测的
5.Leak Canary核心类及其作用
1.DisplayLeakActivity
内存泄漏的查看页面
2.HeapAnalyzerService
内存堆分析服务， 为了保证App进程不会因此受影响变慢&内存溢出，运行于独立的进程
3.HeapAnalyzer
分析由RefWatcher生成的堆转储信息， 验证内存泄漏是否真实存在
4.HeapDump
堆转储信息类，存储堆转储的相关信息
5.ServiceHeapDumpListener
一个监听，包含了开启分析的方法
6.RefWatcher
核心类， 翻译自官方： 检测不可达引用（可能地），当发现不可达引用时，它会触发
7.HeapDumper
(堆信息转储)
8.ActivityRefWatcher
Activity引用检测， 包含了Activity生命周期的监听执行与停止
2.x版本
LeakCanary 2.0及以上版本做了代码重构，完全使用kotlin实现，同时在使用上也做了优化。以前的版本集成的时候需要我们手动在application调用接口安装，而新版本优化后是通过ContentProvider自动实现初始化的，使开发者完全无感知，这是对开发者更加友好的一点变化。另外一点，旧版本如果要监听fragment的回收，需要我们手动调用接口，但是新版本也实现了初始化时对fragment的监听。
言归正传，不管代码重构如何进行，监控内存泄漏的核心原理还是不变的。无论是监控Activity还是监控Fragment，首先都是要在对象销毁的时候拿到这个对象，那么两者都是怎么拿的？
Activity:
通过application.registerActivityLifecycleCallbacks监听Activity生命周期，在onDestroy回调中拿到Activity应用，这个方法用的很多了。
Fragment：
针对不同版本（Android O 8.0以上或以下），不同类型的fragment（android x或者support类型），虽然后处理细节有些不同，但都是通过fragmentManager监听fragment生命周期，fragmentManager.registerFragmentLifecycleCallbacks，也就可以得到生命周期的回调，在onFragmentViewDestroyed中可以监听fragment中view的回收，在onFragmentDestroyed监听fragment对象的回收。
得到Activity或者Fragment的对象后，处理逻辑是一致的，接下来进入LeakCanary最核心的原理部分。
核心原理
1.当Activity或者Fragment销毁后，获取到他们的引用，将引用封装到一个弱引用类型的对象中，并关联引用队列，利用弱引用的特性：WeakReference引用的对象如果被Gc回收，那么这个弱引用会被加入引用队列中。
2.封装成弱引用后，等待5s(默认)，去检查弱引用有没有被加入引用队列（细节上用了一个巧妙的方式），如果加入了，说明被回收了，没有发生内存泄漏；如果没有加入，就可能有内存泄漏要发生。这时会手动触发一次Gc,然后再用同样的方式检查引用队列，如果被回收了，结束。如果仍然没有被回收，那就要通过Debug.dumpHprofData进行堆转储并写入到文件，启动一个服务分析heap dump文件，找到Gc Roots引用路径展现给用户。
细节上用了一个巧妙的方式: 借助一个map来同时存储弱引用KeyedWeakReference，相当于ReferenceQueue和map两个数据结构都存储了这个KeyedWeakReference。当要判断是否发生泄漏时，遍历清空ReferenceQueue，同时把ReferenceQueue清掉的对象从map中也移除，如果对象被回收，弱引用会被加入到ReferenceQueue，那么也就是被回收的都被清理了，剩下的都是没有被清理的。这个时候再判断map中是否有这个引用，如果没有，说明没有发生泄漏，如果还在，说明它对应的引用没有被加入ReferenceQueue，也就是发生了泄漏。
