Handler 消息机制以及内存泄漏

1. 消息机制

1.1 post系列

通过查看源码可知,post(Runnable r)postDelayed(Runnable r, long delayMillis)最终调用的都是sendMessageDelayed方法:

// post
 public final boolean post(Runnable r){
    return sendMessageDelayed(getPostMessage(r), 0);
}
// postDelayed
public final boolean postDelayed(Runnable r, long delayMillis){
    return sendMessageDelayed(getPostMessage(r), delayMillis);
}

1.2 postAtTime

postAtTime(Runnable r, long uptimeMillis)最终调用的是sendMessageAtTime方法:

// postAtTime
public final boolean postAtTime(Runnable r, Object token, long uptimeMillis){
    return sendMessageAtTime(getPostMessage(r, token), uptimeMillis);
}

这里面都有一个共同的方法getPostMessage

private static Message getPostMessage(Runnable r) {
    Message m = Message.obtain();
    m.callback = r;
    return m;
}

m.callback = r这句可以看出:getPostMessage就是把传入的 Runnable 赋值给 Message 对象的 callback 属性

1.3 sendEmptyMessage

sendEmptyMessage最终指向sendEmptyMessageDelayed函数:

public final boolean sendEmptyMessageDelayed(int what, long delayMillis) {
    Message msg = Message.obtain();
    msg.what = what;
    return sendMessageDelayed(msg, delayMillis);
}

msg.what = what这句可以看出:sendEmptyMessageDelayed就是把 what 赋值给 Message 的 what 属性。

1.4 sendMessage(msg : Message)

至于常用的sendMessage(msg : Message)就不用细说了,这是直接传入 Message 类型的参数。

综合以上这几点来说,各种发送消息的方法最终都是把消息赋值给 Message 对象(或者 Message 的属性),而且这些方法最终调用的都是 MessageQueue 中的 enqueueMessage方法,就是把消息加入消息队列

1.5 enqueueMessage方法

方法较长,我们看看关键的几行:

Message prev;
for (;;) {
    prev = p;
    p = p.next;
    if (p == null || when < p.when) {
        break;
    }
    if (needWake && p.isAsynchronous()) {
        needWake = false;
    }
}
msg.next = p; // invariant: p == prev.next
prev.next = msg;

用一个无限循环将消息加入到消息队列中(链表的形式),到这里把消息发出去并加入队列这两步算是完成了,接下来就是取出并处理消息。

1.6 Looper 取出消息

Looper 中有一个死循环(Looper.loop())用来不断从队列中取出消息:

public static void loop() {
    final Looper me = myLooper();
    final MessageQueue queue = me.mQueue;
    for (;;) {
        Message msg = queue.next();
        ...代码省略
        msg.target.dispatchMessage(msg);
        ...代码省略
        msg.recycleUnchecked();
    }
}

queue.next()每次取出一条 Message 消息,然后交由msg.targer.dispatchMessage(msg)处理,从上篇文章中可以知道,msg.targer就是发出消息的 Handler,所以我们只需要关注dispatchMessage(msg)

1.7 dispatchMessage(msg)处理消息

dispatchMessage(msg)在 Handler 类中

public void dispatchMessage(Message msg) {
        if (msg.callback != null) {
            handleCallback(msg);
        } else {
            if (mCallback != null) {
                if (mCallback.handleMessage(msg)) {
                    return;
                }
            }
            handleMessage(msg);
        }
    }
  1. msg 的 callback 不为空,调用handleCallback方法(message.callback.run())
  2. mCallback 不为空,调用mCallback.handleMessage(msg)
  3. 最后如果其他都为空,执行 Handler 自身的handleMessage(msg)方法
第 1 点就是上面的 【1.1 post系列】 和 【1.2 postAtTime】,第 3 点就是我们最常见的 handleMessage方法。需要注意一下就是 callback.run()这里直接调用线程的 run 方法,相当于普通方法调用, 不会开启新的线程

现在谈谈第 2 点,Handler 有很多种构造方法,除了上一篇文章提到的public Handler(Looper looper)Handler()等,还有一个:

public Handler(Looper looper, Callback callback) {
        this(looper, callback, false);
    }

Callback 是这样的:

public interface Callback {
        public boolean handleMessage(Message msg);
    }

需要重写handleMessage,这不就是 Handler 里面的handleMessage吗?其实两者是有区别的:

// Handler
public void handleMessage(Message msg) {}


// Callback
public boolean handleMessage(Message msg);

