Android 消息机制
Android 消息机制也就是 Handler 的运行机制，Handler 运行时需要底层的 Looper 和 MessageQueue 的支持，Handler 作为上层的接口，所以我们开发时大部分情况只需要与 Handler 交互就可以了，并未过多涉及到 Looper 和 MessageQueue。下面将从使用的角度结合源码分析 Handler 的运行机制。
平常我们主要使用 Handler 进行线程通信，比如：子线程向主线程发送消息，子线程之间发送消息，如下代码完成了 2 个子线程之间发送消息：
Handler mHandler = null;
private void test() {
new Thread(new Runnable() {
@Override
public void run() {
for (int index = 0; index < 5; index++) {
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
e.printStackTrace();
}
Message message = Message.obtain();
message.what = index;
mHandler.sendMessage(message);
}
}
}).start();
new Thread(new Runnable() {
@Override
public void run() {
Log.i("zx", "线程名称: " + Thread.currentThread().getName());
Looper.prepare();
mHandler = new Handler() {
@Override
public void handleMessage(@NonNull Message msg) {
super.handleMessage(msg);
Log.i("zx", "msg.what=" + msg.what);
}
};
Looper.loop();
}
}).start();
}
打印结果如下：
msg.what=0
msg.what=1
msg.what=2
msg.what=3
msg.what=4
上方的线程每隔 1 秒发送一次消息给下方的线程，下方的线程每隔 1 秒会自动调用 handleMessage() , 并能接收到消息内容。 sendMessage() 内部到底是什么逻辑，使得处于另一个线程中的 handleMessage() 会被自动调用呢？ Looper.prepare() 又是什么？为什么主线程里创建 Handler 时不需要写呢？带着这些疑问，我们跳进源码里一探究竟。先从 Handler 的构造函数开始看吧。
public Handler() {
this(null, false);
}
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;
}
构造函数里会先获取 looper，然后检查 looper 是否为空，如果为空就抛出异常，那这个 looper 什么情况会为空呢，或者说 looper 是什么时候初始化的呢？那就在 Handler 源码里搜索一下 [new Looper] 关键字，发现并没有结果，继续在 Looper 的源码里搜索，发现 Looper 的 prepare 静态里 new 了一个 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));
}
prepare 里初始化了 Looper，并将其 set 到 ThreadLocal 中。ThreadLocal可以简单理解为每一个线程的独立存储区域，每个线程都有一个副本，以线程为作用域存取，每个线程只能获取自己的ThreadLocal中存的数据，更多关于 ThreadLocal 的知识和源码，请参考我的这一篇文章。所以如果先 Looper.prepare()，接着 new Handler()，由于是在同一个线程中，Handler 构造函数中就能获取到 looper，就不会抛出异常，反之肯定会抛出异常。至于这个 Looper 是什么，咱先不管，继续往下看吧。
接着，追踪一下 Handler 的 sendMessage ，看看 sendMessage 内部是什么逻辑。贴上 sendMessage 的源码：
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;//注释1
if (queue == null) {
RuntimeException e = new RuntimeException(
this + " sendMessageAtTime() called with no mQueue");
Log.w("Looper", e.getMessage(), e);
return false;
}
return enqueueMessage(queue, msg, uptimeMillis);//注释2
}
private boolean enqueueMessage(@NonNull MessageQueue queue, @NonNull Message msg,
long uptimeMillis) {
msg.target = this;//注释3
msg.workSourceUid = ThreadLocalWorkSource.getUid();
if (mAsynchronous) {
msg.setAsynchronous(true);
}
return queue.enqueueMessage(msg, uptimeMillis);//注释4
}
注释 2 那一行可以看到 sendMessage 最后调用了 Handler 的 enqueueMessage ，enqueueMessage 中对 Message 进行了一次包装，注释 3 那一行将 Message 的 target 指向了 Handler 自己，这里很重要，后边会讲到，暂且不管。注释 4 那一行显示调用了 queue 的 enqueueMessage ，从注释 1 可以知道 queue 就是 Handler 的 mQueue，而这个 mQueue 就是 Looper 的 mQueue(见 Handler 构造)，这个 mQueue 是 MessageQueue 类的实例。也就是说，Handler 的 sendMessage 最终调用了它的 Looper 的 MessageQueue 的 enqueueMessage() ，根据名称可以大致推测 MessageQueue 是一个消息队列，enqueueMessage 是一个入队操作，看看 enqueueMessage 源码是不是如我们所想
boolean enqueueMessage(Message msg, long when) {
synchronized (this) {
//省略部分代码
msg.markInUse();
msg.when = when;
Message p = mMessages;
boolean needWake;
//关键部分
if (p == null || when == 0 || when < p.when) {
// New head, wake up the event queue if blocked.
msg.next = p;
mMessages = msg;
needWake = mBlocked;
} else {
// Inserted within the middle of the queue. Usually we don't have to wake
// up the event queue unless there is a barrier at the head of the queue
// and the message is the earliest asynchronous message in the queue.
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; // invariant: p == prev.next
prev.next = msg;
}
// We can assume mPtr != 0 because mQuitting is false.
if (needWake) {
nativeWake(mPtr);
}
}
return true;
}
源码略长，可以只看关键部分，确实如我们所想，将消息插入到队列，不过这里使用单链表（源码中有 p.next 等）实现的先进先出队列。
既然 sendMessage() 是将消息插入队列，那什么时候取出呢？由谁取出呢？目前我们已经遇到了 Handler、Looper、MessageQueue 三个类，源码都很长，一点点看，怕是要绕晕。那我们就先不管谁在什么时候取出的消息，先看看是谁回调了 Handler 的 handleMessage() 吧，因为不管是谁取出了消息，最终的目的都是调用 handleMessage() 处理，那从 handleMessage() 逆向追踪不就行了嘛。由于 sendMessage() 是实现了 Handler 的 sendMessage()，所以看看 Handler 的 sendMessage() 被谁调用了。一搜索就出来了（其实不搜索也能出来，就在 sendMessage 的下一行），代码如下：
public void dispatchMessage(@NonNull Message msg) {
if (msg.callback != null) {
handleCallback(msg);
} else {
if (mCallback != null) {
if (mCallback.handleMessage(msg)) {
return;
}
}
handleMessage(msg);
}
}
可以看到 dispatchMessage() 调用了 handleMessage() ，搜索一下，看看哪里调用了 dispatchMessage()。发现 Looper 的 loop() 中调用了 dispatchMessage()，看到这个 loop() ，是不是就熟悉了呢，一开始 Handler 使用例子里，在初始化 Handler 之后就调用了 loop() 。下边贴上 loop() 的源码：
public static void loop() {
//省略部分代码
for (;;) {
Message msg = queue.next(); // might block
if (msg == null) {
// No message indicates that the message queue is quitting.
return;
}
//省略部分代码
try {
msg.target.dispatchMessage(msg);
//省略部分代码
} catch (Exception exception) {
//省略部分代码
throw exception;
} finally {
//省略部分代码
}
//省略部分代码
msg.recycleUnchecked();
}
}
从源码中看到 loop() 是一个死循环，死循环中会调用 Looper 的 MessageQueue 的 next() ，并将其赋值给 Message 对象，只有当 next() 返回空时死循环才会结束，也就是 Looper 所在线程才会结束。取出的 Message 调用了 target.dispatchMessage() ，之前的分析我们已经知道 target 就是那个调用了 sendMessage() 的 Handler，所以是这里调用了 Handler 的 dispatchMessage() ，我们找到了 handleMessage() 回调的源头。根据名称以及赋值操作，我们可以猜想 next 就是从队列中取出下一个消息的，看看 next 的源码是不是这样。
Message next() {
for (;;) {
//省略部分代码
nativePollOnce(ptr, nextPollTimeoutMillis);
synchronized (this) {
// Try to retrieve the next message. Return if found.
final long now = SystemClock.uptimeMillis();
Message prevMsg = null;
Message msg = mMessages;
if (msg != null && msg.target == null) {
// Stalled by a barrier. Find the next asynchronous message in the queue.
do {
prevMsg = msg;
msg = msg.next;
} while (msg != null && !msg.isAsynchronous());
}
if (msg != null) {
if (now < msg.when) {
// Next message is not ready. Set a timeout to wake up when it is ready.
nextPollTimeoutMillis = (int) Math.min(msg.when - now, Integer.MAX_VALUE);
} else {
// Got a message.
mBlocked = false;
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;
}
} else {
// No more messages.
nextPollTimeoutMillis = -1;
}
// Process the quit message now that all pending messages have been handled.
if (mQuitting) {
dispose();
return null;
}
}
}
}
这里也是一个死循环，死循环中有一个 nativePollOnce native 方法 ，类似于 java 的 Object.wait()，nativePollOnce 将一直阻塞，直到有新的 Message 到来时才会被唤醒，并继续执行后续的 return Message 代码。之前的 enqueueMessage() 中有一个 nativeWake()调用代码，nativeWake()类似于 java 的 Object.notify()，用于消息队列插入新 Message 时唤醒线程。这两个 native 层的方法无须关注太多，只需到知道 next()是一个阻塞方法，有新 Message 时会返回新 Message，没有新 Message 时线程会阻塞，并不会浪费 CPU 周期。
上边源码最后两行显示，当 mQuitting 标记位为 true 时 next()会返回 null ，loop()里的死循环就会跳出，线程就会终止，搜索 mQuitting 关键字发现 在 MessageQueue 类的 quit()将 mQuitting 赋值为 true，继续追踪 quit()，发现 Looper 的 quit()和 quitSafely()调用了此方法，代码如下：
public void quit() {
mQueue.quit(false);
}
public void quitSafely() {
mQueue.quit(true);
}
从名称和注释中可以知道，这两个方法都可以退出 looper() 死循环，区别是：quit 会立即退出，quitSafely 会将当前消息队列中剩余消息处理完成再退出。quit 和 quitSafely 调用后，再次调用 Handler.sendMessage()会返回 false，也就是说，不再接受并处理消息了，Handler 所在线程也会终止。所以子线程用完 Handler 之后，一定要及时调用 Handler.getLooper().quitSafely();
再回到一开始的那个问题，为什么主线程创建 Handler 时不需要写 Looper.prepare()呢，看看主线程的代码就很清楚了
public static void main(String[] args) {
Looper.prepareMainLooper();
ActivityThread thread = new ActivityThread();
thread.attach(false, startSeq);
if (sMainThreadHandler == null) {
sMainThreadHandler = thread.getHandler();
}
Looper.loop();
throw new RuntimeException("Main thread loop unexpectedly exited");
}
在整个 app 的入口 main 中,调用了 prepareMainLooper()，创建了主线程的 Looper，并调用了 loop()，所以主线程从应用程序启动开始，就有了 Looper，也就不需要再手动调用 prepare()了。并且 prepareMainLooper()调用 prepare(boolean quitAllowed)时传入了 false，也就是不允许主线程的 Looper 退出，所以主线程的 Handler 不能调用 getLooper().quitSafely()和 quit()，否则就会抛出 Main thread not allowed to quit 异常。
看到这里，整个调用流程就很清晰了：在每个线程 new Handler()时，这个线程必须要有一个 Looper，Looper保存在线程的ThreadLocal中，在整个线程中全局可取出。这个 Looper 里有一个 MessageQueue，sendMessage()就是往MessageQueue中插入消息。同时Looper 的 loop()会循环从消息队列中去取 Message，每取出一个 Message，就会调用发出这个 Message 的 Handler 的 handleMessage()。取不出 Message 时，线程会阻塞等待。当取出 null 时，表示调用了 Looper 的 quit()或 quitSafely()，此时会跳出 loop()里的死循环并终止线程。通过死循环和阻塞的机制，既可以快速响应，又不会浪费性能
