Android Studio 3.0上分析内存泄漏的原因
以前用eclipse的时候,我们采用的是ddms和mat,不仅使用步骤复杂繁琐,而且要手动排查内存泄漏的位置,操作起来比较麻烦。后来随着android studio的潮流,我也抛弃了eclipse加入了as。
android studio也开始支持自动进行内存泄漏检查,并且操作起来也比较方便。
封面
这个不用*我会告诉你吗
1.写在前面
google在上周发布了android studio 3.0的正式版本,周四早晨在上班的地铁上就看到群里在沸沸扬扬的讨论关于3.0版本的各种坑,啊,不对,各种特性,到公司之后就迫不及待的更新了3.0版本,嗯,还算顺利,只遇到了一个坑,一切都在happy的进行着。
什么,你以为我想要写遇到的坑是什么,呵呵哒,我才不会告诉你,等等。。。手里的板砖先放下,一会说还不行吗,今天我们主要来聊聊如何在android studio 3.0上分析内存泄漏,文章的内容很简单,但是自己摸索还是需要一些时间的,所以就在这里记录下来分享给大家。
2.强大的android profiler
在3.0版本中,android使用了新的性能分析工具android profiler来代替原有的android monitor,使用方式和原来类似,都可以分析cpu、内存和网络的使用情况,但是功能强大了很多。
开始使用
还记得我之前写过一篇文章《android 使用rxlifecycle解决rxjava内存泄漏》,本文将以这篇文章里的demo为例,使用android studio 3.0再次分析一下内存泄漏。
首先点击工具栏中的profile按钮将待分析的app安装到设备上,也可以直接安装,在as底部选择android profiler按钮:
将待分析的app安装到设备上
可以看到有下面的提示,大概意思是不能在当前进程进行更高级的分析:
不能在当前进程进行更高级的分析
点击run configuration进去看看,发现不能勾选开关,提示gradle插件版本太低,需要2.4以上版本才可以,嗯,那就更新一下:
更新gradle插件版本
已经更新到3.0版本了,可以勾选开关了,点击确定:
dependencies { classpath 'com.android.tools.build:gradle:3.0.0' }
勾选开关
又来一个警告,大概意思是说,你的gradle版本已经升级到3.0了,需要和26.0.2版本的构建工具搭配才更好,好好好,听你的:
更新26.0.2版本的构建工具
更新完成之后,需要再次运行一下app,如果还提示更高级的分析,请重启android studio,重启还不好,没关系,反正今天也用不到它,不要打我,下面来看下正常的android profiler:
android profiler
点击memory进入内存详情,在这里可以实时查看内存的占用情况:
内存详情
内存泄漏分析
我们先写个会发生内存泄漏的程序分析一下:
public class rxlifecyclecomponentsactivity extends rxappcompatactivity { @override protected void oncreate(@nullable bundle savedinstancestate) { super.oncreate(savedinstancestate); setcontentview(r.layout.activity_rxlifecycle); butterknife.bind(this); initdata(); } private void initdata() { // 每隔1s执行一次事件 observable.interval(1, timeunit.seconds) .subscribeon(schedulers.io()) .observeon(androidschedulers.mainthread()) .subscribe(new observer<long>() { @override public void onsubscribe(@nonnull disposable d) { } @override public void onnext(@nonnull long along) { log.i("接收数据", string.valueof(along)); } @override public void onerror(@nonnull throwable e) { } @override public void oncomplete() { } }); } }
很简单,每隔1s发送一条数据,因为关闭activity之后没有取消订阅,rxjava还继续持有activity的引用,所以在内存回收的时候,该activity不会被回收,由此引发内存泄漏。
下面反复打开关闭页面5次,然后手动gc(点击左上角的垃圾桶图标),发现内存占用并没有减少:
内存泄漏分析
分析一下当前的内存堆栈情况(点击垃圾桶图标右侧的图标):
分析内存堆栈情况
选择按包名查找,找到当前测试的activity,发现存在5个实例,由此可见,内存已经发生了泄漏:
内存泄漏
防止内存泄漏
修改一下上面的代码,在关闭activity时取消订阅:
public class rxlifecyclecomponentsactivity extends rxappcompatactivity { @override protected void oncreate(@nullable bundle savedinstancestate) { super.oncreate(savedinstancestate); setcontentview(r.layout.activity_rxlifecycle); butterknife.bind(this); initdata(); } private void initdata() { // 每隔1s执行一次事件 observable.interval(1, timeunit.seconds) .subscribeon(schedulers.io()) .observeon(androidschedulers.mainthread()) .compose(this.<long>binduntilevent(activityevent.destroy)) .subscribe(new observer<long>() { @override public void onsubscribe(@nonnull disposable d) { } @override public void onnext(@nonnull long along) { log.i("接收数据", string.valueof(along)); } @override public void onerror(@nonnull throwable e) { } @override public void oncomplete() { } }); } }
反复打开页面5次,手动gc,看下当前的堆栈情况,可以看到当前已经没有rxlifecyclecomponentsactivity的实例存在了:
无内存泄漏
ok,到这里,在android studio 3.0上分析内存泄漏就学习完了,赶快去动手试试吧!
3.更新android studio遇到的问题
编译的时候报错:
发现是在gradle里打包输出apk的代码出的问题,原代码是这样的:
applicationvariants.all { variant -> variant.outputs.each { output -> def file = output.outputfile string apkname = "apk_name" + defaultconfig.versionname.replace(".", "_") + ".apk" output.outputfile = new file(file.parent, apkname) } }
修改成这样就可以了:
applicationvariants.all { variant -> variant.outputs.all { outputfilename = "apk_name" + defaultconfig.versionname.replace(".", "_") + ".apk" } }
4.写在最后
上一篇: Java连载5-标识符、关键字和字面值
下一篇: 新手必看:flash流程介绍
推荐阅读
-
Android Studio 3.0上分析内存泄漏的原因
-
Android自定义View5--getWidth()和getMeasuredWidth()区别, view.post(Runnable)引发内存泄漏的原因和解决
-
解决kotlin 单元测试在android studio 3.0 上的 “AAPT2 error” 错误
-
Android 中 Activity的内存泄漏,原因以及处理方法
-
Android中内存泄漏的相关因素分析(一)
-
Android中内存泄漏的相关因素分析(二)
-
定位分析内存泄漏的原因和后果
-
定位分析内存泄漏的原因和后果
-
Android自定义View5--getWidth()和getMeasuredWidth()区别, view.post(Runnable)引发内存泄漏的原因和解决