概述

Handler是Android常用的线程间消息工具，下文对Handler，Looper，MessageQueue 涉及的代码做一个分析，以此加深Handler的消息模型的认识。

Looper

Looper主要是prepare()和loop()方法。

prepare()为当前线程创建新的Looper对象，存储在ThreadLocal变量里。

Looper会创建Java对象MessageQueue,MessageQueue又会调用native方法nativeInit创建NativeMessageQueue对象，mPtr存储是NativeMessageQueue的地址，nativeInit代码在frameworks/base/core/jni/android_os_MessageQueue.cpp 

NativeMessageQueue构造函数中回调用Native的Looper::getForThread();获取当前线程的native Looper对象，没有就创建新的，Looper代码在/system/core/libutils/Looper.cpp中。

关键的代码都在Looper的构造函数中:

1.mWakeEventFd=eventfd(0,EFD_NONBLOCK)，创建文件描述符。( Linux下的eventfd)

2.调用rebuildEpollLocked()，使用epoll监听mWakeEventFd的可读事件。(Epoll)

调用loop()方法，线程会进入死循环，循环中调用Looper.mQueue的next()方法，也就是MessageQueue的next()方法，获取最新的msg,在调用msg.target.dispatchMessage(msg)方法来处理msg,msg的target就是发送msg的Handler对象。

MessageQueue.next()方法也是个死循环，先调用native方法 nativePollOnce(ptr, nextPollTimeoutMillis)，再调用NativeMessageQueue的pollOnce方法，方法中调用native Looper对象的pollOnce方法，方法中调用Looper.pollInner方法，其中的关键方法代码是：

epoll_wait的作用如下：

int epoll_wait(int epfd, struct epoll_event * events, int maxevents, int timeout);

epfd为用epoll_create创建之后的句柄，events是一个epoll_event*的指针，当epoll_wait这个函数操作成功之后，epoll_events里面将储存所有的读写事件。max_events是当前需要监听的所有fd。最后一个timeout是 epoll_wait的超时，为0的时候表示马上返回，为-1的时候表示一直等下去，直到有事件范围，为任意正整数的时候表示等这么长的时间，如果一直没有事件，则范围。一般如果网络主循环是单独的线程的话，可以用-1来等，这样可以保证一些效率，如果是和主逻辑在同一个线程的话，则可以用0来保证主循环的效率。

如果epoll_wait返回，就开始处理可读事件：

如果有可读事件的fd是nativeInit中创建的mWakeEventFd,就调用awoken()方法，如果是其他fd，就调用pushResponse()方法，awoken()就只是从mWakeEventFd读8个字节数据。

awoken()之后，执行pushResponse()中获取到的Event,调用response.request.callback->handleEvent(fd,events,data)，执行完所有其他fd的可读事件后，java代码已经执行完nativePollOnce(ptr, nextPollTimeoutMillis)，方法开始往下执行。

java对mMessages开始处理，mMessages本质上是一个链表中的head对象，当前mMessages对象是否是同步屏障,只有同步屏障的消息才能 target==null（Message需要调用setAsynchronous(boolean async)才能设置消息为异步消息，默认的都是同步消息），如果是，就找后面的异步消息，不是，直接使用当前消息，然后再判断msg的应该执行的时间是否在当前时间之前如果不是就继续等待一段时间，如果是，返回消息，如果没有同步屏障，mMessages设为找到的消息，如果有同步屏障，把找到的异步消息从链表中剔除。

到此消息的通知和处理就结束了，下面分析Handler。

Handler

1.创建Handler

Handler需要一个Looper来创建，如果不传递传递Looper会调用Looper.myLooper()，如果当前线程没有Looper就会报错，所以必须在new Handler()之前调用Looper.prepare()。

2.Handler发送消息

Handler发送消息调用 sendMessageAtTime()->enqueueMessage()->MessageQueue.enqueueMessage()

根据msg.when,就是msg应该的发生时间,把msg插入到mMessages的链表对用的位置中，然后调用nativeWake方法。

boolean enqueueMessage(Message msg, long when) 

nativeWake()调用NativeMessageQueue.wake方法，调用Looper->wake()方法，向mWakeEventFd写入8字节数据，此时epoll_wait会收到可读事件，从阻塞中返回，Java层代码会从nativePollOnce(ptr, nextPollTimeoutMillis)返回，开始处理最早该发生的msg。

到此代码分析就结束了。

总结

Handler Java层面的消息模型类似于使用BlockingQueue实现的生产消费模型，msg数据也只在Java层传递，而Handler是使用epoll实现，Handler 在native层面也只使用了epoll的线程阻塞和唤起机制，但是epoll几个api都是系统调用，看上去性能还不如直接使用Java的BlockingQueue。Android的主线程为啥还使用Handler来进行线程间通信呢？这可能跟Android主线程的场景有关，Android 主线程除了处理Java 层消息还需要处理Input和Vsync事件的响应，这些消息都是直接发送到主线程的native的Looper中，并在response.request.callback->handleEvent(fd,events,data)的代码中得到处理。Handler这样的实现就很符合主线程的场景。简单从Java层的线程间消息通知机制来说，Handler并不比BlockingQueue这样的实现性能更高。