Android内存泄漏检测工具--LeakCanary

以前我看到内存泄漏分析文章的时候也是这样的想法，看着恐怖的MAT内存模型图，觉得内存泄漏的排查和解决简直是Android开发中登峰造极的技能。直到我遇到了她——LeakCanary，我才直到原来内存泄漏的排查和解决可以那么的优雅。LeakCanary是Square开源了一个内存泄露自动探测神器 。这是项目的github仓库地址：https://github.com/square/leakcanary 。使用非常简单，在build.gradle中引入包依赖：

debugCompile 'com.squareup.leakcanary:leakcanary-android:1.5'releaseCompile 'com.squareup.leakcanary:leakcanary-android-no-op:1.5'testCompile 'com.squareup.leakcanary:leakcanary-android-no-op:1.5'

在Application中的onCreate方法中增加初始化代码：

if (LeakCanary.isInAnalyzerProcess(this)) {    // This process is dedicated to LeakCanary for    // heap analysis.    // You should not init your app in this process.    return;}LeakCanary.install(this);

集成后什么都不用做，按照正常测试，当有内存泄漏发生后，应用会通过系统通知栏发出通知，点击通知就可以进入查看内存泄漏的具体信息。在这里举个实践中的例子。把LeakCanary集成到项目中后，等App启动后一会，系统通知到了，点击通知，跳转到泄漏的详情页面进行查看：

很明显，WebSiteQueryActivity泄露了。首先，static 的MaskHeadView.fLayout变量引用了FrameLayout.mContext对象，这个对象的引用就是指向了WebSiteQueryActivity的实例，导致了它的泄漏，在第二节中我们说过static对象是内部的static对象是比较容易造成内存泄漏的，检查代码发现，MaskHeadView直接在WebSiteQueryActivity的xml文件中使用了，因此持有WebSiteQueryActivity的实例，因为fLayout对象是静态的，因此它的生命周期与Application同样长，因此WebSiteQueryActivity退出后，它的实例引用依然被fLayout持有，导致它无法被回收从而内存泄露了。仔细检查代码，发现fLayout并没有被外部使用到，应该是之前的开发者手抖加了个static字段上去或者是现在不用了，但是没有去掉，在这里我直接去掉了这个修饰符，在此build代码，这个内存泄漏的现象消失了。

//去掉static修饰符，避免static对象引起的内存泄漏private static FrameLayout fLayout;public MaskHeadView(Context context, AttributeSet attrs) {   super(context, attrs);   this.context=context;   initView(context);}private void initView(Context context2) {   view = LayoutInflater.from(context).inflate(R.layout.   mask_head_view, this);   fLayout=(FrameLayout) view.findViewById(R.id.   mask_container);}

这只是个极简单的例子，但方法是一样的。顺便提一句，其实无论是MAT工具的内存分析，还是AndroidStudio中自带的分析工具亦或是LeakCanary，原理都是一样的，都是dump java heap出来进行分析，找到泄漏的问题，只是LeakCanary帮我们把分析的工作做了。

曾几何时，你以为内存泄漏分析都是这样的

但是现在你会发现其实也可以是酱紫的：

本文简书地址:http://www.jianshu.com/p/c250133ae464