LeakCanary的使用和实现原理

• Android 应用内存泄漏问题，一直是性能优化的重点。在不清楚内存泄漏的大致范围时，通过人为测试模拟重现或无目的地分析 heap dump等方法来检测，都太繁琐、耗时且定位不准。

  什么是内存泄漏？

  在 Java 世界中，一切对象都有生命周期，如同人的寿命。人死灯灭，入轮回，转世投胎。Java 对象的生命周期结束后，将被 GC 回收，原先占用的内存会有新的用途。但凡是总有例外，就如孙悟空可以修改生死谱长生不死，聂小倩能残存人间人鬼相恋。Java 对象有时也会”长死不死“，GC 拿它没有办法，这种情况就是内存泄漏。造成这种情况的原因是：Java 对象被另一个生命周期更长对象持有，具有 可达性 ，这并不是我们想要的。

  问：有没有一种简单直接且能有效定位内存泄漏位置的方法呢？

  答：有，那就是 LeakCanary 。我们可以简单地人为：将一个 App 作为输入，通过 LeakCanary 检测后，就会得到内存泄漏位置结果（如果存在的话）。

  

  LeakCanary

  知其然知其所以然，LeakCanary 如此强大实用，那么：LeakCanary 是怎么实现的？

• Android 应用的整个生命周期由其组件的生命周期组成，如下图中所示。用户使用应用的过程中，在不同界面之间跳转，每个界面都经历着”生死“的转换，可在此建立检测点。Activity/Fragment 都有 onDestory() 回调方法， 进入此方法后，Activity/Fragment生命周期结束，应该被回收。

• 

  简述声明周期

• 然后我们需要解决：如何得到未被回收的对象。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 各个模块如何配合达到检测目的。

  

  泳道图