欢迎大家前往腾讯云社区，获取更多腾讯海量技术实践干货哦~

作者：汪毅雄

导语： 本文讲述的是Android的消息机制原理，从Java到Native代码进行了梳理，并结合其中使用到的Epoll模型予以介绍。

 

Android的消息传递，是系统的核心功能，对于如何使用相信大家都已经相当熟悉了，这里简单提一句。我们可以粗糙的认为消息机制中关键的几个类的功能如下：

Handler：消息处理者

Looper：消息调度者

MessageQueue：存放消息的地方

使用过程：

Looper.prepare > #$%^^& > Looper.loop（死循环） — loop到一个消息 > Handler处理

好了，我们直接看源码吧。

消息机制是伴随线程的，也就是说上面的几个类在可以在任何一个线程中都有实例的。

先看Looper吧。以主线程为例，Android进程在初始化，会调用prepareMainLooper

  1. public static void prepareMainLooper() {
  2.         prepare(false);
  3.         synchronized (Looper.class) {
  4.             ...
  5.             sMainLooper = myLooper();
  6.         }
  7.     }

 

  1.  private static void prepare(boolean quitAllowed) {
  2.         ...
  3.         sThreadLocal.set(new Looper(quitAllowed));
  4.     }

 

  1.  private Looper(boolean quitAllowed) {
  2.         mQueue = new MessageQueue(quitAllowed);
  3.         mThread = Thread.currentThread();
  4.     }

 

以上几个方法就是Looper初始化，如果是主线程Looper会创建一个不可退出的MessageQueue，并把looper实例放入线程独立（ThreadLocal）变量中。

Looper#loop

  1. public static void loop() {
  2.         final Looper me = myLooper();
  3.         final MessageQueue queue = me.mQueue;
  4.         for (;;) {
  5.             Message msg = queue.next(); 
  6.             if (msg == null) {
  7.                 return;
  8.             }
  9.             ...
  10.             try {
  11.                 msg.target.dispatchMessage(msg);
  12.             } 
  13.             ...
  14.             msg.recycleUnchecked();
  15.         }
  16.     }

 

Looper prepare后就可以loop了，loop非常简单，一直去queue中拿消息就好了，拿到了交给target也就是Handler处理。大家有可能会奇怪这种死循环，执行起来不会太sb粗暴了吗？其实这个解决方式在queue.next！！！后面再讲。

Handler#dispatchMessage

  1. public void dispatchMessage(Message msg) {
  2.         if (msg.callback != null) {
  3.             handleCallback(msg);
  4.         } else {
  5.             if (mCallback != null) {
  6.                 if (mCallback.handleMessage(msg)) {
  7.                     return;
  8.                 }
  9.             }
  10.             handleMessage(msg);
  11.         }
  12.     }

 

handler收到后，如果发现message的callback不为空，则只处理callback。（提一句，我们用的很多的handler.post(Runnable)，其实这个Runnable就是这里的callback，也就是说post的Runnable实质上是一个优先级很高的Message），如果没有则尝试交给handler本身的callback处理（handler初始化的时候可以用callback方式构造），再没有才到我们常用的handleMessage方法，这里就是我们经常重写的方法。

再说说消息的发送，一般handler会调用sendMessage方法，但是最终这个方法还是会跑到这里

  1. private boolean enqueueMessage(MessageQueue queue, Message msg, long uptimeMillis) {
  2.         msg.target = this;
  3.         if (mAsynchronous) {
  4.             msg.setAsynchronous(true);
  5.         }
  6.         return queue.enqueueMessage(msg, uptimeMillis);
  7.     }

 

再交给MessageQueue

  1. boolean enqueueMessage(Message msg, long when) {
  2.         。。。
  3.         synchronized (this) {
  4.             。。。
  5.                 Message prev;
  6.                 for (;;) {
  7.                     prev = p;
  8.                     p = p.next;
  9.                     if (p == null || when < p.when) {
  10.                         break;
  11.                     }
  12.                     。。。
  13.                 }
  14.                 msg.next = p; // invariant: p == prev.next
  15.                 prev.next = msg;
  16.             if (needWake){
  17.                nativeWake(mPtr);
  18.             }
  19.         }
  20.         return true;
  21.     }

 

