说起 Android 里的 Handler，必少不了下面这张 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()为什么不阻塞主线程
