Handler机制实现原理总结

Handler一般用于线程间通信，如常用的子线程使用handler让主线程更新UI。那么这是怎么实现的呢？

我们先把这个大问题分解成多个小问题：

1. post();postDelayed();sendMessage();sendEmptyMessage();等方法有什么不同？
2. Handler为什么需要一个Looper，为什么它不能为空？
3. Handler为什么可以做到线程间通信？
4. postDelayed()为什么可以让线程延迟执行？

接下来带着这些疑惑去寻找答案。

post();postDelayed();sendMessage();sendEmptyMessage();等方法有什么不同？

它们最终都是调用同一个方法：sendMessageAtTime()，只是参数不同，Handler帮我们进行了一下封装。

先看post();postDelayed();这两个方法，查看源码可以发现，这两个方法都是调用sendMessageDelayed(Message, long)。只是post()的时间这个参数是0。

代码如下：

public final boolean post(@NonNull Runnable r) {
   return  sendMessageDelayed(getPostMessage(r), 0);
}
public final boolean postDelayed(@NonNull Runnable r, long delayMillis) {
    return sendMessageDelayed(getPostMessage(r), delayMillis);
}
private static Message getPostMessage(Runnable r) {
    Message m = Message.obtain();
    m.callback = r;
    return m;
}

关键是将Runable任务封装成Message的这个getPostMessage()。

这里并不是简单地将Runable封装成Message，这里还有一个Message回收池机制的实现。将在下文展开介绍。

再看sendMessage();sendEmptyMessage();这两个方法：

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

可以看到这四个方法最终都是调用sendMessageDelayed():

public final boolean sendMessageDelayed(@NonNull Message msg, long delayMillis) {
    if (delayMillis < 0) {
        delayMillis = 0;
    }
    return sendMessageAtTime(msg, SystemClock.uptimeMillis() + delayMillis);
}

上面sendMessageDelayed()的实现都很简单，但需要注意的是这里使用了SystemClock.uptimeMillis()，它返回的是设备的开机时间(不包括息屏睡眠时间)，这个时间和Handler的消息可以延迟触发有关。将在后面详细介绍。

Handler为什么需要一个Looper，为什么它不能为空？

因为MessageQueue是通过Looper获取到的。

而Message需要通过MessageQueue来等待执行。

在创建Handler时如果检测到Looper为空，将会抛出NullPointerException错误

如果不是通过构造函数传入的Looper，比如Handler#Callback，构造方法会通过Looper.myLooper()获取到当前线程的Looper。

Looper.myLooper()可以获取到当前线程的Looper是因为ThreadLocal的特性。

代码如下：

public Handler(@Nullable Callback callback, boolean async) {
    mLooper = Looper.myLooper();
    if (mLooper == null) {
        throw new RuntimeException(
            "Can't create handler inside thread " + Thread.currentThread()
                    + " that has not called Looper.prepare()");
    }
    mQueue = mLooper.mQueue;
    mCallback = callback;
    mAsynchronous = async;
}

Handler为什么可以做到线程间通信？

Handler最长使用的大概是子线程通知UI线程更新UI吧。

我们通过post();sendMessage();等方法提交一个Message时，这个Message会被放入MessageQueue。在创建Handler时会得到一个Looper，Looper会循环从MessageQueue取出Message处理，而每个Looper属于一个线程，如果该Looper是UI线程的，那Message就是在UI线程处理。

知其然亦应知其所以然。

我们从Handler#post()这个方法开始研究。

在上面已经讲过，post()最终调用的是sendMessageAtTime()，这个方法首先是获取了与该Handler绑定Looper的MessageQueue对象，然后通过一些参数设置，最后执行MessageQueue#enqueueMessage()方法。

MessageQueue#enqueueMessage()

看方法名就知道这个方法主要工作是对Message排队处理：

boolean enqueueMessage(Message msg, long when) {
	//...
    synchronized (this) {
        if (msg.isInUse()) {
            throw new IllegalStateException(msg + " This message is already in use.");
        }
		//...
        msg.markInUse();
        msg.when = when;
        Message p = mMessages;
        boolean needWake;
        if (p == null || when == 0 || when < p.when) {
            msg.next = p;
            mMessages = msg;
            needWake = mBlocked;
        } else {
            Message prev;
            for (;;) {
                prev = p;
                p = p.next;
                if (p == null || when < p.when) {
                    break;
                }
                //...
            }
            msg.next = p; // invariant: p == prev.next
            prev.next = msg;
        }
      //...
    }
    return true;
}

我去掉了一些和排队无关的代码，上面这段代码并不难，就是以链表的形式将Message进行排列。

首先判断这个Message是否正在被使用。

Message什么情况下是被使用状态呢？

其实这个也和Message回收池有些关系。

我们new的对象和回收池中取出的Message默认状态是0，当Message进入MessageQueue等待处理时就是被使用状态。从MessageQueue取出，被处理完成回收的Message其状态又会被重置为0 。

回到Message排队问题，然后判断三个条件：

1. Message链表是否为空
2. when == 0
   1. 这种情况只有调用Handler#sendMessageAtFrontOfQueue()才会出现
3. when < p.when
   1. when表示消息将在什么时候执行，数字越小的排在前面

当其中一个条件满足时，将当前Message插入链表头部。

既然Message时怎么放入MessageQueue这块已经弄清楚了，那接着看一下Looper。看看是怎么取出Messages，又是怎么处理的

Looper

如果使用过Looper就应该知道，这是一个循环。

查看这个类的注释，可以看到它提供了一个简单的用法。

