概述
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)才能设置消息为异步消息，默认的都是同步消息），如果队首是同步屏障，就找后面的异步消息，如果队首不是同步屏障，直接使用当前消息，然后是否到了消息的执行时间，如果没到，就需要继续等待一段时间，如果到了执行时间，就返回消息。最后要把要找到的消息从队列里剔除。
何时执行IdleHandler
IdleHandler只有在当前找不到可以立即执行的消息时才会执行，而且在找到下一个消息之前只会执行一次。
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这样的实现性能会更高。