说起 Android 里的 Handler，必少不了下面这张 Handler，MessageQueue，Looper 关系图。

Handler MessageQueue 与 Looper

Handler 发送和处理事件过程：
① 创建一个 Message，传递给 Handler
② Handler 接收到 Message 之后，立马将其添加到 MessageQuere
③ Looper 会不断的从 MessageQuere 中取出头部 Message
④ 将 Message 交给对应的 Handler 去处理

下面我们从源码角度，对上面的过程进行一一剖析。

Handler 主流程分析

使用Handler发送Message

我们一般使用下面的代码将一个 Message 发送给 Handler。
（Handler 的发送 Message 方法有很多，如使用 sendEmptyMessage 发送一个空的消息，使用 sendMessageDelayed 发送一个延迟消息，但不管那个方法，都只是在外部对 Message 处理了一下，内部实现逻辑完全一致，在这里我们就单独看 sendMessage 即可。）

handler.sendMessage(new Message());

接下来我们进入 Handler 内部。

public final boolean sendMessage(@NonNull Message msg) {
    return sendMessageDelayed(msg, 0);
}

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

public boolean sendMessageAtTime(@NonNull Message msg, long uptimeMillis) {
    MessageQueue queue = mQueue;
    ······
    return enqueueMessage(queue, msg, uptimeMillis);
}

private boolean enqueueMessage(@NonNull MessageQueue queue, @NonNull Message msg,
        long uptimeMillis) {
    msg.target = this;
    msg.workSourceUid = ThreadLocalWorkSource.getUid();
    if (mAsynchronous) {
        msg.setAsynchronous(true);
    }
    return queue.enqueueMessage(msg, uptimeMillis);
}

从上面的代码我们可以看到，Message 在 Handler 内部经过一系列的方法传递，带上发送时间，最终通过 MessageQueue 的 enqueueMessage 方法，添加到 MessageQueue 中。注意在添加到 MessageQueue 之前，Handler 将 Message 的 target 参数赋值为自身，这个在最后事件处理时会用到。

将Message添加到MessageQueue

我们再进到 MessageQueue 的 enqueueMessage 方法看一下。

boolean enqueueMessage(Message msg, long when) {
    ······
    synchronized (this) {
        ······
        msg.when = when;
        Message p = mMessages;
        boolean needWake;
        if (p == null || when == 0 || when < p.when) {
            msg.next = p;
            mMessages = msg;
            needWake = mBlocked;
        } else {
            needWake = mBlocked && p.target == null && msg.isAsynchronous();
            Message prev;
            for (;;) {
                prev = p;
                p = p.next;
                if (p == null || when < p.when) {
                    break;
                }
                if (needWake && p.isAsynchronous()) {
                    needWake = false;
                }
            }
            msg.next = p;
            prev.next = msg;
        }
        if (needWake) {
            nativeWake(mPtr);
        }
    }
    return true;
}

从 enqueueMessage 方法我们看出，MessageQueue 内部是使用链表实现的，当一条新的消息添加进来时，按照发送时间进行排序，时间在前的排在链表前面。

Looper 循环读取 Message

在 Looper 的 loop 方法中，会无限循环的从 MessageQueue 中读取最新的 Message。loop 的代码比较长，这里删减了很多，不影响分析主流程。

public static void loop() {
    final Looper me = myLooper();
    ······
    final MessageQueue queue = me.mQueue;
    ······
    for (;;) {
        Message msg = queue.next();
        if (msg == null) {
            return;
        }
        ······
        msg.target.dispatchMessage(msg);
        ······
    }
}

在 loop 方法中我们可以看到的确是通过一个死循环不断的通过 MessageQueue 的 next 方法取到最新的 Message，除非取到的 Message 为 null 退出死循环。取到不为 null 的 Meesage 之后，通过 Message 内部 target 的 dispatchMessage 方法将 Message 事件发送出去，target 就是前面提及的 Handler。

我们再回到 MessageQueue 中，看一下 next 方法的具体实现（省略部分非关键代码）。

