一、什么是LeakCanary？
LeakCanary就是用来检测Android端内存泄漏的一个工具。能够检测Activity的泄漏
什么是内存泄漏？
Java 对象有时也会”长死不死“，GC 拿它没有办法，这种情况就是内存泄漏。造成这种情况的原因是：Java 对象被另一个生命周期更长对象持有，具有 可达性 ，这并不是我们想要的。
来自 <http://www.jianshu.com/p/3f1a1cc1e964>
内存泄漏的危害？
内存泄漏最终将导致内存溢出，也就是OOM，并且OOM发生在某一处，并不代表问题就是出在那里的，只是刚好有一块内存申请，此时内存又不够了才导致的，比较容易出现在申请比较大的内存的情况下。但是把这块申请的内存降低并不能从根本上解决问题。
这里有一个问题就是：内存的分配方式，分配位置，比如BitMap的分配，以及其他对象的分配？以及Activity对对象的持有，这个概念还不是很清晰。
github上的地址：https://github.com/square/leakcanary
一个原理的介绍内容在这里：
https://www.liaohuqiu.net/cn/posts/leak-canary/
https://www.liaohuqiu.net/cn/posts/leak-canary-read-me/
二、LeakCanary的工作原理是什么？
这三个都有讲解，并且还有直接通过源码来进行讲解的，后面可以针对这块，针对源码专门研究一下。
http://www.jianshu.com/p/a8900eb3de12
http://www.jianshu.com/p/5ee6b471970e
http://www.jianshu.com/p/3f1a1cc1e964
工作原理是：
LeakCanary会开启一个Service，这个Service能够在一个Activity被OnDestory之后，检测是否真的还有这个对象，如果还有，会尝试进行二次确认，如果这个对象还是没有被释放掉，则会获取当时的内存状态，生成一个heap的状态文件，然后分析文件，计算这个对象的GC ROOT的最短强引用路径，确定是否泄漏，如果有泄漏，Leak的APP就会有一条通知栏消息出现
检测流程图如下：
三、如何使用
1、在build.gradle中引入：
debugCompile ‘com.squareup.leakcanary:leakcanary-android:1.3.1‘ // or 1.4-beta1
releaseCompile ‘com.squareup.leakcanary:leakcanary-android-no-op:1.3.1‘ // or 1.4-beta1
testCompile ‘com.squareup.leakcanary:leakcanary-android-no-op:1.3.1‘ // or 1.4-beta1
或者，现在最新的1.5.1的也可以直接用：
dependencies{
compile‘com.squareup.leakcanary:leakcanary-android:1.5.1‘
}
2、同时，在Application的方法，在OnCreate中添加install
public class DemoApplication extends Application {
@Override public void onCreate() {
super.onCreate();
LeakCanary.install(this);
}
}
3、在添加之后，直接打出来应用的包，装上之后，会看到有一个附属应用出来，名字叫做Leaks
4、直接操作APP，如果发现有内存泄漏，则这个过程中会有通知栏提示，点击查看即可，可以将泄漏的信息分享，也可以将当时的heap dump的信息分享出来（但有可能这个heap dump不一定存在）
以检测出来的一个图为例：
LeakCanary的内存泄露提示一般会包含三个部分:
第一部分(LeakSingle类的sInstance变量)引用第二部分(LeakSingle类的mContext变量), 导致第三部分(MainActivity类的实例instance)泄露.
下方是一些更详细的原理的讲解：
1、不同的几种引用方式：强-软-弱-虚
2、LeakCanary这里，有一个原理的讲解叫做：
需要理解为什么要用WeakReference，因为GC的时候是不会对强引用的做处理，而软引用的是在内存不够用了才会被回收，而弱引用就是可以随时回收，所以需要用WeakReference对待检测的对象进行包裹引用，因为是弱引用的，因此在待检测对象调用了Destory或者Finish方法之后，被WeakReference引用的对象的生命周期结束，因为这个是弱引用，就会被GC检测到，这个时候GC会把该对象添加到ReferenceQueue中，如果GC结束该对象还是没有被加入到ReferenceQueue中，则说明可能存在内存泄漏，其实就是找到所有生命周期结束的对象，过滤掉会被回收的，剩下就是没有被回收的，然后会做二次GC，之后还是没有回收，就可以找到当时的内存状态，拿到不同对象的引用情况，得到一个hprof的文件，之后就能找到最短强引用的路径。
解决内存泄漏，通过以下方式：
然后我们需要解决：如何得到未被回收的对象。ReferenceQueue+WeakReference+手动调用 GC可实现这个需求。
- WeakReference 创建时，传入一个 ReferenceQueue 对象。当被 WeakReference 引用的对象的生命周期结束，一旦被 GC 检查到，GC 将会把该对象添加到 ReferenceQueue 中，待ReferenceQueue处理。当 GC 过后对象一直不被加入 ReferenceQueue，它可能存在内存泄漏。
获得未被回收的 Object
- 找到了未被回收的对象，如何确认是否真的内存泄漏？这里可以将问题转换为：未被回收的对象，是否被其他对象引用？找出其最短引用链。VMDebug + HAHA 完成需求。
VM 会有堆内各个对象的引用情况，并能以hprof文件导出。HAHA 是一个由 square 开源的 Android 堆分析库，分析 hprof 文件生成Snapshot对象。Snapshot用以查询对象的最短引用链。
解析hprof
- 找到最短引用链后，定位问题，排查代码将会事半功倍。
如下泳道图分析， LeakCanary 各个模块如何配合达到检测目的。
来自 <http://www.jianshu.com/p/3f1a1cc1e964>