MessageQueue会把消息插入队列，并依次改变队列中各个消息的指针。

咦，好像只用Java层貌似就能把整个消息机制说通了，native代码在哪儿？有何用呢？

但是，刚才提到了Looper初始化的时候也会新建一个MessageQueue

  1. MessageQueue(boolean quitAllowed) {
  2.         mQuitAllowed = quitAllowed;
  3.         mPtr = nativeInit();
  4.     }

 

好了，我们第一个native方法出来了。这时候我们可以猜得到，MessageQueue才是整个消息机制的核心！

接上面Java层的代码，MessageQueue构造的时候会调一个nativeInit。

  1. static jlong android_os_MessageQueue_nativeInit(JNIEnv* env, jclass clazz) {
  2.     NativeMessageQueue* nativeMessageQueue = new NativeMessageQueue();
  3.     。。。
  4. }

 

  1. NativeMessageQueue::NativeMessageQueue() :
  2.         mPollEnv(NULL), mPollObj(NULL), mExceptionObj(NULL) {
  3.     mLooper = Looper::getForThread();
  4.     if (mLooper == NULL) {
  5.         mLooper = new Looper(false);
  6.         Looper::setForThread(mLooper);
  7.     }
  8. }

 

native层调用init方法后，会在native层构建一个native Looper！来看看native Looper的初始化

  1. Looper::Looper(bool allowNonCallbacks) :
  2.         mAllowNonCallbacks(allowNonCallbacks), mSendingMessage(false),
  3.         mPolling(false), mEpollFd(-1), mEpollRebuildRequired(false),
  4.         mNextRequestSeq(0), mResponseIndex(0), mNextMessageUptime(LLONG_MAX) {
  5.     mWakeEventFd = eventfd(0, EFD_NONBLOCK | EFD_CLOEXEC);
  6.     ...
  7.     rebuildEpollLocked();
  8. }

 

这里创建了一个eventfd，代码来自最新的8.0，这部分和5.0 pipe管道的mWakeReadPipeFd和mWakeWritePipeFd稍微有点不一样，前者是等待/响应，后者是读取/写入。只是android选取方式的不同而已，这块就不细说。

  1. void Looper::rebuildEpollLocked() {
  2.     。。。
  3.     mEpollFd = epoll_create(EPOLL_SIZE_HINT);
  4.     LOG_ALWAYS_FATAL_IF(mEpollFd < 0, "Could not create epoll instance: %s", strerror(errno));
  5.     struct epoll_event eventItem;
  6.     memset(& eventItem, 0, sizeof(epoll_event)); 
  7.     eventItem.events = EPOLLIN;
  8.     eventItem.data.fd = mWakeEventFd;
  9.     int result = epoll_ctl(mEpollFd, EPOLL_CTL_ADD, mWakeEventFd, & eventItem);
  10.     。。。
  11. }

 

再到rebuildEpollLocked这个方法中，可以看到通过epoll_create创建了一个epoll专用的文件描述符，EPOLL_SIZE_HINT表示mEpollFd上能监控的最大文件描述符数。最后调用epoll_ctl监控mWakeEventFd文件描述符的Epoll事件，即当mWakeEventFd中有内容可读时，就唤醒当前正在等待的线程.。

这里不了解的人可能听着晕，上面这么一大段一句话概括就是：Android native层用了Epoll模型。什么是Epoll模型呢？我先简单介绍一下。

为什么要引入呢？

在Looper.loop的时候提到了，android不会简单粗暴地真的执行啥都没干的死循环。刚才说了，问题出在queue.next。Epoll干的事就是： 如果你的queue中没有消息可执行了，好了你可以歇着了，等有消息的我再告诉你。这个queue.next就是“阻塞”（休眠）在这里。

Epoll简单介绍

1、传统的阻塞型I/O（一边写，一边读），一个线程只能处理一个一个IO流。

2、如果一个线程想要处理多个流，可以采用了非阻塞、轮询I/O方式，但是传统的非阻塞处理多个流的时候，会遍历所有流，但是如果所有流都没数据，就会白白浪费CPU。
。。。
于是出现了select和epoll两种常见的代理方式。

3、select就是那种无差别轮询的代理方式。epoll可以理解为Event poll，也就是说代理者会代理流的时候也伴随着事件，因此有了对应事件，就可以避免无差别轮询了。

