前言
在Android
开发中,内存泄露十分常见。本文将详细讲解内存泄露的其中一种情况:在Handler
中发生的内存泄露
Anroid异步通信Handler系列文章
Android异步通信:Handler机制学习攻略
Android异步通信:Handler使用教程
Android异步通信:Handler工作原理
Android异步通信:Handler源码分析
Android异步通信:详解Handler内存泄露的原因
目录
背景知识
- 内存泄露的定义:本该被回收的对象不能被回收而停留在堆内存中
- 内存泄露出现的原因:当一个对象已经不再被使用时,本该被回收但却因为有另外一个正在使用的对象持有它的引用从而导致它不能被回收。这就导致了内存泄漏。
1. 问题描述
Handler
的一般用法 = 新建Handler
子类(内部类) 、匿名Handler
内部类,具体如下所示。
/**
* 方式1:新建Handler子类(内部类)
*/
public class MainActivity extends AppCompatActivity {
public static final String TAG = "carson:";
private Handler showhandler;
// 主线程创建时便自动创建Looper & 对应的MessageQueue
// 之后执行Loop()进入消息循环
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
//1. 实例化自定义的Handler类对象->>分析1
//注:此处并无指定Looper,故自动绑定当前线程(主线程)的Looper、MessageQueue
showhandler = new FHandler();
// 2. 启动子线程1
new Thread() {
@Override
public void run() {
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
e.printStackTrace();
}
// a. 定义要发送的消息
Message msg = Message.obtain();
msg.what = 1;// 消息标识
msg.obj = "AA";// 消息存放
// b. 传入主线程的Handler & 向其MessageQueue发送消息
showhandler.sendMessage(msg);
}
}.start();
// 3. 启动子线程2
new Thread() {
@Override
public void run() {
try {
Thread.sleep(5000);
} catch (InterruptedException e) {
e.printStackTrace();
}
// a. 定义要发送的消息
Message msg = Message.obtain();
msg.what = 2;// 消息标识
msg.obj = "BB";// 消息存放
// b. 传入主线程的Handler & 向其MessageQueue发送消息
showhandler.sendMessage(msg);
}
}.start();
}
// 分析1:自定义Handler子类
class FHandler extends Handler {
// 通过复写handlerMessage() 从而确定更新UI的操作
@Override
public void handleMessage(Message msg) {
switch (msg.what) {
case 1:
Log.d(TAG, "收到线程1的消息");
break;
case 2:
Log.d(TAG, " 收到线程2的消息");
break;
}
}
}
}
/**
* 方式2:匿名Handler内部类
*/
public class MainActivity extends AppCompatActivity {
public static final String TAG = "carson:";
private Handler showhandler;
// 主线程创建时便自动创建Looper & 对应的MessageQueue
// 之后执行Loop()进入消息循环
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
//1. 通过匿名内部类实例化的Handler类对象
//注:此处并无指定Looper,故自动绑定当前线程(主线程)的Looper、MessageQueue
showhandler = new Handler(){
// 通过复写handlerMessage()从而确定更新UI的操作
@Override
public void handleMessage(Message msg) {
switch (msg.what) {
case 1:
Log.d(TAG, "收到线程1的消息");
break;
case 2:
Log.d(TAG, " 收到线程2的消息");
break;
}
}
};
// 2. 启动子线程1
new Thread() {
@Override
public void run() {
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
e.printStackTrace();
}
// a. 定义要发送的消息
Message msg = Message.obtain();
msg.what = 1;// 消息标识
msg.obj = "AA";// 消息存放
// b. 传入主线程的Handler & 向其MessageQueue发送消息
showhandler.sendMessage(msg);
}
}.start();
// 3. 启动子线程2
new Thread() {
@Override
public void run() {
try {
Thread.sleep(5000);
} catch (InterruptedException e) {
e.printStackTrace();
}
// a. 定义要发送的消息
Message msg = Message.obtain();
msg.what = 2;// 消息标识
msg.obj = "BB";// 消息存放
// b. 传入主线程的Handler & 向其MessageQueue发送消息
showhandler.sendMessage(msg);
}
}.start();
}
}
-
测试结果
- 上述例子虽可运行成功,但代码会出现严重警告:
- 警告的原因 = 该
Handler
类由于无设置为 静态类,从而导致了内存泄露- 最终的内存泄露发生在
Handler
类的外部类:MainActivity
类
那么,该Handler
在无设置为静态类时,为什么会造成内存泄露呢?
2. 原因讲解
2.1 储备知识
- 主线程的
Looper
对象的生命周期 = 该应用程序的生命周期 - 在
Java
中,非静态内部类 & 匿名内部类都默认持有 外部类的引用
2.2 泄露原因描述
从上述示例代码可知:
- 上述的
Handler
实例的消息队列有2个分别来自线程1、2的消息(分别延迟1s
、6s
) - 在
Handler
消息队列 还有未处理的消息 / 正在处理消息时,消息队列中的Message
持有Handler
实例的引用 - 由于
Handler
= 非静态内部类 / 匿名内部类(2种使用方式),故又默认持有外部类的引用(即MainActivity
实例),引用关系如下图:
- 上述的引用关系会一直保持,直到
Handler
消息队列中的所有消息被处理完毕。在Handler
消息队列 还有未处理的消息 / 正在处理消息时,此时若需销毁外部类MainActivity
,但由于上述引用关系,垃圾回收器(GC)
无法回收MainActivity
,从而造成内存泄漏。如下图:
2.3 总结
- 当
Handler
消息队列 还有未处理的消息 / 正在处理消息时,存在引用关系: “未被处理 / 正处理的消息 ->Handler
实例 -> 外部类” - 若出现
Handler
的生命周期 > 外部类的生命周期 时(即Handler
消息队列 还有未处理的消息 / 正在处理消息 而 外部类需销毁时),将使得外部类无法被垃圾回收器(GC)
回收,从而造成 内存泄露
3. 解决方案
从上面可看出,造成内存泄露的原因有2个关键条件:
- 存在 “未被处理 / 正处理的消息 ->
Handler
实例 -> 外部类” 的引用关系 -
Handler
的生命周期 > 外部类的生命周期
即
Handler
消息队列 还有未处理的消息 / 正在处理消息 而 外部类需销毁
解决方案的思路 = 使得上述任1条件不成立 即可。
解决方案1:静态内部类
原理:静态内部类不默认持有外部类的引用,从而使得 “未被处理 / 正处理的消息 ->
Handler
实例 -> 外部类” 的引用关系 不存在。具体方案:将
Handler
的子类设置成静态内部类。此外,还可使用WeakReference弱引用持有外部类,保证外部类能被回收。因为:弱引用的对象拥有短暂的生命周期,在垃圾回收器线程扫描时,一旦发现了具有弱引用的对象,不管当前内存空间足够与否,都会回收它的内存解决代码
public class MainActivity extends AppCompatActivity {
public static final String TAG = "carson:";
private Handler showhandler;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
// 实例化自定义的Handler类对象->>分析1
// 注:
// a. 此处并无指定Looper,故自动绑定当前线程(主线程)的Looper、MessageQueue;
// b. 定义时需传入持有的Activity实例(弱引用)
showhandler = new FHandler(this);
new Thread() {
@Override
public void run() {
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
e.printStackTrace();
}
// a. 定义要发送的消息
Message msg = Message.obtain();
msg.what = 1;// 消息标识
msg.obj = "AA";// 消息存放
showhandler.sendMessage(msg);
}
}.start();
}
// 设置为:静态内部类
private static class FHandler extends Handler{
// 定义 弱引用实例
private WeakReference<Activity> reference;
// 在构造方法中传入需持有的Activity实例
public FHandler(Activity activity) {
// 使用WeakReference弱引用持有Activity实例
reference = new WeakReference<Activity>(activity); }
// 通过复写handlerMessage() 从而确定更新UI的操作
@Override
public void handleMessage(Message msg) {
switch (msg.what) {
case 1:
Log.d(TAG, "收到线程1的消息");
break;
case 2:
Log.d(TAG, " 收到线程2的消息");
break;
}
}
}
}
解决方案2:当外部类结束生命周期时,清空Handler内消息队列
原理:不仅使得 “未被处理 / 正处理的消息 ->
Handler
实例 -> 外部类” 的引用关系 不复存在,同时 使得Handler
的生命周期(即 消息存在的时期) 与 外部类的生命周期 同步具体方案:当 外部类(此处以
Activity
为例) 结束生命周期时(此时系统会调用onDestroy()
),清除Handler
消息队列里的所有消息(调用removeCallbacksAndMessages(null)
)具体代码
@Override
protected void onDestroy() {
super.onDestroy();
mHandler.removeCallbacksAndMessages(null);
// 外部类Activity生命周期结束时,同时清空消息队列 & 结束Handler生命周期
}
使用建议
为了保证Handler
中消息队列中的所有消息都能被执行,此处推荐使用解决方案1解决内存泄露问题,即 静态内部类 + 弱引用的方式
4. 总结
- 本文主要讲解了
Handler
造成 内存泄露的相关知识:原理 & 解决方案 - 下一篇文章我将对讲解
Android Handler
的相关知识,感兴趣的同学可以继续关注Carson_Ho的简书
Anroid异步通信Handler系列文章
Android异步通信:Handler机制学习攻略
Android异步通信:Handler使用教程
Android异步通信:Handler工作原理
Android异步通信:Handler源码分析
Android异步通信:详解Handler内存泄露的原因
欢迎关注Carson_Ho的简书
不定期分享关于安卓开发的干货,追求短、平、快,但却不缺深度。