从源码角度分析Android的消息机制
前言
说到Android的消息机制，那么主要的就是指的Handler的运行机制。其中包括MessageQueue以及Looper的工作过程。
在开始正文之前，先抛出两个问题：
- 为什么更新UI的操作要在主线程中进行？
- Android中为什么主线程不会因为Looper.loop()里的死循环卡死？
UI线程的判断是在ViewRootImpl中的checkThread方法中完成的。
对于第一个问题，这里给一个简单的回答：
如果可以在子线程中修改UI，多线程的并发访问可能会导致UI控件的不可预期性，采用加锁的方式，就会降低UI的访问效率以及会阻塞其他线程的执行，所以最简单有效的方法就是采用单线程模型来处理UI操作。
Handler的运行离不来底层的MessageQueue和Looper的支撑。MessageQueue翻译过来是一个消息队列，里面存储了Handler需要的Message，MessageQueue并不是一个队列，其实上是用单链表的数据结构来存储Message。
那么Handler如何拿到Message呢？这时候就需要Looper了，Looper通过Looper.loop()来开启一个死循环，不断从MessageQueue中取消息然后传递给Handler。
这里还有另一个知识点就是Looper的获取，这里就要提高一个存储类：ThreadLocal
ThreadLocal的工作原理
ThreadLocal是线程内部的一个数据存储类，可以存储某个线程中的数据，对于其他线程无法获取该线程的数据。我们通过原理来看一下，这个观点是否正确。
public void set(T value) {
Thread t = Thread.currentThread();
ThreadLocalMap map = getMap(t);
if (map != null)
map.set(this, value);
else
createMap(t, value);
}
public T get() {
Thread t = Thread.currentThread();
ThreadLocalMap map = getMap(t);
if (map != null) {
ThreadLocalMap.Entry e = map.getEntry(this);
if (e != null) {
@SuppressWarnings("unchecked")
T result = (T)e.value;
return result;
}
}
return setInitialValue();
}
可以看出它的set和get方法就是在当前线程中所做的操作，ThreadLocalMap内部是一个数组table。 这样就保证了在不同线程中的数据互不干扰。
ThreadLocal除了使用在Handler中获取Looper，还用于一些复杂的场景，比如：监听器的传递。
我们简单了解了ThreadLocal，那么我们从New Handler()来一步步梳理下消息机制。
Looper的工作原理
// Handler.java
public Handler() {
this(null, false);
}
// callback 消息回调；async 是否同步
public Handler(Callback callback, boolean async) {
...
// 1. 首先获取looper
mLooper = Looper.myLooper();
if (mLooper == null) {
throw new RuntimeException(
"Can't create handler inside thread " + Thread.currentThread()
+ " that has not called Looper.prepare()");
}
// 2. 获取MessggeQueue
mQueue = mLooper.mQueue;
mCallback = callback;
mAsynchronous = async;
}
我们平常用的是无参数的方法，它传入的是空的回调以及false。
public static @Nullable Looper myLooper() {
return sThreadLocal.get();
}
这里就出现了我们之前说的ThreadLoacal类，那么looper值是什么时候设置进去的呢？
它的设置方法其实是在prepare方法以及prepareMainLooper方法中，我们来分别来看下：
public static void prepare() {
prepare(true);
}
private static void prepare(boolean quitAllowed) {
// 在创建looper之前，判断looper是否与threadloacal绑定过，这也是prepare只能设置一遍的原因。
if (sThreadLocal.get() != null) {
throw new RuntimeException("Only one Looper may be created per thread");
}
sThreadLocal.set(new Looper(quitAllowed));
}
public static void prepareMainLooper() {
// 这里其实还是调用的prepare方法
prepare(false);
synchronized (Looper.class) {
if (sMainLooper != null) {
throw new IllegalStateException("The main Looper has already been prepared.");
}
sMainLooper = myLooper();
}
}
通过上面可以prepare方法只能设置一遍，那么我们在主线程中为什么能直接使用呢？ app程序的入口是在ActivityThread中的main方法中：
public static void main(String[] args) {
...
//1. 初始化Looper对象
Looper.prepareMainLooper();
// 2. 开启无限循环
Looper.loop();
throw new RuntimeException("Main thread loop unexpectedly exited");
}
看到了吧，初始化在这里，那么我们再来看下looper的初始化方法：
private Looper(boolean quitAllowed) {
mQueue = new MessageQueue(quitAllowed);
mThread = Thread.currentThread();
}
Looper的初始化做了两件事：创建消息队列MessageQueue以及获取当前的线程。 到这里，我们可以得到一个结论：
- prepare方法在一个线程中只能调用一次。
- Looper的初始化在一个线程中只能调用一次。
- 最后可以得知：一个线程对应一个Looper，一个Looper对应一个MessageQueue。
Looper可以理解为一个工厂线，不断从MessageQueue中取Message，工厂线开启的方式就是Looper.loop()
public static void loop() {
final Looper me = myLooper();
// 1. 判断looper是否存在
if (me == null) {
throw new RuntimeException("No Looper; Looper.prepare() wasn't called on this thread.");
}
final MessageQueue queue = me.mQueue;
...
//2. 开启一个死循环
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);
dispatchEnd = needEndTime ? SystemClock.uptimeMillis() : 0;
} finally {
if (traceTag != 0) {
Trace.traceEnd(traceTag);
}
}
...
}
}
looper方法通过开启一个死循环，不断从MessageQueue中取Message消息，当message为空时，退出该循环，否则调用msg.target.dispatchMessage(msg)方法，target就是msg绑定的Handler对象。
Handler的工作原理
好了到这里又回到了Handler类中。
public void dispatchMessage(Message msg) {
if (msg.callback != null) {
handleCallback(msg);
} else {
if (mCallback != null) {
if (mCallback.handleMessage(msg)) {
return;
}
}
handleMessage(msg);
}
}
这个handleMessage就是我们需要实现的方法。 那么Handler是如何设置到Message中的呢？我们来看下我们熟知的sendMessage方法：
public final boolean sendMessage(Message msg)
{
return sendMessageDelayed(msg, 0);
}
public final boolean sendMessageDelayed(Message msg, long delayMillis)
{
if (delayMillis < 0) {
delayMillis = 0;
}
return sendMessageAtTime(msg, SystemClock.uptimeMillis() + delayMillis);
}
public boolean sendMessageAtTime(Message msg, long uptimeMillis) {
MessageQueue queue = mQueue;
...
return enqueueMessage(queue, msg, uptimeMillis);
}
private boolean enqueueMessage(MessageQueue queue, Message msg, long uptimeMillis) {
// 关键代码来了！
msg.target = this;
if (mAsynchronous) {
msg.setAsynchronous(true);
}
return queue.enqueueMessage(msg, uptimeMillis);
}
可以看到，通过一系列的方法，在enqueueMessage中将handler赋值到msg的target中。最后调用的是MessageQueue的enqueueMessage方法中：
boolean enqueueMessage(Message msg, long when) {
if (msg.target == null) {
throw new IllegalArgumentException("Message must have a target.");
}
if (msg.isInUse()) {
throw new IllegalStateException(msg + " This message is already in use.");
}
synchronized (this) {
if (mQuitting) {
IllegalStateException e = new IllegalStateException(
msg.target + " sending message to a Handler on a dead thread");
Log.w(TAG, e.getMessage(), e);
msg.recycle();
return false;
}
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 {
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;
}
enqueueMessage方法主要做了两件事：
首先判断handler是否存在以及是否在使用中。然后根据时间顺序插入MessageQueue中。
到这里基本的流程已经梳理完了，回到起初我们的问题：Looper.loop()是一个死循环，为什么不会堵塞主线程呢？
我们来看下MessageQueue的next方法：
Message next() {
final long ptr = mPtr;
if (ptr == 0) {
return null;
}
int pendingIdleHandlerCount = -1; // -1 only during first iteration
int nextPollTimeoutMillis = 0;
for (;;) {
nativePollOnce(ptr, nextPollTimeoutMillis);
...
}
}
nativePollOnce方法是一个 native 方法，当调用此 native 方法时，主线程会释放 CPU 资源进入休眠状态，直到下条消息到达或者有事务发生，通过往 pipe 管道写端写入数据来唤醒主线程工作，这里采用的 epoll 机制。关于 nativePollOnce 的详细分析可以参考：nativePollOnce函数分析
总结
- app程序启动从ActivityThread中的main方法中开始，通过Looper.prepare()进行Looper以及MessageQueue的创建以及ThreadLocal与线程之间的绑定。
- 我们在创建Handler时，通过ThreadLocal来获取该线程中的Looper以及在Looper上绑定的MessageQueue。
- 通过Handler.sendMessage()方法来将msg与Handler之间进行绑定，然后将msg通过时间顺序插入MessageQueue中。
- 主线程创建后，Looper.loop()来启动一个（不占用资源）死循环，从Looper已经存在的MessageQueue中不断取出Message，然后调用不为空的Message绑定的Handler的dispatchMessage(msg)方法，最后会调用我们复写的handlerMessage方法中。
参考资料
上一篇：Android编程实现将压缩数据库文件拷贝到安装目录的方法
栏 目：Android代码
下一篇：Kotlin之在Gradle中无参（no-arg）编译器插件的使用详解
本文标题：从源码角度分析Android的消息机制
本文地址：http://www.codeinn.net/misctech/164739.html