4、其通常的操作有：epoll_create（创建一个epoll）、epoll_ctl（往epoll中增加/删除某一个流的某一个事件）、epoll_wait（在一定时间内等待事件的发生）

  1. eventItem.events = EPOLLIN;
  2. eventItem.data.fd = mWakeEventFd;
  3. int result = epoll_ctl(mEpollFd, EPOLL_CTL_ADD, mWakeEventFd, & eventItem);

 

好了，我们结合Looper初始化的代码来读一下epoll在这里干了什么吧。

我直接翻译了：往mEpollFd代理中、注册、一个叫mWakeEventFd流、的数据流入事件（EPOLLIN）

这样大家应该懂了吧。。。

接上MessageQueue在初始化后，在native创建了一个Looper。
我们继续消息的发送和提取在native层的表现。其实native层主要负责的是消息的调度，比如说何时阻塞、何时唤醒线程，避免CPU浪费。

native发送

发送在native比较简单，handler发送消息后，会到MessageQueue的enqueueMessage，此时在线程阻塞的情况下，会调用nativeWake来唤起线程。

  1. void NativeMessageQueue::wake() {
  2.     mLooper->wake();
  3. }

 

  1.  void Looper::wake() {
  2.     。。。
  3.     uint64_t inc = 1;
  4.     ssize_t nWrite = TEMP_FAILURE_RETRY(write(mWakeEventFd, &inc, sizeof(uint64_t)));
  5.     if (nWrite != sizeof(uint64_t)) {
  6.       。。。。
  7.     }
  8. }

 

这里TEMP_FAILURE_RETRY是一个宏定义，顾名思义，就是不断地尝试往mWakeEventFd流里面写一个无用数据直到成功，以此来唤醒queue.next。这部分就不多说了。

native消息提取

也就是queue.next

  1. Message next() {
  2.         。。。
  3.         for (;;) {
  4.            。。。
  5.             nativePollOnce(ptr, nextPollTimeoutMillis);
  6.            。。。
  7.         }
  8.     }

 

可以看到，又是一个死循环（阻塞）。继续往下看

  1. void NativeMessageQueue::pollOnce(JNIEnv* env, jobject pollObj, int timeoutMillis) {
  2.     。。。
  3.     mLooper->pollOnce(timeoutMillis);
  4.     。。。
  5. }

 

mLooper->pollOnce

mLooper->pollInner

  1. int Looper::pollInner(int timeoutMillis) {
  2.     。。。
  3.     int result = POLL_WAKE;
  4.     mPolling = true;
  5.     struct epoll_event eventItems[EPOLL_MAX_EVENTS];
  6.     int eventCount = epoll_wait(mEpollFd, eventItems, EPOLL_MAX_EVENTS, timeoutMillis);
  8.     mPolling = false;
  9.     mLock.lock();
  11.     for (int i = 0; i < eventCount; i++) {
  12.         int fd = eventItems[i].data.fd;
  13.         uint32_t epollEvents = eventItems[i].events;
  14.         if (fd == mWakeEventFd) {
  15.             if (epollEvents & EPOLLIN) {
  16.                 awoken();
  17.             } else {
  18.                 ALOGW("Ignoring unexpected epoll events 0x%x on wake event fd.", epollEvents);
  19.             }
  20.         } 
  21.         。。。
  22.     }
  23.     。。。
  24.     mLock.unlock();
  25.     。。。
  26.     return result;
  27. }

 

在这里，我们注意到epoll_wait方法，这里会得到一段时间内（结合消息计算得来的）收到的事件个数，这里对于queue来说就是空闲（阻塞）状态。过了这个时间后，看看事件数，如果为0，则意味着超时。否则，遍历所有的事件，看看有没有mWakeEventFd，且是EPOLLIN事件的，有的话就真正唤醒线程、解除空闲状态。

消息机制在native层的主要表现就是这些。

最后，画了一个粗糙、且不太准确图仅供参考学习

 

Android View和 Window 的关系

Android 7.0 中 ContentProvider 实现原理

此文已由作者授权腾讯云技术社区发布，转载请注明原文出处

版权声明：本文为qcloud1001原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：http://www.cnblogs.com/qcloud1001/p/7993756.html