Looper.prepare();
Looper.loop();

主要有两个方法：

1. 第一个在当前线程创建Looper对象并放入ThreadLocal中，
2. 第二个循环MessageQueue，取出其中的Message在当前线程处理

Looper实现在这里不进行深入，只讲一下和MessageQueue有关的。

先看loop():

//Looper
public static void loop() {
    final Looper me = myLooper();
    //...
    for (;;) {
        if (!loopOnce(me, ident, thresholdOverride)) {
            return;
        }
    }
}
private static boolean loopOnce(final Looper me,
        final long ident, final int thresholdOverride) {
    Message msg = me.mQueue.next(); // might block
    if (msg == null) {
	    // No message indicates that the message queue is quitting.
	    return false;
	}
    //。。。
    msg.target.dispatchMessage(msg);
	//。。。
    msg.recycleUnchecked();
    return true;
}

//Handler
public void dispatchMessage(@NonNull Message msg) {
    if (msg.callback != null) {
        handleCallback(msg);
    } else {
        if (mCallback != null) {
            if (mCallback.handleMessage(msg)) {
                return;
            }
        }
        handleMessage(msg);
    }
}

可以看到loop()里面用for写了一个死循环，它执行了loopOnce()，它是真正取出Message并执行的方法。

在dispatchMessage()方法内，首先判断callback是否为空，它是Message的Runable，就是我们使用post();postDelayed();提交到Runable。

然后判断Handler#Callback，是否为空，这个是在Handler构造方法传入的Callback，这里也解释了当我们实现了callback时可以跨线程通信的原因。

当next()返回null会结束for循环。我们Android主线程没有消息为什么还可以继续运行？

我们创建Looper对象都是通过其静态方法来创建的，而Looper的构造方法有一个参数quitAllowed，这个参数为True时MessageQueue不会因为消息为空而退出。

private Looper(boolean quitAllowed) {
    mQueue = new MessageQueue(quitAllowed);
    mThread = Thread.currentThread();
}

postDelayed()为什么可以让线程延迟执行？

让我们回到上面Looper#loopOnce()这个方法，我在上面没有介绍怎么从MessageQueue取出Message就是留给这个问题的。

线上关键代码：

//MessageQueue
Message next() {
	for (;;) {
        synchronized (this) {
	        //获取当前的开机时间
            final long now = SystemClock.uptimeMillis();
            Message prevMsg = null;
            Message msg = mMessages;
            if (msg != null) {
	            //判断当前开机时间是否小于msg的开机时间
	            //如果为false表示这条消息应该被拿出去处理了
                if (now < msg.when) {
                    nextPollTimeoutMillis = (int) Math.min(msg.when - now, Integer.MAX_VALUE);
                } else {
                    // Got a message.
                    if (prevMsg != null) {
                        prevMsg.next = msg.next;
                    } else {
                        mMessages = msg.next;
                    }
                    msg.next = null;
                    if (DEBUG) Log.v(TAG, "Returning message: " + msg);
                    msg.markInUse();
                    return msg;
                }
            }
            //。。。
        }
	}
}

这块代码还是很多的，我去掉了和该问题无关的代码。

这里先获取了当前开机时间，然后和Message的when对比，如果当前开机时间比when大，表示这条消息到了处理时间，直接return。

我们使用postDelayed(Runnable,0)时，执行到sendMessageDelayed()后会加上SystemClock.uptimeMillis()最后变成when值，也就是SystemClock.uptimeMillis()+0，

因此MessageQueue取出消息时，该Message会被立即执行，而延迟xxx时间是一样的道理。

Message回收池是怎么回事？

让我们回到上面展示的Looper#loopOnce()这个方法，可以看到当消息被取出来处理后，调用了msg.recycleUnchecked();回收当前Message：

void recycleUnchecked() {
    // Mark the message as in use while it remains in the recycled object pool.
    // Clear out all other details.    flags = FLAG_IN_USE;
    what = 0;
    arg1 = 0;
    arg2 = 0;
    obj = null;
    replyTo = null;
    sendingUid = UID_NONE;
    workSourceUid = UID_NONE;
    when = 0;
    target = null;
    callback = null;
    data = null;  

    synchronized (sPoolSync) {
        if (sPoolSize < MAX_POOL_SIZE) {
            next = sPool;
            sPool = this;
            sPoolSize++;
        }
    }
}

这个方法会重置Message参数，然后判断当前回收池有没有达到上限，上限是50个，没有达到会把这个Message插入链表等待再次使用。

public static Message obtain() {
    synchronized (sPoolSync) {
        if (sPool != null) {
            Message m = sPool;
            sPool = m.next;
            m.next = null;
            m.flags = 0; // clear in-use flag
            sPoolSize--;
            return m;
        }
    }
    return new Message();
}

Message.obtain()会检查回收池，如果回收池不为空，从链表头部取出一个对象并返回。

在Google官方文档也能看到，Google建议我们通过Message.obtain()获取一个新的Message对象，而不是直接new。

总结

handler的这个机制是由几个类一起协作共同实现的。它们分别是：

1. Handler
   • Handler：负责协调各个类的工作，以达到这个机制的功能。
2. Looper
   • Looper：一个Looper对象属于一个线程，由它来管理此线程里的MessageQueue(消息队列)
3. MessageQueue
   • MessageQueue：消息队列，负责管理Message，以及延迟Message处理
4. Message
   • Message：用于存放需要发送的数据，将数据包装为消息对象。管理回收池等。

扩展知识

1. MessageQueue