Message next() {
    final long ptr = mPtr;
    if (ptr == 0) {
        return null;
    }
    ······
    int nextPollTimeoutMillis = 0;
    for (; ; ) {
        ······
        nativePollOnce(ptr, nextPollTimeoutMillis);
        synchronized (this) {
            final long now = SystemClock.uptimeMillis();
            Message prevMsg = null;
            Message msg = mMessages;
            if (msg != null && msg.target == null) {
                do {
                    prevMsg = msg;
                    msg = msg.next;
                } while (msg != null && !msg.isAsynchronous());
            }
            if (msg != null) {
                if (now < msg.when) {
                    nextPollTimeoutMillis = (int) Math.min(msg.when - now, Integer.MAX_VALUE);
                } else {
                    mBlocked = false;
                    if (prevMsg != null) {
                        prevMsg.next = msg.next;
                    } else {
                        mMessages = msg.next;
                    }
                    msg.next = null;
                    msg.markInUse();
                    return msg;
                }
            } else {
                nextPollTimeoutMillis = -1;
            }
            if (mQuitting) {
                dispose();
                return null;
            }
            ······
        }
        ······
        nextPollTimeoutMillis = 0;
    }
}

从 next 方法中我们可以看出，内部也是通过死循环取到当前需要发送的 Message 返回回去，如果mQuitting 变量为 true 返回 null，而 mQuitting 会在 quit 方法中置为 true。

void quit(boolean safe) {
    ······
    synchronized (this) {
        if (mQuitting) {
            return;
        }
        mQuitting = true;
        ······
    }
}

Handler 处理 Message

在 Looper 中，从 MessageQueue 取到 Message 之后，会调用 Handler 的 dispatchMessage 方法处理事件。

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

在 dispatchMessage 方法实现中我们可以看到，如果 Message 的 callback 不为空，就调用 handleCallback 方法，如果为空，那么会再判断 mCallback 是否为空，如果 mCallback 不为空，直接调用 mCallback 的 handleMessage 方法，否则会走到自身的 handleMessage 方法中。

上述 Message 的 callback，即通过如下方法创建 Message 时传入的 Runnable。

Message.obtain(handler, new Runnable() {
    @Override
    public void run() {
    }
});

mCallback 为通过如下方式创建 Handler 时传入的回调接口。

new Handler(new Handler.Callback() {
    @Override
    public boolean handleMessage(@NonNull Message msg) {
        return true;
    }
});

通过上面的分析，我们了解了 Handler 的基本工作流程，但仔细思考一下，还是会有很多疑问。
1、MessageQueue 和 Handler，Looper 是如何关联起来的？
2、Looper 中通过死循环从 MessageQueue 中读取消息，这不会导致 APP 卡死吗？

关于 Handler 的两个疑问

MessageQueue 和 Handler，Looper 是如何关联起来的？

要搞清这个问题，我们先看 Looper 的构造方法。

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

Looper 的构造方法内创建了 MessageQueue，并将其保存为自己的内部属性，即 Looper 持有了 MessageQueue。由于构造方法是私有的，我们再看看哪里调用了。

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

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

private static void prepare(boolean quitAllowed) {
    ······
    sThreadLocal.set(new Looper(quitAllowed));
}

public static void prepareMainLooper() {
    prepare(false);
    synchronized (Looper.class) {
        ······
        sMainLooper = myLooper();
    }
}

在 prepare(boolean) 方法内会 new 一个 Looper，并将其 set 到 ThreadLocal 中，prepare(boolean) 方法又会被 prepare() 和 prepareMainLooper() 调用，prepareMainLooper() 即创建 UI 线程的 Looper，该方法会在程序的入口 main 方法里调用（最后会调用 Looper 的 loop 方法），这里不再深究。在子线程中使用 Handler，我们需要手动调用一次 Looper 的 prepare 方法，来创建子线程的 Looper，最后再调用一次 Looper 的 loop 方法，开启消息读取。

在上面的 Looper 的 loop 源码第一行中，通过 myLooper 方法取到 Looper。

public static @Nullable Looper myLooper() {
    return sThreadLocal.get();
}