Callback 里面的handleMessage返回值是 Boolean 类型的,那么接下来分别返回 true 和 false 看看效果吧:

class MainActivity : AppCompatActivity() {
    var handler: Handler? = null
    var looper: Looper? = null

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)
        looper = Looper.getMainLooper()
        val callback = object: Handler.Callback{
            override fun handleMessage(msg: Message?): Boolean {
                Log.e("abc","--- Callback:threadName ---" + Thread.currentThread().name
                )
                return true
            }
        }
        val thread = object : Thread() {
            override fun run() {
                super.run()
                handler = object : Handler(looper, callback) {
                    override fun handleMessage(msg: Message?) {
                        super.handleMessage(msg)
                        Log.e("abc","--- handleMessage:threadName ---" + Thread.currentThread().name
                        )
                    }
                }
            }
        }

        thread.start()

        myBtn.setOnClickListener {
            handler?.sendEmptyMessage(4)
        }
    }
}

// Log 打印情况
--- Callback:threadName ---main

如果返回值类型改成 false:

val callback = object: Handler.Callback{
            override fun handleMessage(msg: Message?): Boolean {
                Log.e("abc", "--- Callback:threadName ---" + Thread.currentThread().name
                )
                return false
            }
        }
        
// Log 打印情况
--- Callback:threadName ---main
--- handleMessage:threadName ---main

所以,Callback 中的handleMessage返回 true 就不继续执行 Handler 中的handlerMessage了,反之则两个handleMessage都执行。其实这些从dispatchMessage方法中可以看出来(返回 true 则 return 终止,否则继续执行 handleMessage):

 if (mCallback != null) {
    if (mCallback.handleMessage(msg)) {
        return;
    }
}
handleMessage(msg);

总结

上面主要讲了消息的发送和取出,大概知道了 Handler 消息机制的工作流程:

  1. Handler 对象通过post(postDelayedpostAtTime)或者sendMessagesendEmptyMessage)把消息(Message)交给 MessageQueue
  2. MessageQueue.enqueueMessage方法将 Message 以链表的形式放入消息队列中
  3. Looper.loop()循环调用 MessageQueue 的next()取出消息,交给 Handler 的dispatchMessage方法处理消息
  4. dispatchMessage()中分别判断msg.callback和构造函数传入的mCallback是否为空,不为空则执行它们的回调,为空则执行 Handler 自身的handlerMessage方法。

2. Handler 内存泄漏问题

2.1 引起内存泄漏的原因

下面这样写会有内存泄漏风险:

val mHandler = object : Handler() {
        override fun handleMessage(msg: Message?) {
            super.handleMessage(msg)
        }
    }

Android Studio 会标黄警告,鼠标放在 handler 代码块部分还会弹出提示,大概意思就是建议你用静态模式或者弱引用。上面这种写法相当于定义了一个匿名内部类,非静态的匿名内部类默认是持有外部类(对应 Activity 等)引用的。如果发消息的 handler 所在线程还在执行,当前 Activity 就被 finish 了,那么该 Handler 的匿名内部类持有 Activity 的引用,所以 Activity 对象是无法被 GC 机制回收的。即:执行了 finish 代码,但 Activity 对象还在内存中(内存泄漏)。这种对象如果越来越多,就会有 OOM(内存溢出)的可能。

2.2 解决办法

kotlin 中没有静态类这个概念,这里用 java 静态内部类举例:

static class MyHandler extends Handler {
        WeakReference weakActivity;

        MyHandler(MyActivity activity) {
            weakActivity = new WeakReference<>(activity);
        }

        @Override
        public void handleMessage(Message msg) {
            super.handleMessage(msg);
            MyActivity activity = weakActivity.get();
            // activity.text = "......"
        }
    }
  1. 静态内部类不持有外部类引用,所以不会导致 Activity 对象泄漏(java 中 「静态的」等于「类的」,静态内部类如果能持有外部类引用,那说明外部类的引用就是内部「类的」,这不符合逻辑,这样写编译都不通过)。
  2. 但该静态内部类必须使用外部类的引用(比如操作 UI),此时就可以用弱引用的方式。上面代码用的是把 Activity 的弱引用在 Handler 构造函数中初始化,这样如果需要操作 UI,可以使用activity.text = "test"这种方式。

参考文章:

  1. 从Handler.post(Runnable r)再一次梳理Android的消息机制(以及handler的内存泄露
  2. Handler内存泄露及解决方案

你可能感兴趣的:(handler,内存泄漏)