videocapture.read()解决内存泄露_安卓：开源的内存泄漏检测神器介绍

引言

还在为不会使用MAT而烦恼吗？还在对着MAT工具解析出的hprof图拼命找内存泄露的源头吗？放弃挣扎吧，少年。Android Studio时代，我们使用LeakCanary——傻瓜式的内存泄露检测工具。

简介

LeakCanary产自著名的Square公司，就是那个生产了网络请求框架OkHttp、Retrofit、图片加载框架Picasso的那个。LeakCanary可以让你的App在Debug模式下发生内存泄露时主动弹框提醒，而在Release模式下什么都不影响。

官网链接

Github上LeakCanary的源码首页A memory leak detection library for Android and Java。如果你是个良好的英文阅读者，那么无需往下看，首页上有你想要的一切。

快速集成

第一步：在build.gradle中添加如下依赖：

dependencies { 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(假设名为ExampleApplication)中添加如下代码：

public class ExampleApplication extends Application { @Override public void onCreate() { super.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); // Normal app init code... }}

到这里其实可以检测到Activity的内存泄露了，原理后面再说。以Debug模式运行你的App，你可以看到，你App的图标后面跟着一个Leaks图标，如下图；而如果你以Release模式运行，则没有这个图标。

测试使用

假装你是测试人员，你开始各种点击App，进行测试。然后你有幸看到这样一个弹框，如下图。

你很好奇，然后点击了弹框中间那个图标，于是手机屏幕的左上角出现了你App的图标，再下拉点击那个图标，或者从桌面上LeakCanary图标(跟在你App的图标屁股后面那个)点进去，你看到下图。点击+号可以展开，点击－号收起。

内存泄露往往发生在，生命周期较长的对象，直接或间接持有了生命周期较短的对象的强引用，导致了生命周期较短的对象不能及时释放。

上图已经够傻瓜式了，第一行表示生命周期较长的那个对象，图中是AliPayModel这个类；第二行表示生命周期长的那个持有了一个什么样的引用，图中是mActivity；第三行表示生命周期较短的那个对象，图中是SelectPayTypeActivity。

回去查看源码，发现AliPayModel是个单例，在SelectPayTypeActivity中以AliPayModel.getInstance(this).XXX()的方式调用单例中的XXX()方法。于是AliPayModel通过mActivity持有了SelectPayTypeActivity.this的引用。SelectPayTypeActivity本来应该在用户退出这个页面和进入其他Activity(尤其是其他Activity层级较深时)时释放掉，但是单例的生命周期贯穿整个App，AliPayModel一直引用着SelectPayTypeActivity，导致SelectPayTypeActivity不能及时释放，引发内存泄露。

public class AliPayModel extends BasePayModel { private Activity mActivity; private AliPayModel() {} private static AliPayModel instance = new AliPayModel(); public static AliPayModel getInstance(Activity tag) { instance.mActivity = tag; return instance; }

找到了原因，解决方法也呼之欲出。要么AliPayModel这个业务类不要定义成单例，要么mActivity由强引用改成软引用或者弱引用。Java的强、软、弱、虚四种引用的区别不在本文的讨论范围。

发现开源组件中的内存泄露

用上述方法，可以检测出各种各样的内存泄露，包括：WebView导致的内存泄露、资源未关闭导致的内存泄露、非静态匿名内部类导致的内存泄露、Handler导致的内存泄露等等。

请看下图，每次选择图片、上传头像时都会引发0.96M的内存泄露！

再按图索骥，发现罪魁祸首是将一个Activity定义为static。表示不是很能理解这种神代码。最让人心中万马奔腾的是，它竟然有2600多个star！在这个项目的Issues中很多人反映内存占用大、容易OOM、卡顿等，但是没有人从技术层面去查找和分析原因，更遑论去阅读源码，都是直接拿来就用！

总结

经过简单的配置，我们非常快速地发现了自己项目中存在的内存泄露的代码，并且无意中发现了开源组件中的严重内存泄露问题。下次面试被问到内存泄露检测工具，请不要只会习惯性地说MAT。