Handler机制详解(一) —— Handler是如何实现跨线

对Android开发来说Handler机制是很重要的也是面试必问的一点，相信大家也都能说出它的基本运行机制。

由Handler, Looper, Message, MessageQueue几部分组成，当Handler通过sendMessage()或postRunnable()将Message添加到MessageQueue中，再由Looper.loop()从MessageQueue中取出交由Handler处理。Looper.loop()就是个死循环，一直在从MessageQueue中获取Message。

这是我最初入行时在面试中的回答，你说它不对吧，也就那么回事。你说它对吧，又远不够详细。比如：

1. Handler是如何实现跨线程操作？
2. 既然Looper.loop()是死循环，为什么没有占用大量的cpu消耗呢？
3. 为什么主线程不会因Looper.loop()里的死循环卡死？

这篇先来看看第一个问题：

Handler是如何实现跨线程操作？

我们先来看看通过Handler发送到MessageQueue的message是如何被Looper.loop()拿出来去处理的。

public static void loop() {
    // 获取当前线程的looper对象，没有则抛出异常
    final Looper me = myLooper();
    if (me == null) {
        throw new RuntimeException("No Looper; Looper.prepare() wasn't called on this thread.");
    }

    me.mInLoop = true;
    // 获取looper中的MessageQueue对象
    final MessageQueue queue = me.mQueue

    // 开始循环
    for (;;) {
        // 从queue中获取message，next()里面也是死循环，当没有消息时会阻塞，
        // 调用MessageQueue.quit()后会清空队列中消息并返回null，此时looper也会跳出死循环，中止loop
        Message msg = queue.next(); // might block
        if (msg == null) {
            // No message indicates that the message queue is quitting.
            return;
        }
        
        ...
        ...
        
        try {
            // msg.target就是message中绑定的Handler对象，通过调用Handler的dispatchMessage(msg)来真正处理message
            // 不管是sendMessage还是postRunnable都会在最终将message插入队列时为message绑定handler
            msg.target.dispatchMessage(msg);
        } catch (Exception exception) {
            ...
        } finally {
            ...
        }

        ...
    }
}

public void dispatchMessage(@NonNull Message msg) {
    // 优先使用message中的callback来处理
    if (msg.callback != null) {
        handleCallback(msg);
    } else {
        // 如果message没有设置callback，则使用handler中的callback来处理
        if (mCallback != null) {
            if (mCallback.handleMessage(msg)) {
                return;
            }
        }
        
        // 两个callback都没有设置的情况下则调用handleMessage()来处理
        handleMessage(msg);
    }
}

从上述代码中我们可以看出是在loop()中通过queue.next()取出message，再调用message中绑定的handler的dispatchMessage()去处理message。

既然如此，那是否就是Looper.loop()在哪个线程调用，dispatchMessage()或者说最终message的处理就在哪个线程被执行？

那Looper.loop()又是在哪里被执行的呢？

上面我们看到了在loop()中第一步就是通过myLooper()获取Looper对象，再从looper对象中获取到对应的MessageQueue，我们来看一看myLooper()的实现.

/**
 * Return the Looper object associated with the current thread.  Returns
 * null if the calling thread is not associated with a Looper.
 */
public static @Nullable Looper myLooper() {
    return sThreadLocal.get();
}

static final ThreadLocal<Looper> sThreadLocal = new ThreadLocal<Looper>();

可以看到它只是很简单的使用sThreadLocal.get()获取Looper对象而已，那ThreadLocal又是什么呢？简单来说就是每个线程对其进行访问时都是线程自己的变量，或者说它对每个线程都有自己的独立空间来存储数据。我们不对他做详细解释，可以参考官方注释：

This class provides thread-local variables. These variables differ from their normal counterparts in that each thread that accesses one (via its get or set method) has its own, independently initialized copy of the variable. ThreadLocal instances are typically private static fields in classes that wish to associate state with a thread (e.g., a user ID or Transaction ID).

我们接着来看，可以看到sThreadLocal的set()是在prepare()中被调用，它也是静态方法。那就是说我们可以直接通过Looper.prepare()去为当前线程(方法执行时的线程)构造Looper
对象，并且它会存储在Looper中的sThreadLocal变量中，同时会在初始化前做校验来保证每个线程只能初始化一次。而ThreadLocal的特性保证了我们在任何地方调用myLooper()都会获取到当前线程对应的Looper对象。

public static void prepare() {
    prepare(true);
}

private static void prepare(boolean quitAllowed) {
    if (sThreadLocal.get() != null) {
        throw new RuntimeException("Only one Looper may be created per thread");
    }
    sThreadLocal.set(new Looper(quitAllowed));
}

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

我们再回到问题本身，答案已经明了，我们在创建Handler时传入了与线程绑定的Looper对象，因为最终对message的处理是在Looper.loop()中完成的，所以通过Handler发送的message消息都会在Looper对象对应的线程中执行，其实与Handler创建的线程无关(当你为Handler传入looper对象时)。

例如，在A线程中创建Handler对象h并传入A线程的Looper对象，并调用了loop()，那么你在任意线程使用h对象发送的message最终都会在A线程被处理。因为你发送的Message会在被A线程执行的loop()内取出并处理。

---

如有错误，欢迎大家评论里指正，不胜感激。