温馨提示:这篇文章已超过607天没有更新,请注意相关的内容是否还可用!
还在为不会使用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。
还没有评论,来说两句吧...