它是什么
一句话说，就是：
Android项目中，用于检测内存泄露，优化性能的工具
解决了什么问题
解决了，内存泄漏难以发现的问题。通过Leakcanary，可以轻松的找到GC中跟搜索法可达，然而不再使用的对象。 一般情况下，这种问题是很难被发现的，原因是他的出现是不经意间的，其中，内存泄露常见的场景有：
内存泄露常见场景
非静态内部类的静态实例
- 非静态内部类会持有外部类的引用
- 在外部类生命周期结束后，静态实例会长期维持着外部类的引用，导致无法被gc
多线程相关的匿名内部类\非静态内部类
- 匿名内部类同样也会持有外部类实例的引用，例如（AsyncTask、Tread、Runnable接口的实现类）
- 匿名内部类\非静态内部类中有耗时操作，在外部类生命周期结束后，仍然长时间维持着外部类的引用，导致无法被gc
Handler内存泄露
- Handler定义为非静态的，即持有了外部引用
- Message存储到MessageQueue中，耗时较长，无法被回收
怎样去使用它
集成进项目之中
-
新版本的Leakcanary只需添加依赖,无需更改代码
debugImplementation 'com.squareup.leakcanary:leakcanary-android:2.5'
发现内存泄露
Leaknary 能够发现内存泄露的位置有：
- 销毁的
Activity实例 * 销毁的Fragment实例 * 销毁的View实例 * 销毁的ViewModel实例 LeakCanary可以hook到Android生命周期中，从而自动检测Activity和Fragment何时destroy，并进行垃圾收集。ObjectWatcher持有这些被destroy的对象的弱引用。通过以下方法，可以找到被Destroy的对象，例如
AppWatcher.objectWatcher.watch(myDetachedView, "View was detached")
如果运行垃圾回收，并等待5秒钟后ObjectWatcher仍未清除 ，则认定可能发生内存泄漏。LeakCanary将此记录到Logcat：
在未被正常清楚的对象达到一定数量后，LeakCanary将其dump到存储堆，并显示通知：
注意：
当应用程序的状态是可见的时候，默认阈值为5 ，当应用程序是不可见的时候，默认阈值为1，。如果看到Leakcanary弹出通知，然后将应用程序压至后台（例如，直接上划进入主页），则LeakCanary阈值从5更改为1，并在5秒钟后dump到存储堆。若点击按钮将强制LeakCanary立即dump到存储堆。
打印堆中的信息
当保留对象的数量达到阈值时，LeakCanary将Java堆dump到存储在Android文件系统上的.hprof文件中（详见LeakCanary在何处存储堆转储？）。转储堆会使应用程序停止运行一小段时间，在此期间LeakCanary会显示Toast：
分析堆中的信息
LeakCanary.hprof使用Shark解析文件，并在该堆存储中找到保留的对象。
对于每个保留的对象，LeakCanary会查找引用路径，以防止对该保留的对象进行垃圾回收：至于泄露跟踪的具体内容，将在下一部分中展开：修复内存泄漏。
分析完成后，LeakCanary将显示带有摘要的通知，并在Logcat中显示结果。注意：下图将4个保留的对象归为2个不同的泄漏。LeakCanary为每个泄漏跟踪创建一个签名，并将具有相同签名的泄漏（即，由同一bug引起的泄漏）组合在一起。
点击弹出的通知，将提供更多详细的信息。也可以通过启动Leaks来找到该条内存泄露的详细信息
在Leaks中，每行对应一组具有相同签名的泄漏。应用程序首次出现的内存泄露类型将标记为“New”。
点击泄漏将展示整个泄露的跟踪信息。
泄漏签名是每个级联的散列参考怀疑导致泄漏，即，每个参考与红色下划线显示：
当泄漏跟踪以文本形式共享时，这些相同的可疑引用都带有下划线：如
并计算出响应的signature ，例如上述的签名为
分类内存泄露信息
常见的内存泄露Leaknary将其分成了第三方库和程序员操作失误两种。
-
第三方库的泄露如下所示：（带有Library Leak）
-
程序员异常操作的泄露：
如何解决内存泄露
- 我们在代码中能不用static变量持有context就不用，非要用就用weak引用。
- 对于内部类，尽量用静态内部类，这样就不会持有外部类引用。如果需要外部类引用做一些事，就手动赋给一个weak引用。
- 对于匿名内部类，不要图简单方便，实在不行就 写成外部类
- 在使用handler时，记得在activity的onDestroy()中加上remove()，有待尝试
