原因:
Handler 的使用造成的内存泄漏问题应该说是最为常见了,很多时候我们为了避免 ANR 而不在主线程进行耗时操作,在处理网络任务或者封装一些请求回调等api都借助Handler来处理,但 Handler 不是万能的,对于 Handler 的使用代码编写一不规范即有可能造成内存泄漏。另外,我们知道 Handler、Message 和 MessageQueue 都是相互关联在一起的,万一 Handler 发送的 Message 尚未被处理,则该 Message 及发送它的 Handler 对象将被线程 MessageQueue 一直持有。
由于 Handler 属于 TLS(Thread Local Storage) 变量, 生命周期和 Activity 是不一致的。因此这种实现方式一般很难保证跟 View 或者 Activity 的生命周期保持一致,故很容易导致无法正确释放。
分析:
对于handler泄漏其实是由于消息队列持有对handler的引用,而handler又持有activity的隐式引用,这个引用会保持到消息得到处理,而导致activity无法被垃圾回收器进行回收,而导致内存泄漏 ,使用static+WeakReference可以解决内存泄漏问题,不过不写也无所谓 , 不加static的默认会在handler构造函数加上activity这个参数,只要handler没有被回收,就会泄露。加static目的是为了防止泄露,为什么会泄露,就是因为没回收,没回收是因为还引用着。只有postDelayed的时候才会有泄露问题,因为delayed的时候activity的引用还保持着,所以只要delayed完了就能回收了,大多数情况下根本不必用加static。
说了这么多搬砖好,下面呈上如何搬好砖:
import android.app.Activity;
import android.os.Handler;
import android.os.Message;
import java.lang.ref.WeakReference;
/**
* Description Handler内存泄漏的处理类
* Created by
* Date
*/
public class MyHandler extends Handler {
private WeakReference<Activity> mActivity;
private HandleMessageCallBack handleMessageCallBack;
public MyHandler(Activity activity, HandleMessageCallBack handleMessageCallBack) {
mActivity = new WeakReference<>(activity);
this.handleMessageCallBack = handleMessageCallBack;
}
@Override
public void handleMessage(Message msg) {
Activity activity = mActivity.get();
if (activity != null) {
//做操作
handleMessageCallBack.messageCallBack(msg);
}
}
//接口回调Message
public interface HandleMessageCallBack {
void messageCallBack(Message msg);
}
}
本文深入探讨了Handler在Android开发中常见的内存泄漏问题,分析了Handler、Message和MessageQueue之间的关联导致的内存泄漏原因,并提供了使用WeakReference结合Activity的解决方案。
873

被折叠的 条评论
为什么被折叠?



