前言： 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端来进行分析 总结： 到这里，具体的实践差不多了，此工具可在日常测试过程中同时监控内存泄漏的情况，并有数据可以用来分析，更加符合用户场景，覆盖率更高，不错的一个工具，具体项目中可以用的到。这里只是简单在实际项目中试用，具体的原理和具体的内存泄漏分析还需要继续实践。若有具体实践过的同学也可以多多交流下哈。
