安卓程序leaks是什么软件(leaks软件介绍及应用指南)

allen

温馨提示:这篇文章已超过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。

文章版权声明:除非注明,否则均为蔻桦网络工作室原创文章,转载或复制请以超链接形式并注明出处。

发表评论

快捷回复: 表情:
评论列表 (暂无评论,2284人围观)

还没有评论,来说两句吧...

取消
微信二维码
微信二维码
支付宝二维码