在上面的 Handler 的sendMessageAtTime 源码第一行中，突然出现一个 MessageQueue（再贴一下源码）。

public boolean sendMessageAtTime(@NonNull Message msg, long uptimeMillis) {
    MessageQueue queue = mQueue;
    ······
    return enqueueMessage(queue, msg, uptimeMillis);
}

通过跟踪源码，会发现 mQueue 是在 Handler 的构造方法内赋值，不管通过那个构造方法创建 Handler，最终都会走到下面的构造方法。

public Handler(@Nullable Callback callback, boolean async) {
    ······
    mLooper = Looper.myLooper();
    ······
    mQueue = mLooper.mQueue;
    mCallback = callback;
    mAsynchronous = async;
}

我们可以看到也是通过 Looper.myLooper() 方法取到 Looper。
通过上面的分析我们可以了解到，MessageQueue 被 Looper 持有，Handler 也是通过 Looper 拿到 MessageQueue。在 Looper 内部，MessageQueue 创建完后被添加到 ThreadLocal 中，后续也是从 ThreadLocal 中取到 MessageQueue。
那么 ThreadLocal 是什么呢？为什么这里要使用 ThreadLocal 存储 MessageQueue？
ThreadLocal 在 Java API 中是这样解释的。

该类提供了线程局部 (thread-local) 变量。这些变量不同于它们的普通对应物，因为访问某个变量（通过其get或set方法）的每个线程都有自己的局部变量，它独立于变量的初始化副本。ThreadLocal实例通常是类中的 private static 字段，它们希望将状态与某一个线程（例如，用户 ID 或事务 ID）相关联。

说人话就是在 A 和 B 线程中分别给同一个 ThreadLocal set 一个值，然后在 A 线程中 get 到的就是在 A 线程中 set 的值，在 B 线程中 get 到的就是在 B 线程中 set 的值。Looper 在待接收 Handler 事件的线程中添加到 ThreadLocal 中，也是在该线程中获取 Looper（对应 Looper 的 loop 方法和 Handler 的构造方法），这就保证了 Handler 只会接收到创建时所属线程的消息。

Looper 中通过死循环从 MessageQueue 中读取消息，这不会导致 APP 卡死吗？

首先让我们先看一下 APP 的 main 方法源码，只贴出需要关心的关键代码。

public static void main(String[] args) {
    ······
    Looper.prepareMainLooper();
    ······
    Looper.loop();
    throw new RuntimeException("Main thread loop unexpectedly exited");
}

在 main 方法中，首先调用 Looper 的 prepareMainLooper 方法，创建 Looper 和 MessageQueue，最后调用 Looper 的 loop 方法，正常情况下程序便会停留在 loop 方法这一行，在 loop 方法中不断的处理主线程所有的事件，比如每一个点击触摸或者 Activity 的生命周期，APP 整个生命周期就运行在这套无限循环的事件驱动中。如果代码能够继续往下执行，main 方法执行结束，此时 APP 就因为崩溃闪退了。

了解了 APP 的持续运行必须依赖 loop 的死循环，那么死循环一直运行是不是特别消耗CPU资源呢？其实不然，注意在 MessageQueue 的 next 方法中有这样一行。

nativePollOnce(ptr, nextPollTimeoutMillis);
private native void nativePollOnce(long ptr, int timeoutMillis);

nextPollTimeoutMillis 为下一条消息将要发送的时间，nativePollOnce 是 native 方法，通过查询资料发现，在这个方法中会让线程进入休眠状态，直到下一条事件发送时间来临或者 MessageQueue 中插入一条新事件。

在 MessageQueue 的 enqueueMessage 方法中，最后有如下代码，实现插入新事件时唤醒线程（注意插入消息是在子线程中，不会受到主线程的阻塞影响）。

if (needWake) {
    nativeWake(mPtr);
}

本文参考：
《Android 开发艺术探索》
Handler中有Loop死循环，为什么没有阻塞主线程，原理是什么？
Handler机制原因，主线程looper.loop()为什么不阻塞主线程