Android源码分析：再读消息循环源码

Android消息循环在应用开发中会经常涉及，我以前也分析过。不过那个时候分析的还是以很老的Android源码来进行的，并且只是分析了Java层的代码，当时的文章为：Android消息循环分析。而Native层，以及一些新增的功能，都没有涉及，今天再读源码，对其进行再次分析。 对于应用层的开发者来说，虽然已经过了10年，java层的Api还是跟之前一样的，依然是通过Handler发送消息，Looper会中消息队列中取消息，消息会根据Handler中的callback或者消息自己的callback执，如上图所示。我之前分析的发送消息和处理消息已经比较清楚了，这块不再看了。这里主要分析一下从MessageQueue取消息，之前涉及的文件描述符的监控和Native层的一些实现等进行分析。 java层loop取消息 首先来看java层如何从消息队列取消息的，Looper中有如下代码： 1 2 3 4 5 6 7 8 9 10 11 12 13 public static void loop() { final Looper me = myLooper(); ... me.mInLoop = true; Binder.clearCallingIdentity(); final long ident = Binder.clearCallingIdentity(); ... for (;;) { if (!loopOnce(me, ident, thresholdOverride)) { return; } } } 以上代码核心就是拿到当前线程的Looper然后，在无限循环当中取调用loopOnce。loopOnce代码很长，但是忽略错误处理和Log，核心代码如下： 1 2 3 4 5 6 7 8 9 private static boolean loopOnce(final Looper me, final long ident, final int thresholdOverride) { Message msg = me.mQueue.next(); //从消息队列中取消息 ... msg.target.dispatchMessage(msg); //分发消息 ... msg.recycleUnchecked(); //回收消息，方便下一次发送消息使用 return true; } 在loopOnce中主要就是去通过MessageQueue取消息，之后在分发消息，并且回收消息。再来看MessageQueue的next方法： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 Message next() { final long ptr = mPtr; ... int nextPollTimeoutMillis = 0; for (;;) { nativePollOnce(ptr, nextPollTimeoutMillis); synchronized (this) { 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 { mBlock = false; if (preMsg != null) { prevMsg.next = msg.next; } else { mMessages = msg.next; } msg.next = null; msg.markInUse(); return msg; } } else { nextPollTimeoutMillis = -1; } ... } ... } } 以上为next方法的简化，在Java层的MessageQueue的实现就是一个链表，因此向其中发送消息或者取消息的过程就是链表添加或者删除的过程。在第21行到第26行就是从链表中删除msg的过程。其中这个链表它的头节点是存放在mMessages这个变量，Message在插入链表的时候，也是按照事件先后运行放到链表当中的。 在这个方法的开头，我们看到mPtr，它就是MessageQueue在native层对应的对象，不过Native的Message和Java层的Message是相互独立的，在读取next的时候，也会通过nativePollOnce来native层来读取一个消息，另外在这里还传了一个nextPollTimeoutMillis，用来告诉native需要等待的时间，具体后面在来具体分析相关代码。 因为我们的消息循环中除了放置我们通过Handler所发送的消息之外，还会存在同步信号的屏障，比如ViewRootImpl就会在每一次scheduleTraversals的时候发送一个屏障消息。屏障消息和普通消息的区别就是没有targetHandler。因此在第10行，当我们检查到是屏障消息的时候，会跳过它， 并且查找它之后的第一条异步消息。 另外就是在这个do-while的循环条件中，我们可以看到它还有判断消息是否为Asynchronous的，我们正常创建的Handler一般async都是false，也就是说消息的这个值也是为false。而异步的，一般会被IMS，WMS，Display，动画等系统组件使用，应用开发者无法使用。 这里我们只要知道，如果有异步消息，就会先执行异步消息。在第17行，这里还会判断消息的事件，如果消息的when比当前事件大的化，那么这个消息还不能够执行，这时候需要去等待，这里就会给nextPollTimeoutMillis去赋值。 Native层的MessageQueue和Looper 我们刚刚看MessageQueue的代码时候，看到mPtr，它对应native层的MessageQueue的指针。它的初始化在MessageQueue的构造方法中，也就是调用nativeInit，其内部源码为调用NativeMessageQueue的构造方法，源码在android_os_MessageQueue.cpp中： 1 2 3 4 5 6 7 8 NativeMessageQueue::NativeMessageQueue() : mPollEnv(NULL), mPollObj(NULL), mExceptionObj(NULL) { mLooper = Looper::getForThread(); if (mLooper == NULL) { mLooper = new Looper(false); Looper::setForThread(mLooper); } } 这里我们可以看到在Native层，创建MessageQueue的时候，也会创建Looper，当然如果当前线程存在Looper则会直接使用。Native层的Looper跟Jav层一样，是存放在ThreadLocal当中的，可以看如下代码： 1 2 3 4 5 sp<Looper> Looper::getForThread() { int result = pthread_once(& gTLSOnce, initTLSKey); Looper* looper = (Looper*)pthread_getspecific(gTLSKey); return sp<Looper>::fromExisting(looper); } 到这里，我们知道对于一个启动了消息循环的线程，它在Java层和Native层分别会有各自的MessageQueue和Looper，java层通过mPtr来引用Native层的对象，从而使得两层能够产生联系。 Native层pollOnce 之前分析Java层获取消息的时候，会有一个地方调用nativePollOnce,它在native拿到NativeMessageQueue之后会调用它的pollOnce方法，代码如下： 1 2 3 4 5 6 7 8 9 10 11 12 13 void NativeMessageQueue::pollOnce(JNIEnv* env, jobject pollObj, int timeoutMillis) { mPollEnv = env; mPollObj = pollObj; mLooper->pollOnce(timeoutMillis); mPollObj = NULL; mPollEnv = NULL; if (mExceptionObj) { env->Throw(mExceptionObj); env->DeleteLocalRef(mExceptionObj); mExceptionObj = NULL; } } 这里的pollObj为我们java层的MessageQueue， 这里继续调用了native层的pollOnce，代码如下： 1 2 3 4 5 6 7 int Looper::pollOnce(int timeoutMillis, int* outFd, int* outEvents, void** outData) { //我们的调用流程只会传timeoutMillis ... for (;;) { ... result = pollInner(timeoutMillis); } } 这里省略了一些结果处理的代码，我们可以回头在看，这可以看到开启了一个无限循环，并调用pollInner， 这个方法比较长，我们先分块看其中的代码： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 if (timeoutMillis != 0 && mNextMessageUptime != LLONG_MAX) { nsecs_t now = systemTime(SYSTEM_TIME_MONOTONIC); int messageTimeoutMillis = toMillisecondTimeoutDelay(now, mNextMessageUptime); if (messageTimeoutMillis >= 0 && (timeoutMillis < 0 || messageTimeoutMillis < timeoutMillis)) { timeoutMillis = messageTimeoutMillis; } } int result = POLL_WAKE; mResponses.clear(); //清除reponses列表和计数 mResponseIndex = 0; mPolling = true; struct epoll_event eventItems[EPOLL_MAX_EVENTS]; int eventCount = epoll_wait(mEpollFd.get(), eventItems, EPOLL_MAX_EVENTS, timeoutMillis); mPolling = false; 这里timeoutMillis是我们从java层传过来的下一个消息的执行事件，而mNextMessageUptime是native层的最近一个消息的执行事件，这个根据这两个字段判断需要等待的事件。 在之后调用epoll_wait来等待I/O事件，或者到设置的超时时间结束等待，这样做可以避免Java层和Na