Android性能优化之利用强大的LeakCanary检测内存泄漏及解决办法
前言:
最近公司c轮融资成功了,移动团队准备扩大一下,需要招聘android开发工程师,陆陆续续面试了几位android应聘者,面试过程中聊到性能优化中如何避免内存泄漏问题时,很少有人全面的回答上来。所以决定抽空学习总结一下这方面的知识,以及分享一下我们是如何检测内存泄漏的。我们公司使用开源框架leakcanary来检测内存泄漏。
什么是内存泄漏?
有些对象只有有限的生命周期。当它们的任务完成之后,它们将被垃圾回收。如果在对象的生命周期本该结束的时候,这个对象还被一系列的引用,这就会导致内存泄漏。随着泄漏的累积,app将消耗完内存。
内存泄漏造成什么影响?
它是造成应用程序oom的主要原因之一。由于android系统为每个应用程序分配的内存有限,当一个应用中产生的内存泄漏比较多时,就难免会导致应用所需要的内存超过这个系统分配的内存限额,这就造成了内存溢出而导致应用crash。
什么是leakcanary?
leakcanary是square开源框架,是一个android和java的内存泄露检测库,如果检测到某个 activity 有内存泄露,leakcanary 就是自动地显示一个通知,所以可以把它理解为傻瓜式的内存泄露检测工具。通过它可以大幅度减少开发中遇到的oom问题,大大提高app的质量。
leakcanary捕获常见内存泄漏以及解决办法
1.)错误使用单例造成的内存泄漏
在平时开发中单例设计模式是我们经常使用的一种设计模式,而在开发中单例经常需要持有context对象,如果持有的context对象生命周期与单例生命周期更短时,或导致context无法被释放回收,则有可能造成内存泄漏,错误写法如下:
public class loginmanager { private static loginmanager minstance; private context mcontext; private loginmanager(context context) { this.mcontext = context; } public static loginmanager getinstance(context context) { if (minstance == null) { synchronized (loginmanager.class) { if (minstance == null) { minstance = new loginmanager(context); } } } return minstance; } public void dealdata() { } }
弱我们在一个activity中调用的,然后关闭该activity则会出现内存泄漏。
loginmanager.getinstance(this).dealdata();
leakcanary检测结果如下:
解决 办法要保证context和application的生命周期一样,修改后代码如下:
public class loginmanager { private static loginmanager minstance; private context mcontext; private loginmanager(context context) { this.mcontext = context.getapplicationcontext(); } public static loginmanager getinstance(context context) { if (minstance == null) { synchronized (loginmanager.class) { if (minstance == null) { minstance = new loginmanager(context); } } } return minstance; } public void dealdata() { } }
2.)handler造成的内存泄漏
早些年handler的使用频率还是蛮高的,它是工作线程与ui线程之间通讯的桥梁,只是现在大量开源框架对其进行了封装,我们这里模拟一种常见使用方式来模拟内存泄漏情形。
public class mainactivity extends appcompatactivity { private handler mhandler = new handler(); private textview mtextview; @override protected void oncreate(bundle savedinstancestate) { super.oncreate(savedinstancestate); setcontentview(r.layout.activity_main); mtextview = (textview) findviewbyid(r.id.text);//模拟内存泄露 mhandler.postdelayed(new runnable() { @override public void run() { mtextview.settext("lcj"); } }, 3 * 60 * 1000); finish(); } @override protected void ondestroy() { super.ondestroy(); lapplication.getrefwatcher().watch(this); } }
上述代码通过内部类的方式创建mhandler对象,此时mhandler会隐式地持有一个外部类对象引用这里就是mainactivity,当执行postdelayed方法时,该方法会将你的handler装入一个message,并把这条message推到messagequeue中,messagequeue是在一个looper线程中不断轮询处理消息,那么当这个activity退出时消息队列中还有未处理的消息或者正在处理消息,而消息队列中的message持有mhandler实例的引用,mhandler又持有activity的引用,所以导致该activity的内存资源无法及时回收,引发内存泄漏。
leakcanary检测结果如下:
要想避免handler引起内存泄漏问题,需要我们在activity关闭退出的时候的移除消息队列中所有消息和所有的runnable。上述代码只需在ondestroy()函数中调用mhandler.removecallbacksandmessages(null);就行了。
public class mainactivity1 extends appcompatactivity { private handler mhandler = new handler(); private textview mtextview; @override protected void oncreate(bundle savedinstancestate) { super.oncreate(savedinstancestate); setcontentview(r.layout.activity_main); mtextview = (textview) findviewbyid(r.id.text); //模拟内存泄露 mhandler.postdelayed(new runnable() { @override public void run() { mtextview.settext("lcj"); } }, 3 * 60 * 1000); finish(); } @override protected void ondestroy() { super.ondestroy(); mhandler.removecallbacksandmessages(null); mhandler=null; lapplication.getrefwatcher().watch(this); } }
3.)线程造成的内存泄漏
最早时期的时候处理耗时操作多数都是采用thread+handler的方式,后来逐步被asynctask取代,直到现在采用rxjava的方式来处理异步。这里以asynctask为例,可能大部分人都会这样处理一个耗时操作然后通知ui更新结果:
public class mainactivity extends appcompatactivity { private asynctask<void, void, integer> asynctask; private textview mtextview; @override protected void oncreate(bundle savedinstancestate) { super.oncreate(savedinstancestate); setcontentview(r.layout.activity_main); mtextview = (textview) findviewbyid(r.id.text); testasynctask(); finish(); } private void testasynctask() { asynctask = new asynctask<void, void, integer>() { @override protected integer doinbackground(void... params) { int i = 0; //模拟耗时操作 while (!iscancelled()) { i++; if (i > 1000000000) { break; } log.e("leakcanary", "asynctask---->" + i); } return i; } @override protected void onpostexecute(integer integer) { super.onpostexecute(integer); mtextview.settext(string.valueof(integer)); } }; asynctask.execute(); } @override protected void ondestroy() { super.ondestroy(); lapplication.getrefwatcher().watch(this); } }
对于上面的例子来说,在处理一个比较耗时的操作时,可能还没处理结束mainactivity就执行了退出操作,但是此时asynctask依然持有对mainactivity的引用就会导致mainactivity无法释放回收引发内存泄漏。
leakcanary检测结果:
如何解决这种内存泄漏呢?在使用asynctask时,在activity销毁时候也应该取消相应的任务asynctask.cancel()方法,避免任务在后台执行浪费资源,进而避免内存泄漏的发生。
public class mainactivity3 extends appcompatactivity { private asynctask<void, void, integer> asynctask; private textview mtextview; @override protected void oncreate(bundle savedinstancestate) { super.oncreate(savedinstancestate); setcontentview(r.layout.activity_main); mtextview = (textview) findviewbyid(r.id.text); testasynctask(); finish(); } private void testasynctask() { asynctask = new asynctask<void, void, integer>() { @override protected integer doinbackground(void... params) { int i = 0; //模拟耗时操作 while (!iscancelled()) { i++; if (i > 1000000000) { break; } log.e("leakcanary", "asynctask---->" + i); } return i; } @override protected void onpostexecute(integer integer) { super.onpostexecute(integer); mtextview.settext(string.valueof(integer)); } }; asynctask.execute(); } private void destroyasynctask() { if (asynctask != null && !asynctask.iscancelled()) { asynctask.cancel(true); } asynctask = null; } @override protected void ondestroy() { super.ondestroy(); destroyasynctask(); lapplication.getrefwatcher().watch(this); } }
4.)非静态内部类创建静态实例造成的内存泄漏
有时我们需要一个可以随着屏幕旋转的activity,比如视频播放activity,这时我们为了防止多次调用oncreate方法导致某些参数重新初始化,我们一般会选择创建一个内部类和一个静态实例来保存这些参数,比如以下实现:
public class mainactivity extends appcompatactivity { private static config mconfig; @override protected void oncreate(bundle savedinstancestate) { super.oncreate(savedinstancestate); setcontentview(r.layout.activity_main); //模拟内存泄露 if (mconfig == null) { mconfig = new config(); mconfig.setsize(18); mconfig.settitle("老九门"); } finish(); } @override protected void ondestroy() { super.ondestroy(); lapplication.getrefwatcher().watch(this); } class config { private int size; private string title; public int getsize() { return size; } public void setsize(int size) { this.size = size; } public string gettitle() { return title; } public void settitle(string title) { this.title = title; } } }
上述代码看着没有任何问题,其实内部类都会持有一个外部类引用,这里这个外部类就是mainactivity,然而内部类实例又是static静态变量其生命周期与application生命周期一样,所以在mainactivity关闭的时候,内部类静态实例依然持有对mainactivity的引用,导致mainactivity无法被回收释放,引发内存泄漏。leakcanary检测内存泄漏结果如下:
对于这种泄漏的解决办法就是将内部类改成静态内部类,不再持有对mainactivity的引用即可,修改后的代码如下:
public class mainactivity extends appcompatactivity { private static config mconfig; @override protected void oncreate(bundle savedinstancestate) { super.oncreate(savedinstancestate); setcontentview(r.layout.activity_main); //模拟内存泄露 if (mconfig == null) { mconfig = new config(); mconfig.setsize(18); mconfig.settitle("老九门"); } finish(); } @override protected void ondestroy() { super.ondestroy(); lapplication.getrefwatcher().watch(this); } static class config { private int size; private string title; public int getsize() { return size; } public void setsize(int size) { this.size = size; } public string gettitle() { return title; } public void settitle(string title) { this.title = title; } } }
5.)由webview引起的内存泄漏
在目前的开发中多多少少会用到hybrid开发方式,这样我们就会用webview去承载html网页,就如下面这种方式:
java代码:
public class mainactivity5 extends appcompatactivity { private webview mwebview; @override protected void oncreate(bundle savedinstancestate) { super.oncreate(savedinstancestate); setcontentview(r.layout.activity_web); mwebview = (webview) findviewbyid(r.id.web); mwebview.loadurl("http://www.cnblogs.com/whoislcj/p/5720202.html"); } @override protected void ondestroy() { super.ondestroy(); lapplication.getrefwatcher().watch(this); } }
xml布局文件:
<?xml version="1.0" encoding="utf-8"?> <linearlayout xmlns:android="http://schemas.android.com/apk/res/android" android:id="@+id/activity_main" android:layout_width="match_parent" android:layout_height="match_parent" android:orientation="vertical"> <webview android:id="@+id/web" android:layout_width="wrap_content" android:layout_height="wrap_content"/> </linearlayout>
webview解析网页时会申请native堆内存用于保存页面元素,当页面较复杂时会有很大的内存占用。如果页面包含图片,内存占用会更严重。并且打开新页面时,为了能快速回退,之前页面占用的内存也不会释放。有时浏览十几个网页,都会占用几百兆的内存。这样加载网页较多时,会导致系统不堪重负,最终强制关闭应用,也就是出现应用闪退或重启。及时activity关闭时在ondestroy中调用如下代码也是没有任何作用。
private void destroywebview() { if (mwebview != null) { mlinearlayout.removeview(mwebview); mwebview.pausetimers(); mwebview.removeallviews(); mwebview.destroy(); mwebview = null; } }
先看下leakcanary检测到的结果如下:
该如何解决呢?这个查了不少资料,其中一种就是使用getapplicationgcontext作为参数构建webview,然后动态添加到一个viewgroup中,最后退出的时候调用webview的销毁的函数,虽然也达到了防止内存溢出的效果,但是在有些网页弹出时候需要记住密码的对话框的时候,会出现unable to add window -- token null is not for an application 的错误,所以这里采用的解决办法是通过把使用了webview的activity(或者service)放在单独的进程里。然后在检测到应用占用内存过大有可能被系统干掉或者它所在的activity(或者service)结束后,调用android.os.process.killprocess(android.os.process.mypid());,主动kill掉进程。由于系统的内存分配是以进程为准的,进程关闭后,系统会自动回收所有内存。
修改后的代码如下:
public class mainactivity5 extends appcompatactivity { private webview mwebview; @override protected void oncreate(bundle savedinstancestate) { super.oncreate(savedinstancestate); setcontentview(r.layout.activity_web); mwebview = (webview) findviewbyid(r.id.web); mwebview.loadurl("http://www.cnblogs.com/whoislcj/p/5720202.html"); } @override protected void ondestroy() { destroywebview(); android.os.process.killprocess(android.os.process.mypid()); super.ondestroy(); lapplication.getrefwatcher().watch(this); } private void destroywebview() { if (mwebview != null) { mwebview.pausetimers(); mwebview.removeallviews(); mwebview.destroy(); mwebview = null; } } }
manifest中对应的activity配置如下:
<activity android:name=".mainactivity5" android:process="com.whoislcj.webview"/>
6.)资源未关闭造成的内存泄漏
对于使用了braodcastreceiver,contentobserver,file,cursor,stream,bitmap等资源的使用,应该在activity销毁时及时关闭或者注销,否则这些资源将不会被回收,造成内存泄漏。例如获取媒体库图片地址代码在查询结束的时候一定要调用
cursor 的关闭方法防止造成内存泄漏。
string columns[] = new string[]{ mediastore.images.media.data, mediastore.images.media._id, mediastore.images.media.title, mediastore.images.media.display_name }; cursor cursor = this.getcontentresolver().query(mediastore.images.media.external_content_uri, columns, null, null, null); if (cursor != null) { int photoindex = cursor.getcolumnindexorthrow(mediastore.images.media.data); //显示每张图片的地址,但是首先要判断一下,cursor是否有值 while (cursor.movetonext()) { string photopath = cursor.getstring(photoindex); //这里获取到的就是图片存储的位置信息 log.e("leakcanary", "photopath---->" + photopath); } cursor.close(); }
总结:
以上就是通过leakcanary检测到的内存泄漏情况以及解决办法。希望对大家的学习有所帮助,也希望大家多多支持。
下一篇: 深入浅析Android消息机制