LeakCanary 原理浅析
自顶向下，用图简化，不落代码陷阱，不入细节迷障。
Android 应用内存泄漏问题，一直是性能优化的重点。在不清楚内存泄漏的大致范围时，通过人为测试模拟重现或无目的地分析 heap dump等方法来检测，都太繁琐、耗时且定位不准。
什么是内存泄漏？
在 Java 世界中，一切对象都有生命周期，如同人的寿命。人死灯灭，入轮回，转世投胎。Java 对象的生命周期结束后，将被 GC 回收，原先占用的内存会有新的用途。但凡是总有例外，就如孙悟空可以修改生死谱长生不死，聂小倩能残存人间人鬼相恋。Java 对象有时也会”长死不死“，GC 拿它没有办法，这种情况就是内存泄漏。造成这种情况的原因是：Java 对象被另一个生命周期更长对象持有，具有 可达性 ，这并不是我们想要的。
问：有没有一种简单直接且能有效定位内存泄漏位置的方法呢？
答：有，那就是 LeakCanary 。我们可以简单地人为：将一个 App 作为输入，通过LeakCanary 检测后，就会得到内存泄漏位置结果（如果存在的话）。
知其然知其所以然，LeakCanary 如此强大实用，那么：LeakCanary 是怎么实现的？
- Android 应用的整个生命周期由其组件的生命周期组成，如下图中所示。用户使用应用的过程中，在不同界面之间跳转，每个界面都经历着”生死“的转换，可在此建立检测点。
Activity/Fragment都有onDestory()回调方法， 进入此方法后，Activity/Fragment生命周期结束，应该被回收。
-
然后我们需要解决：如何得到未被回收的对象。
ReferenceQueue+WeakReference+手动调用 GC可实现这个需求。WeakReference 创建时的参数，传入一个 ReferenceQueue 对象。当被 WeakReference 引用的对象的生命周期结束，一旦被 GC 检查到，GC 将会把该对象添加到 ReferenceQueue 中，待ReferenceQueue处理。当 GC 过后对象一直不被加入 ReferenceQueue，它可能存在内存泄漏。
-
找到了未被回收的对象，如何确认是否真的内存泄漏？这里可以将问题转换为：未被回收的对象，是否被其他对象引用？找出其最短引用链。
VMDebug+HAHA完成需求。VM 会有堆内各个对象的引用情况，并能以
hprof文件导出。HAHA 是一个由 square 开源的 Android 堆分析库，分析hprof文件生成Snapshot对象。Snapshot用以查询对象的最短引用链。
- 找到最短引用链后，定位问题，排查代码将会事半功倍。
如下泳道图分析， LeakCanary 各个模块如何配合达到检测目的。
泳道图源自参考链接
参考引用链接
LeakCanary: Detect all memory leaks!
Wrangling Dalvik: Memory Management in Android