一.Handler造成的内存泄漏
平时在处理网络任务或者封装一些请求回调等api都应该会借助Handler来处理。
Handler如此常用,一个不小心,比较容易造成我们app的内存泄漏。
下面我们举个例子:
1. 新建一个工程, 配置好leakCanary内存泄漏检测环境。(详情请看此博文:http://blog.csdn.net/c_xundaozhe/article/details/51694316)
2. 布局好UI 。(界面布局仅一个button, activity_main.xml文件中加个Button即可,Button 的ID为send_btn).
3. 在MainActity中添加如下代码
运行代码,我们做如下操作:
1. 点击按钮,在20秒内点击手机返回键,关闭MainActivity
2. 等待10秒左右
将会发现,LeakCanary提示内存泄漏:
分析泄漏的原因:
由于mhandler是Handler的匿名内部类的实例,所以它持有外部类Activity的引用,我们知道消息队列是在一个Looper线程中不断轮询处理消息,而消息队列中的Message持有mHandler实例的引用,mHandler又持有Activity的引用,那么当这个Activity退出时,消息队列中还有未处理的消息或者正在处理消息,将导致该Activity的内存资源无法及时回收,引发内存泄漏。
处理办法: 使用静态内部类,将上面的代码改一下:
修改代码后运行,重复上面相同的操作,LeakCanary没有报出内存泄漏。
在这里我们引申出另外一个问题:在我们平时使用handlerMessage()处理消息时,很多时候需要使用外部类MainActivity的方法,比如我们需要更新MainActivity的UI.那么问题就来了,我们静态内部类没有MainActivity的引用,没办法直接访问MainActivity的属性和方法的时候我们又该怎么办呢?
Handler使用方式升级版: 使用弱引用 -解决静态内部类访问外部类
名词解释:弱引用-----可以被JAVA 虚拟机顺利垃圾回收的一种引用方式
代码流程如下:
1. 修改一下我们刚才例子中的UI :在MainActity的布局文件 activity_main.xml中添加一个TextView ,并且在MainActity的oncreat找到并初始化它。
布局和效果示意如下:
2. 我们在handlerMessage中,给TextView设置值,请注意红色方框内的弱引用使用方式:
分析上面的做法:
创建一个静态Handler内部类,然后对Handler持有的外部对象使用弱引用,这样在回收时也可以回收Handler持有的对象,解决了我们内存泄漏以及访问外部对象的问题。
但是,这样子还不够完美: 我们退出MainActivity后,Looper线程的消息队列中还是可能会有待处理的消息,啥意思呢?就是我们MainActivity退出后,消息队列里还有消息,即我们的例子中,20秒后,还收到消息队列中的消息。
更完美的做法:我们应该在Activity关闭的时候,移除消息队列中的消息。
**********************************************************不那么华丽的分割线**********************************************************
二 使用单例模式造成的内存泄漏
Android的单例模式在我们项目开发中经常会用到,不过使用的不恰当的话也会造成内存泄漏。因为单例的静态特性使得单例的生命周期和应用的生命周期一样长, 这就说明了如果一个对象已经不需要使用了,而单例对象还持有该对象的引用,那么这个对象将不能被正常回收,这就导致了内存泄漏。
Android中习惯使用单例的常见类: xxxManager , xxxHelper , xxxUtils 等
我们举个例子:
1. 新建一个工程。
2. 配置好LeakCanary检测环境。
3. 添加一个单例类AppManager,代码如下
4.在MainActivity中使用此单例,代码如下
运行代码后做如下操作:
1. 点手机返回键,退出MainActivity。
2. 等待10秒
做完如上操作后,LeakCanary提示MainActivity内存泄漏:
我们来分析一下,这里为什么会出现内存泄漏呢?
AppManager appManager=AppManager.getInstance(this);
这句传入的是Activity的Context,我们都知道,Activty是间接继承于Context的,当这Activity退出时,Activity应该被回收, 但是单例中又持有它的引用,导致Activity回收失败,造成内存泄漏。
为了以防误传Activity的Context , 我们可以修改一下单例的代码,如下:
这样子修改,不管外面传入什么Context,最终都会使用Applicaton的Context,而我们单例的生命周期和应用的一样长,这样就防止了内存泄漏。
修改完毕后,运行代码,重复以上操作,将会发现leakCanary没有检测出泄漏。
**********************************************************不那么华丽的分割线**********************************************************
三 非静态内部类创建静态实例造成的内存泄漏
在实际的项目开发中,有时候我们需要频繁的启动某个页面(Activity),启动的时候总是需要初始化一些资源,为了避免重复创建相同资源,常常会使用静态对象去保存这些值,这种情况下,也很容易照成内存泄漏。我们举个例子:
1. 创建一个新的工程,配置好LeakCanary检测环境。
2. 直接在MainActivity中加入如下所示的代码
上面的代码中,我们创建了一个静态的资源对象mResouce,每次Activity启动都会使用该资源的数据,避免了重复创建。但是这样会造成内存泄漏。
运行代码,做如下操作:
1. 点击手机的返回键
2. 等待10秒
做上面的操作后,LeakCanary提示内存泄漏:
这里有事为什么会导致内存泄漏呢?
我们结合leakCanary给出的提示去分析,mResource->references->mainActivity
1.首先,非静态内部类默认会持有外部类的引用。
2.然后又使用了该非静态内部类创建了一个静态的实例。
3.该静态实例的生命周期和应用的一样长,这就导致了该静态实例一直会持有该Activity的引用,导致Activity的内存资源不能正常回收。
正确的做法有两种,一种是将内部类testResource改成静态内部类,还有就是将testResource抽取出来,封装成一个单例,如上一个例子那样,但是需要context时单例要切记注意Context的泄漏,使用applicationContext。
在这里,我们直接将testResource改成静态内部类。代码示意如下
修改代码,运行后执行相同操作,leakCanry没有报内存泄漏。
********************************************不那么华丽的分割线*****************************************
四.线程造成的内存泄漏
对于线程造成的内存泄漏,也是平时比较常见的,leakCanary官方Demo就是线程成造成的内存泄漏,使用了AsyncTask去执行异步线程,现在我们换个写法,直接使用Thread:
1.新建工程,配置好leakCanary环境
2.直接在MainActivity添加如下代码:
红色方框内的代码,可能每个人都这样写过。
OK ,我们执行一下,然后做如下操作:
1 MainActivity页面打开后,在20秒内点击手机返回键
2. 等待10秒
操作完成,leakCanary检测出内存泄漏。
分析:和上面几个案例的原因类似,不知不觉又搞了一个匿名内部类Runnable,对当前Activity都有一个隐式引用。如果Activity在销毁的时候,Runable内部的任务还未完成, 那么将导致Activity的内存资源无法回收,造成内存泄漏。正确的做法还是使用静态内部类的方式,如下:
上面代码中,自定义了静态的内部类MyRunable,实现了Runable ,然后在使用的时候实例化它。
运行代码后做如上相同操作,发现leakCannary没有检测出内存泄漏。
********************************************不那么华丽的分割线*****************************************
五.资源未关闭造成的内存泄漏
对于使用了BraodcastReceiver,ContentObserver,File,Cursor,Stream,Bitmap等资源的代码,应该在Activity销毁时及时关闭或者注销,否则这些资源将不会被回收,造成内存泄漏。