前言：
　　Android内测泄漏是比较常见的问题，在没有造成OOM之前，在测试过程中，也会经常性的忽略这个问题，但在android碎片化严重的，还是存在很多内测泄漏造成OOM的问题在反馈。那么如何检测内存泄漏呢，当然我们可以通过MAT这些工具来排查哪些页面会出现内存泄漏，那么问题来了，测试周期本来很紧张，全页面覆盖耗费很大，不全面覆盖又会有一些漏缺，那么有没有一种嵌入到日常测试过程，发现内存泄漏即提示并且有定位的方法，无意中在git上看到一个开源项目：LeakCanary，本文是对LeakCanary具体的实践。
　　实践：
　　1.素材：
　　编辑器：Android Studio(AS)
　　项目：阅读具体项目源码
　　2.具体实现
　　2.1编辑build.gradle
　　需要加入具体依赖
　　debugCompile 'com.squareup.leakcanary:leakcanary-android:1.3.1'
　　releaseCompile 'com.squareup.leakcanary:leakcanary-android-no-op:1.3.1'
　　这里需要说明一下，gradle依赖需要翻墙，不翻墙很有可能失败，好用公司网络（虽然说失败过很多次，但还是可以成功的）或者vpn，声明后重新构建去下载依赖
　　2.2编辑Application.class开启LeakCanary
　　该类即androidManifest中声明的application类（自定义的会居多，具体可以从androidManifest查看）
　　在复写的oncreate()方法中加入如下代码：
　　LeakCanary.install(this);
　　2.3安装应用到手机
　　在安装阅读app的同时，会在手机中安装一个监控app

　　2.4测试apk
　　此时可以开始日常测试啦，若有内测泄漏，会有toast提示正在dump数据
　　打开leak app可以看到一条具体的内测泄漏信息（这里在toast提示之后会有一定的延迟，过一会儿才会在leak app显示）

　　这里具体定位到具体tread和activtiy，你还可以借助heap dump数据进行mat工具分析
　　这里的例子是引用的对象没有释放造成的MainGridActivity页面的内存泄漏
　　2.5可share一些数据文件
　　这里提供share heap dump文件

　　从git的源码可以看到，dump的.hprof文件在sdcard/Download/leakcanary目录下，你也可以通过adb shell下进行查看，并且pull到pc端来进行分析
　　总结：
　　到这里，具体的实践差不多了，此工具可在日常测试过程中同时监控内存泄漏的情况，并有数据可以用来分析，更加符合用户场景，覆盖率更高，不错的一个工具，具体项目中可以用的到。这里只是简单在实际项目中试用，具体的原理和具体的内存泄漏分析还需要继续实践。若有具体实践过的同学也可以多多交流下哈。