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()里的死循环并终止线程。通过死循环和阻塞的机制,既可以快速响应,又不会浪费性能