Handler+Looper+MessageQueue这三者的关系其实就是Android的消息机制。这块内容相比开发人员都不陌生，在面试中，或者日常开发中都会碰到，今天就来讲这三者的关系。
Handler 、 Looper 、Message 这三者都与Android异步消息处理线程相关的概念。那么什么叫异步消息处理线程呢？
异步消息处理线程启动后会进入一个无限的循环体之中，每循环一次，从其内部的消息队列中取出一个消息，然后回调相应的消息处理函数，执行完成一个消息后则继续循环。若消息队列为空，线程则会阻塞等待。
那么Android消息机制主要是指Handler的运行机制，Handler运行需要底层的MessageQueue和Looper支撑。其中MessageQueue采用的是单链表的结构，Looper可以叫做消息循环。由于MessageQueue只是一个消息存储单元，不能去处理消息，而Looper就是专门来处理消息的，Looper会以无限循环的形式去查找是否有新消息，如果有的话，就处理，否则就一直等待着。
我们知道，Handler创建的时候会采用当前线程的Looper来构造消息循环系统，需要注意的是，线程默认是没有Looper的，如果需要使用Handler就必须为线程创建Looper，因为默认的UI主线程，也就是ActivityThread，ActivityThread被创建的时候就会初始化Looper，这也是在主线程中默认可以使用Handler的原因。
先给出这三者之间的关系图
前面提到的Handler+Looper+MessageQueue，这三者实际上是一个整体，我们在开发过程中接触的最多是Handler。Handler的主要作用是将一个任务切换到某个指定的线程中去执行，那么Androd为什么要提供这个功能呢？
这是因为Android规定UI只能在主线程中进行，如果在子线程中访问UI，那么程序就会崩溃，抛出异常，这就是导致我们不能在主线程中进行耗时操作，否则会导致程序无法响应，即ANR，那要是我们想要从服务端获取数据在UI上显示怎么办呢，耗时的话我们一般在子线程中进行获取，如何把获取的数据呈现在主线程中呢，这其中就用到了Handler，Handler主要原因就是为了解决在子线程中无法访问UI的矛盾。
可以在延伸下，系统为什么不允许在子线程中访问UI呢，这是因为Android的UI控件不是线程安全的，如果是多线程中并发访问可能会导致UI控件处于不可控的状态。
Looper扮演的角色就是消息循环，不断从MessageQueue中查看是否有新消息，如果有新消息到来就会立刻处理，否则就一直祖塞在那里，在它的构造方法，默认会创建一个MessageQueue的消息队列，然后将当前线程的对象保存起来。
private Looper(boolean quitAllowed) {
mQueue = new MessageQueue(quitAllowed);
mThread = Thread.currentThread();
对于Looper主要是prepare()和loop()两个方法，首先看prepare()方法。
public static final void prepare() {
if (sThreadLocal.get() != null) {
throw new RuntimeException("Only one Looper may be created per thread");
sThreadLocal.set(new Looper(true));
sThreadLocal是一个ThreadLocal对象，可以在一个线程中存储变量。可以看到，在第5行，将一个Looper的实例放入了ThreadLocal，并且2-4行判断了sThreadLocal是否为null，否则抛出异常。这也就说明了Looper.prepare()方法不能被调用两次，同时也保证了一个线程中只有一个Looper实例
然后我们看loop()方法：
public static void loop() {
final Looper me = myLooper();
if (me == null) {
throw new RuntimeException("No L Looper.prepare() wasn't called on this thread.");
final MessageQueue queue = me.mQ
// Make sure the identity of this thread is that of the local process,
// and keep track of what that identity token actually is.
Binder.clearCallingIdentity();
final long ident = Binder.clearCallingIdentity();
for (;;) {
Message msg = queue.next(); // might block
if (msg == null) {
// No message indicates that the message queue is quitting.
// This must be in a local variable, in case a UI event sets the logger
Printer logging = me.mL
if (logging != null) {
logging.println("&&&&& Dispatching to " + msg.target + " " +
msg.callback + ": " + msg.what);
msg.target.dispatchMessage(msg);
if (logging != null) {
logging.println("&&&&& Finished to " + msg.target + " " + msg.callback);
// Make sure that during the course of dispatching the
// identity of the thread wasn't corrupted.
final long newIdent = Binder.clearCallingIdentity();
if (ident != newIdent) {
Log.wtf(TAG, "Thread identity changed from 0x"
+ Long.toHexString(ident) + " to 0x"
+ Long.toHexString(newIdent) + " while dispatching to "
+ msg.target.getClass().getName() + " "
+ msg.callback + " what=" + msg.what);
msg.recycle();
方法直接返回了sThreadLocal存储的Looper实例，如果me为null则抛出异常，也就是说looper方法必须在prepare方法之后运行。拿到该looper实例中的mQueue（消息队列）就进入了我们所说的无限循环。取出一条消息，如果没有消息则阻塞。使用调用 msg.target.dispatchMessage(msg);把消息交给msg的target的dispatchMessage方法去处理。Msg的target是什么呢？其实就是handler对象，下面会进行分析。释放消息占据的资源。
Looper主要作用：
1、 与当前线程绑定，保证一个线程只会有一个Looper实例，同时一个Looper实例也只有一个MessageQueue。
2、 loop()方法，不断从MessageQueue中去取消息，交给消息的target属性的dispatchMessage去处理。
好了，我们的异步消息处理线程已经有了消息队列（MessageQueue），也有了在无限循环体中取出消息的哥们，现在缺的就是发送消息的对象了，于是乎：Handler登场了。
Handler的工作主要是包含消息的发送和接受的过程。使用Handler之前，我们都是初始化一个实例，比如用于更新UI线程，我们会在声明的时候直接初始化，或者在onCreate中初始化Handler实例。
public Handler() {
this(null, false);
public Handler(Callback callback, boolean async) {
if (FIND_POTENTIAL_LEAKS) {
final Class&? extends Handler& klass = getClass();
if ((klass.isAnonymousClass() || klass.isMemberClass() || klass.isLocalClass()) &&
(klass.getModifiers() & Modifier.STATIC) == 0) {
Log.w(TAG, "The following Handler class should be static or leaks might occur: " +
klass.getCanonicalName());
mLooper = Looper.myLooper();
if (mLooper == null) {
throw new RuntimeException(
"Can't create handler inside thread that has not called Looper.prepare()");
mQueue = mLooper.mQ
mCallback =
mAsynchronous =
通过Looper.myLooper()获取了当前线程保存的Looper实例，然后在19行又获取了这个Looper实例中保存的MessageQueue（消息队列），这样就保证了handler的实例与我们Looper实例中MessageQueue关联上了。
然后看我们最常用的sendMessage方法
public final boolean sendMessage(Message msg)
return sendMessageDelayed(msg, 0);
public final boolean sendEmptyMessageDelayed(int what, long delayMillis) {
Message msg = Message.obtain();
msg.what =
return sendMessageDelayed(msg, delayMillis);
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 = mQ
if (queue == null) {
RuntimeException e = new RuntimeException(
this + " sendMessageAtTime() called with no mQueue");
Log.w("Looper", e.getMessage(), e);
return false;
return enqueueMessage(queue, msg, uptimeMillis);
最后调用了sendMessageAtTime，在此方法内部有直接获取MessageQueue然后调用了enqueueMessage方法，我们再来看看此方法：
private boolean enqueueMessage(MessageQueue queue, Message msg, long uptimeMillis) {
msg.target = this;
if (mAsynchronous) {
msg.setAsynchronous(true);
return queue.enqueueMessage(msg, uptimeMillis);
enqueueMessage中首先为meg.target赋值为this，如果大家还记得Looper的loop方法会取出每个msg然后交给msg,target.dispatchMessage(msg)去处理消息，也就是把当前的handler作为msg的target属性。最终会调用queue的enqueueMessage的方法，也就是说handler发出的消息，最终会保存到消息队列中去。
现在已经很清楚了Looper会调用prepare()和loop()方法，在当前执行的线程中保存一个Looper实例，这个实例会保存一个MessageQueue对象，然后当前线程进入一个无限循环中去，不断从MessageQueue中读取Handler发来的消息。然后再回调创建这个消息的handler中的dispathMessage方法，下面我们赶快去看一看这个方法：
public void dispatchMessage(Message msg) {
if (msg.callback != null) {
handleCallback(msg);
if (mCallback != null) {
if (mCallback.handleMessage(msg)) {
handleMessage(msg);
* Subclasses must implement this to receive messages.
public void handleMessage(Message msg) {
可以看到这是一个空方法，为什么呢，因为消息的最终回调是由我们控制的，我们在创建handler的时候都是复写handleMessage方法，然后根据msg.what进行消息处理。
1、首先Looper.prepare()在本线程中保存一个Looper实例，然后该实例中保存一个MessageQueue对象；因为Looper.prepare()在一个线程中只能调用一次，所以MessageQueue在一个线程中只会存在一个。
2、Looper.loop()会让当前线程进入一个无限循环，不端从MessageQueue的实例中读取消息，然后回调msg.target.dispatchMessage(msg)方法。
3、Handler的构造方法，会首先得到当前线程中保存的Looper实例，进而与Looper实例中的MessageQueue想关联。
4、Handler的sendMessage方法，会给msg的target赋值为handler自身，然后加入MessageQueue中。
5、在构造Handler实例时，我们会重写handleMessage方法，也就是msg.target.dispatchMessage(msg)最终调用的方法。
Handler Post
public final boolean post(Runnable r)
sendMessageDelayed(getPostMessage(r), 0);
private static Message getPostMessage(Runnable r) {
Message m = Message.obtain();
m.callback =
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 = mQ
if (queue == null) {
RuntimeException e = new RuntimeException(
this + " sendMessageAtTime() called with no mQueue");
Log.w("Looper", e.getMessage(), e);
return false;
return enqueueMessage(queue, msg, uptimeMillis);
可以看到，在getPostMessage中，得到了一个Message对象，然后将我们创建的Runable对象作为callback属性，赋值给了此message.
注：产生一个Message对象，可以new &，也可以使用Message.obtain()方法；两者都可以，但是更建议使用obtain方法，因为Message内部维护了一个Message池用于Message的复用，避免使用new 重新分配内存。最终和handler.sendMessage一样，调用了sendMessageAtTime，然后调用了enqueueMessage方法，给msg.target赋值为handler，最终加入MessagQueue.
可以看到，这里msg的callback和target都有值，那么会执行哪个呢？
dispatchMessage方法
public void dispatchMessage(Message msg) {
if (msg.callback != null) {
handleCallback(msg);
if (mCallback != null) {
if (mCallback.handleMessage(msg)) {
handleMessage(msg);
Handler使用流程图：
源于对掌握的Android开发基础点进行整理，罗列下已经总结的文章，从中可以看到技术积累的过程。
阅读(...) 评论()[转载]在openfire中添加消息队列，防止聊天信息丢失方法
经过测试和研究openfire源码，发现当在断网情况下，大概一分钟左右服务器才断定客户端断开连接。而在这一分钟内发送的消息是没有存入离线消息表里的。致使消息丢失。当然这个时间是可以设置的，但是设置时长没有实际价值。因为不能让服务器实时判断客户端是否连接。于是添加了消息队列机制，处理消息丢失的问题。
一下是具体实现：
一、在NIOConnection.java中的deliver方法中，添加消息队列。
所有的在线message都会经过这个 方法。
& //聊天消息放入消息队列
& if(packet instanceof Message) {
& Message message = (Message)
& Type type = message.getType();
if("chat".equals(type.name())||"groupchat".equals(type.name())){
& & & Element
request = message.getElement().element("request");
if(request!=null){
& & & Message
createCopy = message.createCopy();
messageQueue.offer(createCopy);
//从队列中获取值发送
if(messageQueue.size()==1){
deliverMessage(createCopy);
deliverMessage是一个发送message的方法，是根据发送的代码重构的，具体如下：
public void deliverMessage(Message queueMessage) throws
UnauthorizedException{
& & if (isClosed()) {
backupDeliverer.deliver(queueMessage);
& & ByteBuffer buffer =
ByteBuffer.allocate(4096);
&buffer.setAutoExpand(true);
& & boolean errorDelivering
& // OF-464: if the connection has been dropped,
fail over to backupDeliverer (offline)
& if (!ioSession.isConnected()) {
& throw new IOException("Connection reset/closed
by peer");
& & &XMLWriter
xmlSerializer =
&new XMLWriter(new ByteBufferWriter(buffer,
encoder.get()), new OutputFormat());
&xmlSerializer.write(queueMessage.getElement());
&xmlSerializer.flush();
(flashClient) {
& &buffer.put((byte) '');
&buffer.flip();
&ioSession.write(buffer);
&catch (Exception e) {
&Log.debug("Error delivering packet:n" +
queueMessage, e);
&errorDelivering =
&if (errorDelivering) {
& & &// Retry
sending the packet again. Most probably if the packet is a
& & &// Message
it will be stored offline
&backupDeliverer.deliver(queueMessage);
&session.incrementServerPacketCount();
二、在一分钟左右服务器确定客户端断开连接时，会触发close()方法，在close方法中将消息队列中的消息放入离线消息表。
&if (closedSuccessfully) {
& //从消息队列中获取消息，插入到离线数据库
& OfflineMessageStore instance =
OfflineMessageStore.getInstance();
& Iterator iterator =
messageQueue.iterator();
& while(iterator.hasNext()){
& instance.addMessage(iterator.next());
& messageQueue.clear();
notifyCloseListeners();
三、在接收消息回执时，会操作消息队列。这里实在ClientStanzeHandler.java中，processMessage()方法中获取connection，这里需要说明一下，之所以在这里操作，是因为消息队列是存储在接收方的connection中，而消息回执接收的connection是自己的connection。从这里发送回执message的时候要获取的connection为接收方的connection，进而才能操作对方的消息队列。
代码如下：
//判断是不是消息回执，如果是就获取消息队列进行操作
& Element received =
packet.getElement().element("received");
& if(received!=null){
&if(connection!=null && connection
instanceof NIOConnection){
& NIOConnection conn =
(NIOConnection)
& Queue messageQueue =
conn.getMessageQueue();
& String attributeValue =
received.attributeValue("id");
& & Message peek =
messageQueue.peek();
& & //如果相等就从队列清除
if(attributeValue.equals(peek.getID())){
messageQueue.poll();
//判断队列中是否还有message,如果有的话继续发送
if(messageQueue.size()!=0){
& & peek =
messageQueue.peek();
conn.deliverMessage((peek));
& & }else{
& & //继续从队列中发送message
if(messageQueue.size()!=0){
& & peek =
messageQueue.peek();
conn.deliverMessage(peek);
至此，消息队列机制完成。经测试消息再也没有丢失。
内部还有一些细节，通过代码可以理解不在赘述。
以上网友发言只代表其个人观点，不代表新浪网的观点或立场。如何：创建 MessageQueue 组件实例
如何：创建 MessageQueue 组件实例
本文档已存档，并且将不进行维护。
如何：创建 MessageQueue 组件实例
.NET Framework 2.0
当需要使应用程序内置消息处理功能时，可以创建
组件。使用 MessageQueue 组件，可以连接到现有队列，发送和接收消息，以及使用非常少的代码为应用程序添加通信服务。例如，假设要生成一个订单输入系统，该系统在收到来自销售人员或网站上客户直接交互的订单后，将其放入队列中。开始时可以向项目中添加 MessageQueue 组件的一个实例，然后将其配置为与消息队列服务器上现有的 OrderEntry 队列进行交互。
可以向 Windows 窗体、Web 窗体和组件类添加 MessageQueue 组件的实例。MessageQueue 组件没有可视的用户界面。如果向可视化设计器（如 Windows 窗体设计器）中添加 MessageQueue 组件的实例，该组件将出现在窗体下边框下面一个很小的区域中。此区域称为组件栏，用作显示与窗体关联的所有非可视项的位置。
继承的非可视化类支持类似于组件栏的可视化设计图面，MessageQueue 组件和其他组件排列在该图面上。此设计器上项的排列并不重要，因为您所看到的该界面从不向应用程序的最终用户显示。
有关如何配置 MessageQueue 组件的说明，请参见。 有多种创建 MessageQueue 组件的实例的方法：
可以从“工具箱”的“组件”选项卡上将 MessageQueue 组件的一个实例拖到窗体或组件设计器上。
可以在“服务器资源管理器”中定位所需的队列，然后将其添加到设计器中，从而创建一个预先配置为指向该队列的 MessageQueue 组件的实例。
可以通过代码创建 MessageQueue 组件的实例。
访问“工具箱”的“组件”选项卡。
选择 MessageQueue 图标并将它拖放到窗体或组件的设计器图面上。
配置组件。有关更多信息，请参见。
打开“服务器资源管理器”。有关更多信息，请参见。
展开“服务器”节点，确定此节点是否列出了要在其上驻留队列的服务器。
提示 如果没有列出要查看的服务器，则需要添加该服务器。有关更多信息，请参见。
展开要查看的服务器的节点，然后在它下面找到并展开“消息队列”节点。
注意 如果未展开“消息队列”节点，则说明试图在其上查看队列的计算机未安装“消息队列”。有关如何安装和配置“消息队列”的信息，请参见 Windows 2000 或 Windows NT 消息队列文档。
定位要添加到项目中的队列，然后右击它。
单击“添加到设计器”。
配置组件。有关更多信息，请参见。
通过代码创建 MessageQueue 类的实例，然后设置
以确定希望组件引用的现有队列。您的代码可能类似于：
System.Messaging.MessageQueue myMQ =
new System.Messaging.MessageQueue();
myMQ.Path = @".\MyNewQueue";
提示 还可以通过使用以下格式，将步骤 1 和步骤 2 并为一个步骤：
System.Messaging.MessageQueue myMQ2 =
new System.Messaging.MessageQueue(@".\MyNewQueue");
注意 可以通过队列的路径、自动生成的队列格式名或队列的非唯一描述性标签来引用队列。每种引用队列的方法各有优缺点。有关更多信息，请参见。
为队列配置其他任何必需的属性。有关更多信息，请参见。Android是消息驱动的，实现消息驱动有几个要素：
消息的表示：Message消息队列：MessageQueue消息循环，用于循环取出消息进行处理：Looper消息处理，消息循环从消息队列中取出消息后要对消息进行处理：Handler
平时我们最常使用的就是Message与Handler了，如果使用过HandlerThread或者自己实现类似HandlerThread的东西可能还会接触到Looper，而MessageQueue是Looper内部使用的，对于标准的SDK，我们是无法实例化并使用的（构造函数是包可见性）。
我们平时接触到的Looper、Message、Handler都是用JAVA实现的，Android做为基于Linux的系统，底层用C、C++实现的，而且还有NDK的存在，消息驱动的模型怎么可能只存在于JAVA层，实际上，在Native层存在与Java层对应的类如Looper、MessageQueue等。
&初始化消息队列
首先来看一下如果一个线程想实现消息循环应该怎么做，以HandlerThread为例：
public void run() {
mTid = Process.myTid();
Looper.prepare();
synchronized (this) {
mLooper = Looper.myLooper();
notifyAll();
Process.setThreadPriority(mPriority);
onLooperPrepared();
Looper.loop();
mTid = -1;
主要是红色标明的两句，首先调用prepare初始化MessageQueue与Looper，然后调用loop进入消息循环。先看一下Looper.prepare。
public static void prepare() {
prepare(true);
private static void prepare(boolean quitAllowed) {
if (sThreadLocal.get() != null) {
throw new RuntimeException(&Only one Looper may be created per thread&);
sThreadLocal.set(new Looper(quitAllowed));
重载函数，quitAllowed默认为true，从名字可以看出来就是消息循环是否可以退出，默认是可退出的，Main线程（UI线程）初始化消息循环时会调用prepareMainLooper，传进去的是false。使用了ThreadLocal，每个线程可以初始化一个Looper。
再来看一下Looper在初始化时都做了什么：
private Looper(boolean quitAllowed) {
mQueue = new MessageQueue(quitAllowed);
mRun = true;
mThread = Thread.currentThread();
MessageQueue(boolean quitAllowed) {
mQuitAllowed = quitA
nativeInit();
在Looper初始化时，新建了一个MessageQueue的对象保存了在成员mQueue中。MessageQueue的构造函数是包可见性，所以我们是无法直接使用的，在MessageQueue初始化的时候调用了nativeInit，这是一个Native方法：
static void android_os_MessageQueue_nativeInit(JNIEnv* env, jobject obj) {
NativeMessageQueue* nativeMessageQueue = new NativeMessageQueue();
if (!nativeMessageQueue) {
jniThrowRuntimeException(env, &Unable to allocate native queue&);
nativeMessageQueue-&incStrong(env);
android_os_MessageQueue_setNativeMessageQueue(env, obj, nativeMessageQueue);
static void android_os_MessageQueue_setNativeMessageQueue(JNIEnv* env, jobject messageQueueObj,
NativeMessageQueue* nativeMessageQueue) {
env-&SetIntField(messageQueueObj, gMessageQueueClassInfo.mPtr,
reinterpret_cast&jint&(nativeMessageQueue));
在nativeInit中，new了一个Native层的MessageQueue的对象，并将其地址保存在了Java层MessageQueue的成员mPtr中，Android中有好多这样的实现，一个类在Java层与Native层都有实现，通过JNI的GetFieldID与SetIntField把Native层的类的实例地址保存到Java层类的实例的mPtr成员中，比如Parcel。
再看NativeMessageQueue的实现：
NativeMessageQueue::NativeMessageQueue() : mInCallback(false), mExceptionObj(NULL) {
mLooper = Looper::getForThread();
if (mLooper == NULL) {
mLooper = new Looper(false);
Looper::setForThread(mLooper);
在NativeMessageQueue的构造函数中获得了一个Native层的Looper对象，Native层的Looper也使用了线程本地存储，注意new Looper时传入了参数false。
Looper::Looper(bool allowNonCallbacks) :
mAllowNonCallbacks(allowNonCallbacks), mSendingMessage(false),
mResponseIndex(0), mNextMessageUptime(LLONG_MAX) {
int wakeFds[2];
int result = pipe(wakeFds);
LOG_ALWAYS_FATAL_IF(result != 0, &Could not create wake pipe.
errno=%d&, errno);
mWakeReadPipeFd = wakeFds[0];
mWakeWritePipeFd = wakeFds[1];
result = fcntl(mWakeReadPipeFd, F_SETFL, O_NONBLOCK);
LOG_ALWAYS_FATAL_IF(result != 0, &Could not make wake read pipe non-blocking.
errno=%d&,
result = fcntl(mWakeWritePipeFd, F_SETFL, O_NONBLOCK);
LOG_ALWAYS_FATAL_IF(result != 0, &Could not make wake write pipe non-blocking.
errno=%d&,
// Allocate the epoll instance and register the wake pipe.
mEpollFd = epoll_create(EPOLL_SIZE_HINT);
LOG_ALWAYS_FATAL_IF(mEpollFd & 0, &Could not create epoll instance.
errno=%d&, errno);
struct epoll_event eventI
memset(& eventItem, 0, sizeof(epoll_event)); // zero out unused members of data field union
eventItem.events = EPOLLIN;
eventItem.data.fd = mWakeReadPipeFd;
result = epoll_ctl(mEpollFd, EPOLL_CTL_ADD, mWakeReadPipeFd, & eventItem);
LOG_ALWAYS_FATAL_IF(result != 0, &Could not add wake read pipe to epoll instance.
errno=%d&,
Native层的Looper使用了epoll。初始化了一个管道，用mWakeWritePipeFd与mWakeReadPipeFd分别保存了管道的写端与读端，并监听了读端的EPOLLIN事件。注意下初始化列表的值，mAllowNonCallbacks的值为false。
mAllowNonCallback是做什么的？使用epoll仅为了监听mWakeReadPipeFd的事件？其实Native Looper不仅可以监听这一个描述符，Looper还提供了addFd方法：
int addFd(int fd, int ident, int events, ALooper_callbackFunc callback, void* data);
int addFd(int fd, int ident, int events, const sp&LooperCallback&& callback, void* data);
fd表示要监听的描述符。ident表示要监听的事件的标识，值必须&=0或者为ALOOPER_POLL_CALLBACK(-2)，event表示要监听的事件，callback是事件发生时的回调函数，mAllowNonCallbacks的作用就在于此，当mAllowNonCallbacks为true时允许callback为NULL，在pollOnce中ident作为结果返回，否则不允许callback为空，当callback不为NULL时，ident的值会被忽略。还是直接看代码方便理解：
int Looper::addFd(int fd, int ident, int events, const sp&LooperCallback&& callback, void* data) {
#if DEBUG_CALLBACKS
ALOGD(&%p ~ addFd - fd=%d, ident=%d, events=0x%x, callback=%p, data=%p&, this, fd, ident,
events, callback.get(), data);
if (!callback.get()) {
if (! mAllowNonCallbacks) {
ALOGE(&Invalid attempt to set NULL callback but not allowed for this looper.&);
return -1;
if (ident & 0) {
ALOGE(&Invalid attempt to set NULL callback with ident & 0.&);
return -1;
ident = ALOOPER_POLL_CALLBACK;
int epollEvents = 0;
if (events & ALOOPER_EVENT_INPUT) epollEvents |= EPOLLIN;
if (events & ALOOPER_EVENT_OUTPUT) epollEvents |= EPOLLOUT;
{ // acquire lock
AutoMutex _l(mLock);
request.fd =
request.ident =
request.callback =
request.data =
struct epoll_event eventI
memset(& eventItem, 0, sizeof(epoll_event)); // zero out unused members of data field union
eventItem.events = epollE
eventItem.data.fd =
ssize_t requestIndex = mRequests.indexOfKey(fd);
if (requestIndex & 0) {
int epollResult = epoll_ctl(mEpollFd, EPOLL_CTL_ADD, fd, & eventItem);
if (epollResult & 0) {
ALOGE(&Error adding epoll events for fd %d, errno=%d&, fd, errno);
return -1;
mRequests.add(fd, request);
int epollResult = epoll_ctl(mEpollFd, EPOLL_CTL_MOD, fd, & eventItem);
if (epollResult & 0) {
ALOGE(&Error modifying epoll events for fd %d, errno=%d&, fd, errno);
return -1;
mRequests.replaceValueAt(requestIndex, request);
} // release lock
如果callback为空会检查mAllowNonCallbacks看是否允许callback为空，如果允许callback为空还会检测ident是否&=0。如果callback不为空会把ident的值赋值为ALOOPER_POLL_CALLBACK，不管传进来的是什么值。
接下来把传进来的参数值封装到一个Request结构体中，并以描述符为键保存到一个KeyedVector mRequests中，然后通过epoll_ctl添加或替换（如果这个描述符之前有调用addFD添加监听）对这个描述符事件的监听。
通过Looper.prepare初始化好消息队列后就可以调用Looper.loop进入消息循环了，然后我们就可以向消息队列发送消息，消息循环就会取出消息进行处理，在看消息处理之前，先看一下消息是怎么被添加到消息队列的。
在Java层，Message类表示一个消息对象，要发送消息首先就要先获得一个消息对象，Message类的构造函数是public的，但是不建议直接new Message，Message内部保存了一个缓存的消息池，我们可以用obtain从缓存池获得一个消息，Message使用完后系统会调用recycle回收，如果自己new很多Message，每次使用完后系统放入缓存池，会占用很多内存的，如下所示：
public static Message obtain() {
synchronized (sPoolSync) {
if (sPool != null) {
Message m = sP
sPool = m.
m.next = null;
sPoolSize--;
return new Message();
public void recycle() {
clearForRecycle();
synchronized (sPoolSync) {
if (sPoolSize & MAX_POOL_SIZE) {
sPool = this;
sPoolSize++;
Message内部通过next成员实现了一个链表，这样sPool就了为了一个Messages的缓存链表。
消息对象获取到了怎么发送呢，大家都知道是通过Handler的post、sendMessage等方法，其实这些方法最终都是调用的同一个方法sendMessageAtTime:
public boolean sendMessageAtTime(Message msg, long uptimeMillis) {
MessageQueue queue = mQ
if (queue == null) {
RuntimeException e = new RuntimeException(
this + & sendMessageAtTime() called with no mQueue&);
Log.w(&Looper&, e.getMessage(), e);
return false;
return enqueueMessage(queue, msg, uptimeMillis);
sendMessageAtTime获取到消息队列然后调用enqueueMessage方法，消息队列mQueue是从与Handler关联的Looper获得的。
private boolean enqueueMessage(MessageQueue queue, Message msg, long uptimeMillis) {
msg.target = this;
if (mAsynchronous) {
msg.setAsynchronous(true);
return queue.enqueueMessage(msg, uptimeMillis);
enqueueMessage将message的target设置为当前的handler，然后调用MessageQueue的enqueueMessage，在调用queue.enqueueMessage之前判断了mAsynchronous，从名字看是异步消息的意思，要明白Asynchronous的作用，需要先了解一个概念Barrier。
Barrier与Asynchronous Message
Barrier是什么意思呢，从名字看是一个拦截器，在这个拦截器后面的消息都暂时无法执行，直到这个拦截器被移除了，MessageQueue有一个函数叫enqueueSyncBarier可以添加一个Barrier。
int enqueueSyncBarrier(long when) {
// Enqueue a new sync barrier token.
// We don't need to wake the queue because the purpose of a barrier is to stall it.
synchronized (this) {
final int token = mNextBarrierToken++;
final Message msg = Message.obtain();
msg.arg1 =
Message prev = null;
Message p = mM
if (when != 0) {
while (p != null && p.when &= when) {
if (prev != null) { // invariant: p == prev.next
msg.next =
prev.next =
msg.next =
mMessages =
在enqueueSyncBarrier中，obtain了一个Message，并设置msg.arg1=token，token仅是一个每次调用enqueueSyncBarrier时自增的int值，目的是每次调用enqueueSyncBarrier时返回唯一的一个token，这个Message同样需要设置执行时间，然后插入到消息队列，特殊的是这个Message没有设置target，即msg.target为null。
进入消息循环后会不停地从MessageQueue中取消息执行，调用的是MessageQueue的next函数，其中有这么一段：
Message msg = mM
if (msg != null && msg.target == null) {
// Stalled by a barrier.
Find the next asynchronous message in the queue.
msg = msg.
} while (msg != null && !msg.isAsynchronous());
如果队列头部的消息的target为null就表示它是个Barrier，因为只有两种方法往mMessages中添加消息，一种是enqueueMessage，另一种是enqueueBarrier，而enqueueMessage中如果mst.target为null是直接抛异常的，后面会看到。
所谓的异步消息其实就是这样的，我们可以通过enqueueBarrier往消息队列中插入一个Barrier，那么队列中执行时间在这个Barrier以后的同步消息都会被这个Barrier拦截住无法执行，直到我们调用removeBarrier移除了这个Barrier，而异步消息则没有影响，消息默认就是同步消息，除非我们调用了Message的setAsynchronous，这个方法是隐藏的。只有在初始化Handler时通过参数指定往这个Handler发送的消息都是异步的，这样在Handler的enqueueMessage中就会调用Message的setAsynchronous设置消息是异步的，从上面Handler.enqueueMessage的代码中可以看到。
&所谓异步消息，其实只有一个作用，就是在设置Barrier时仍可以不受Barrier的影响被正常处理，如果没有设置Barrier，异步消息就与同步消息没有区别，可以通过removeSyncBarrier移除Barrier：
void removeSyncBarrier(int token) {
// Remove a sync barrier token from the queue.
// If the queue is no longer stalled by a barrier then wake it.
final boolean needW
synchronized (this) {
Message prev = null;
Message p = mM
while (p != null && (p.target != null || p.arg1 != token)) {
if (p == null) {
throw new IllegalStateException(&The specified message queue synchronization &
+ & barrier token has not been posted or has already been removed.&);
if (prev != null) {
prev.next = p.
needWake = false;
mMessages = p.
needWake = mMessages == null || mMessages.target != null;
p.recycle();
if (needWake) {
nativeWake(mPtr);
参数token就是enqueueSyncBarrier的返回值，如果没有调用指定的token不存在是会抛异常的。
enqueueMessage
接下来看一下是怎么MessageQueue的enqueueMessage。
final boolean enqueueMessage(Message msg, long when) {
if (msg.isInUse()) {
throw new AndroidRuntimeException(msg + & This message is already in use.&);
if (msg.target == null) {
throw new AndroidRuntimeException(&Message must have a target.&);
boolean needW
synchronized (this) {
if (mQuiting) {
RuntimeException e = new RuntimeException(
msg.target + & sending message to a Handler on a dead thread&);
Log.w(&MessageQueue&, e.getMessage(), e);
return false;
msg.when =
Message p = mM
if (p == null || when == 0 || when & p.when) {
// New head, wake up the event queue if blocked.
msg.next =
mMessages =
needWake = mB
// Inserted within the middle of the queue.
Usually we don't have to wake
// up the event queue unless there is a barrier at the head of the queue
// and the message is the earliest asynchronous message in the queue.
needWake = mBlocked && p.target == null && msg.isAsynchronous();
for (;;) {
if (p == null || when & p.when) {
if (needWake && p.isAsynchronous()) {
needWake = false;
msg.next = // invariant: p == prev.next
prev.next =
if (needWake) {
nativeWake(mPtr);
return true;
注意上面代码红色的部分，当msg.target为null时是直接抛异常的。
在enqueueMessage中首先判断，如果当前的消息队列为空，或者新添加的消息的执行时间when是0，或者新添加的消息的执行时间比消息队列头的消息的执行时间还早，就把消息添加到消息队列头（消息队列按时间排序），否则就要找到合适的位置将当前消息添加到消息队列。
Native发送消息
消息模型不只是Java层用的，Native层也可以用，前面也看到了消息队列初始化时也同时初始化了Native层的Looper与NativeMessageQueue，所以Native层应该也是可以发送消息的。与Java层不同的是，Native层是通过Looper发消息的，同样所有的发送方法最终是调用sendMessageAtTime：
void Looper::sendMessageAtTime(nsecs_t uptime, const sp&MessageHandler&& handler,
const Message& message) {
#if DEBUG_CALLBACKS
ALOGD(&%p ~ sendMessageAtTime - uptime=%lld, handler=%p, what=%d&,
this, uptime, handler.get(), message.what);
size_t i = 0;
{ // acquire lock
AutoMutex _l(mLock);
size_t messageCount = mMessageEnvelopes.size();
while (i & messageCount && uptime &= mMessageEnvelopes.itemAt(i).uptime) {
i += 1;
MessageEnvelope messageEnvelope(uptime, handler, message);
mMessageEnvelopes.insertAt(messageEnvelope, i, 1);
// Optimization: If the Looper is currently sending a message, then we can skip
// the call to wake() because the next thing the Looper will do after processing
// messages is to decide when the next wakeup time should be.
In fact, it does
// not even matter whether this code is running on the Looper thread.
if (mSendingMessage) {
} // release lock
// Wake the poll loop only when we enqueue a new message at the head.
if (i == 0) {
&Native Message只有一个int型的what字段用来区分不同的消息，sendMessageAtTime指定了Message，Message要执行的时间when，与处理这个消息的Handler：MessageHandler，然后用MessageEnvelope封装了time, MessageHandler与Message，Native层发的消息都保存到了mMessageEnvelopes中，mMessageEnvelopes是一个Vector&MessageEnvelope&。Native层消息同样是按时间排序，与Java层的消息分别保存在两个队列里。
消息队列初始化好了，也知道怎么发消息了，下面就是怎么处理消息了，看Handler.loop函数：
public static void loop() {
final Looper me = myLooper();
if (me == null) {
throw new RuntimeException(&No L Looper.prepare() wasn't called on this thread.&);
final MessageQueue queue = me.mQ
// Make sure the identity of this thread is that of the local process,
// and keep track of what that identity token actually is.
Binder.clearCallingIdentity();
final long ident = Binder.clearCallingIdentity();
for (;;) {
Message msg = queue.next(); // might block
if (msg == null) {
// No message indicates that the message queue is quitting.
// This must be in a local variable, in case a UI event sets the logger
Printer logging = me.mL
if (logging != null) {
logging.println(&&&&&& Dispatching to & + msg.target + & & +
msg.callback + &: & + msg.what);
msg.target.dispatchMessage(msg);
if (logging != null) {
logging.println(&&&&&& Finished to & + msg.target + & & + msg.callback);
// Make sure that during the course of dispatching the
// identity of the thread wasn't corrupted.
final long newIdent = Binder.clearCallingIdentity();
if (ident != newIdent) {
Log.wtf(TAG, &Thread identity changed from 0x&
+ Long.toHexString(ident) + & to 0x&
+ Long.toHexString(newIdent) + & while dispatching to &
+ msg.target.getClass().getName() + & &
+ msg.callback + & what=& + msg.what);
msg.recycle();
loop每次从MessageQueue取出一个Message，调用msg.target.dispatchMessage(msg)，target就是发送message时跟message关联的handler，这样就调用到了熟悉的dispatchMessage，Message被处理后会被recycle。当queue.next返回null时会退出消息循环，接下来就看一下MessageQueue.next是怎么取出消息的，又会在什么时候返回null。
final Message next() {
int pendingIdleHandlerCount = -1; // -1 only during first iteration
int nextPollTimeoutMillis = 0;
for (;;) {
if (nextPollTimeoutMillis != 0) {
Binder.flushPendingCommands();
nativePollOnce(mPtr, nextPollTimeoutMillis);
synchronized (this) {
if (mQuiting) {
// Try to retrieve the next message.
Return if found.
final long now = SystemClock.uptimeMillis();
Message prevMsg = null;
Message msg = mM
if (msg != null && msg.target == null) {
// Stalled by a barrier.
Find the next asynchronous message in the queue.
msg = msg.
} while (msg != null && !msg.isAsynchronous());
if (msg != null) {
if (now & msg.when) {
// Next message is not ready.
Set a timeout to wake up when it is ready.
nextPollTimeoutMillis = (int) Math.min(msg.when - now, Integer.MAX_VALUE);
// Got a message.
mBlocked = false;
if (prevMsg != null) {
prevMsg.next = msg.
mMessages = msg.
msg.next = null;
if (false) Log.v(&MessageQueue&, &Returning message: & + msg);
msg.markInUse();
// No more messages.
nextPollTimeoutMillis = -1;
// If first time idle, then get the number of idlers to run.
// Idle handles only run if the queue is empty or if the first message
// in the queue (possibly a barrier) is due to be handled in the future.
if (pendingIdleHandlerCount & 0
&& (mMessages == null || now & mMessages.when)) {
pendingIdleHandlerCount = mIdleHandlers.size();
if (pendingIdleHandlerCount &= 0) {
// No idle handlers to run.
Loop and wait some more.
mBlocked = true;
if (mPendingIdleHandlers == null) {
mPendingIdleHandlers = new IdleHandler[Math.max(pendingIdleHandlerCount, 4)];
mPendingIdleHandlers = mIdleHandlers.toArray(mPendingIdleHandlers);
// Run the idle handlers.
// We only ever reach this code block during the first iteration.
for (int i = 0; i & pendingIdleHandlerC i++) {
final IdleHandler idler = mPendingIdleHandlers[i];
mPendingIdleHandlers[i] = null; // release the reference to the handler
boolean keep = false;
keep = idler.queueIdle();
} catch (Throwable t) {
Log.wtf(&MessageQueue&, &IdleHandler threw exception&, t);
if (!keep) {
synchronized (this) {
mIdleHandlers.remove(idler);
// Reset the idle handler count to 0 so we do not run them again.
pendingIdleHandlerCount = 0;
// While calling an idle handler, a new message could have been delivered
// so go back and look again for a pending message without waiting.
nextPollTimeoutMillis = 0;
MessageQueue.next首先会调用nativePollOnce，然后如果mQuiting为true就返回null，Looper就会退出消息循环。
接下来取消息队列头部的消息，如果头部消息是Barrier（target==null）就往后遍历找到第一个异步消息，接下来检测获取到的消息（消息队列头部的消息或者第一个异步消息），如果为null表示没有消息要执行，设置nextPollTimeoutMillis = -1；否则检测这个消息要执行的时间，如果到执行时间了就将这个消息markInUse并从消息队列移除，然后从next返回到loop；否则设置nextPollTimeoutMillis = (int) Math.min(msg.when - now, Integer.MAX_VALUE)，即距离最近要执行的消息还需要多久，无论是当前消息队列没有消息可以执行（设置了Barrier并且没有异步消息或消息队列为空）还是队列头部的消息未到执行时间，都会执行后面的代码，看有没有设置IdleHandler，如果有就运行IdleHandler，当IdleHandler被执行之后会设置nextPollTimeoutMillis
首先看一下nativePollOnce，native方法，调用JNI，最后调到了Native Looper::pollOnce，并从Java层传进去了nextPollTimeMillis，即Java层的消息队列中执行时间最近的消息还要多久到执行时间。
int Looper::pollOnce(int timeoutMillis, int* outFd, int* outEvents, void** outData) {
int result = 0;
for (;;) {
while (mResponseIndex & mResponses.size()) {
const Response& response = mResponses.itemAt(mResponseIndex++);
int ident = response.request.
if (ident &= 0) {
int fd = response.request.
int events = response.
void* data = response.request.
#if DEBUG_POLL_AND_WAKE
ALOGD(&%p ~ pollOnce - returning signalled identifier %d: &
&fd=%d, events=0x%x, data=%p&,
this, ident, fd, events, data);
if (outFd != NULL) *outFd =
if (outEvents != NULL) *outEvents =
if (outData != NULL) *outData =
if (result != 0) {
#if DEBUG_POLL_AND_WAKE
ALOGD(&%p ~ pollOnce - returning result %d&, this, result);
if (outFd != NULL) *outFd = 0;
if (outEvents != NULL) *outEvents = 0;
if (outData != NULL) *outData = NULL;
result = pollInner(timeoutMillis);
先不看开始的一大串代码，先看一下pollInner：
int Looper::pollInner(int timeoutMillis) {
#if DEBUG_POLL_AND_WAKE
ALOGD(&%p ~ pollOnce - waiting: timeoutMillis=%d&, this, timeoutMillis);
// Adjust the timeout based on when the next message is due.
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 = messageTimeoutM
#if DEBUG_POLL_AND_WAKE
ALOGD(&%p ~ pollOnce - next message in %lldns, adjusted timeout: timeoutMillis=%d&,
this, mNextMessageUptime - now, timeoutMillis);
int result = ALOOPER_POLL_WAKE;
mResponses.clear();
mResponseIndex = 0;
struct epoll_event eventItems[EPOLL_MAX_EVENTS];
int eventCount = epoll_wait(mEpollFd, eventItems, EPOLL_MAX_EVENTS, timeoutMillis);
// Acquire lock.
mLock.lock();
// Check for poll error.
if (eventCount & 0) {
if (errno == EINTR) {
ALOGW(&Poll failed with an unexpected error, errno=%d&, errno);
result = ALOOPER_POLL_ERROR;
// Check for poll timeout.
if (eventCount == 0) {
#if DEBUG_POLL_AND_WAKE
ALOGD(&%p ~ pollOnce - timeout&, this);
result = ALOOPER_POLL_TIMEOUT;
// Handle all events.
#if DEBUG_POLL_AND_WAKE
ALOGD(&%p ~ pollOnce - handling events from %d fds&, this, eventCount);
for (int i = 0; i & eventC i++) {
int fd = eventItems[i].data.
uint32_t epollEvents = eventItems[i].
if (fd == mWakeReadPipeFd) {
if (epollEvents & EPOLLIN) {
ALOGW(&Ignoring unexpected epoll events 0x%x on wake read pipe.&, epollEvents);
ssize_t requestIndex = mRequests.indexOfKey(fd);
if (requestIndex &= 0) {
int events = 0;
if (epollEvents & EPOLLIN) events |= ALOOPER_EVENT_INPUT;
if (epollEvents & EPOLLOUT) events |= ALOOPER_EVENT_OUTPUT;
if (epollEvents & EPOLLERR) events |= ALOOPER_EVENT_ERROR;
if (epollEvents & EPOLLHUP) events |= ALOOPER_EVENT_HANGUP;
pushResponse(events, mRequests.valueAt(requestIndex));
ALOGW(&Ignoring unexpected epoll events 0x%x on fd %d that is &
&no longer registered.&, epollEvents, fd);
// Invoke pending message callbacks.
mNextMessageUptime = LLONG_MAX;
while (mMessageEnvelopes.size() != 0) {
nsecs_t now = systemTime(SYSTEM_TIME_MONOTONIC);
const MessageEnvelope& messageEnvelope = mMessageEnvelopes.itemAt(0);
if (messageEnvelope.uptime &= now) {
// Remove the envelope from the list.
// We keep a strong reference to the handler until the call to handleMessage
// finishes.
Then we drop it so that the handler can be deleted *before*
// we reacquire our lock.
{ // obtain handler
sp&MessageHandler& handler = messageEnvelope.
Message message = messageEnvelope.
mMessageEnvelopes.removeAt(0);
mSendingMessage = true;
mLock.unlock();
#if DEBUG_POLL_AND_WAKE || DEBUG_CALLBACKS
ALOGD(&%p ~ pollOnce - sending message: handler=%p, what=%d&,
this, handler.get(), message.what);
handler-&handleMessage(message);
} // release handler
mLock.lock();
mSendingMessage = false;
result = ALOOPER_POLL_CALLBACK;
// The last message left at the head of the queue determines the next wakeup time.
mNextMessageUptime = messageEnvelope.
// Release lock.
mLock.unlock();
// Invoke all response callbacks.
for (size_t i = 0; i & mResponses.size(); i++) {
Response& response = mResponses.editItemAt(i);
if (response.request.ident == ALOOPER_POLL_CALLBACK) {
int fd = response.request.
int events = response.
void* data = response.request.
#if DEBUG_POLL_AND_WAKE || DEBUG_CALLBACKS
ALOGD(&%p ~ pollOnce - invoking fd event callback %p: fd=%d, events=0x%x, data=%p&,
this, response.request.callback.get(), fd, events, data);
int callbackResult = response.request.callback-&handleEvent(fd, events, data);
if (callbackResult == 0) {
removeFd(fd);
// Clear the callback reference in the response structure promptly because we
// will not clear the response vector itself until the next poll.
response.request.callback.clear();
result = ALOOPER_POLL_CALLBACK;
Java层的消息都保存在了Java层MessageQueue的成员mMessages中，Native层的消息都保存在了Native Looper的mMessageEnvelopes中，这就可以说有两个消息队列，而且都是按时间排列的。timeOutMillis表示Java层下个要执行的消息还要多久执行，mNextMessageUpdate表示Native层下个要执行的消息还要多久执行，如果timeOutMillis为0，epoll_wait不设置TimeOut直接返回；如果为-1说明Java层无消息直接用Native的time
out；否则pollInner取这两个中的最小值作为timeOut调用epoll_wait。当epoll_wait返回时就可能有以下几种情况：
出错返回。
正常返回，描述符上有事件产生。
如果是前两种情况直接goto DONE。
否则就说明FD上有事件发生了，如果是mWakeReadPipeFd的EPOLLIN事件就调用awoken，如果不是mWakeReadPipeFd，那就是通过addFD添加的fd，在addFD中将要监听的fd及其events，callback,data封装成了Request对象，并以fd为键保存到了KeyedVector mRequests中，所以在这里就以fd为键获得在addFD时关联的Request，并连同events通过pushResonse加入mResonse队列（Vector），Resonse仅是对events与Request的封装。如果是epoll_wait出错或timeout，就没有描述符上有事件，就不用执行这一段代码，所以直接goto
void Looper::pushResponse(int events, const Request& request) {
response.events =
response.request =
mResponses.push(response);
接下来进入DONE部分，从mMessageEnvelopes取出头部的Native消息，如果到达了执行时间就调用它内部保存的MessageeHandler的handleMessage处理并从Native 消息队列移除，设置result为ALOOPER_POLL_CALLBACK，否则计算mNextMessageUptime表示Native消息队列下一次消息要执行的时间。如果未到头部消息的执行时间有可能是Java层消息队列消息的执行时间小于Native层消息队列头部消息的执行时间，到达了Java层消息的执行时间epoll_wait
TimeOut返回了，或都通过addFd添加的描述符上有事件发生导致epoll_wait返回，或者epoll_wait是出错返回。Native消息是没有Barrier与Asynchronous的。
最后，遍历mResponses（前面刚通过pushResponse存进去的），如果response.request.ident&==ALOOPER_POLL_CALLBACK，就调用注册的callback的handleEvent(fd,&events,&data)进行处理，然后从mResonses队列中移除，这次遍历完之后，mResponses中保留来来的就都是ident&=0并且callback为NULL的了。在NativeMessageQueue初始化Looper时传入了mAllowNonCallbacks为false，所以这次处理完后mResponses一定为空。
接下来返回到pollOnce。pollOnce是一个for循环，pollInner中处理了所有response.request.ident==ALOOPER_POLL_CALLBACK的Response，在第二次进入for循环后如果mResponses不为空就可以找到ident&0的Response，将其ident作为返回值返回由调用pollOnce的函数自己处理，在这里我们是在NativeMessageQueue中调用的Loope的pollOnce，没对返回值进行处理，而且mAllowNonCallbacks为false也就不可能进入这个循环。pollInner返回值不可能是0，或者说只可能是负数，所以pollOnce中的for循环只会执行两次，在第二次就返回了。
Native Looper可以单独使用，也有一个prepare函数，这时mAllowNonCallbakcs值可能为true，pollOnce中对mResponses的处理就有意义了。
&wake与awoken
在Native Looper的构造函数中，通过pipe打开了一个管道，并用mWakeReadPipeFd与mWakeWritePipeFd分别保存了管道的读端与写端，然后用epoll_ctl(mEpollFd,&EPOLL_CTL_ADD,&mWakeReadPipeFd,&&eventItem)监听了读端的EPOLLIN事件，在pollInner中通过epoll_wait(mEpollFd,&eventItems,&EPOLL_MAX_EVENTS,&timeoutMillis)读取事件，那是在什么时候往mWakeWritePipeFd写，又是在什么时候读的mWakeReadPipeFd呢？
在Looper.cpp中我们可以发现如下两个函数：
void Looper::wake() {
#if DEBUG_POLL_AND_WAKE
ALOGD(&%p ~ wake&, this);
ssize_t nW
nWrite = write(mWakeWritePipeFd, &W&, 1);
} while (nWrite == -1 && errno == EINTR);
if (nWrite != 1) {
if (errno != EAGAIN) {
ALOGW(&Could not write wake signal, errno=%d&, errno);
void Looper::awoken() {
#if DEBUG_POLL_AND_WAKE
ALOGD(&%p ~ awoken&, this);
char buffer[16];
ssize_t nR
nRead = read(mWakeReadPipeFd, buffer, sizeof(buffer));
} while ((nRead == -1 && errno == EINTR) || nRead == sizeof(buffer));
wake函数向mWakeWritePipeFd写入了一个“W”字符，awoken从mWakeReadPipeFd读，往mWakeWritePipeFd写数据只是为了在pollInner中的epoll_wait可以监听到事件返回。在pollInner也可以看到如果是mWakeReadPipeFd的EPOLLIN事件只是调用了awoken消耗掉了写入的字符就往后处理了。
那什么时候调用wake呢？这个只要找到调用的地方分析一下就行了，先看Looper.cpp，在sendMessageAtTime即发送Native Message的时候，根据发送的Message的执行时间查找mMessageEnvelopes计算应该插入的位置，如果是在头部插入，就调用wake唤醒epoll_wait，因为在进入pollInner时根据Java层消息队列头部消息的执行时间与Native层消息队列头部消息的执行时间计算出了一个timeout，如果这个新消息是在头部插入，说明执行时间至少在上述两个消息中的一个之前，所以应该唤醒epoll_wait，epoll_wait返回后，检查Native消息队列，看头部消息即刚插入的消息是否到执行时间了，到了就执行，否则就可能需要设置新的timeout。同样在Java层的MessageQueue中，有一个函数nativeWake也同样可以通过JNI调用wake，调用nativeWake的时机与在Native调用wake的时机类似，在消息队列头部插入消息，还有一种情况就是，消息队列头部是一个Barrier，而且插入的消息是第一个异步消息。
if (p == null || when == 0 || when & p.when) {
// New head, wake up the event queue if blocked.
msg.next =
mMessages =
needWake = mB
// Inserted within the middle of the queue.
Usually we don't have to wake
// up the event queue unless there is a barrier at the head of the queue
// and the message is the earliest asynchronous message in the queue.
needWake = mBlocked && p.target == null && msg.isAsynchronous();//如果头部是Barrier并且新消息是异步消息则“有可能”需要唤醒
for (;;) {
if (p == null || when & p.when) {
if (needWake && p.isAsynchronous()) { // 消息队列中有异步消息并且执行时间在新消息之前，所以不需要唤醒。
needWake = false;
msg.next = // invariant: p == prev.next
prev.next =
在头部插入消息不一定调用nativeWake，因为之前可能正在执行IdleHandler，如果执行了IdleHandler，就在IdleHandler执行后把nextPollTimeoutMillis设置为0，下次进入for循环就用0调用nativePollOnce，不需要wake，只有在没有消息可以执行（消息队列为空或没到执行时间）并且没有设置IdleHandler时mBlocked才会为true。
如果Java层的消息队列被Barrier Block住了并且当前插入的是一个异步消息有可能需要唤醒Looper，因为异步消息可以在Barrier下执行，但是这个异步消息一定要是执行时间最早的异步消息。
退出Looper也需要wake，removeSyncBarrier时也可能需要。
转载请注明出处！
本文已收录于以下专栏：
相关文章推荐
转载自：http://blog.csdn.net/yanbober/article/details/。这篇博主的文章讲解得非常棒，其他也有比较棒的一些文章，大家可以关注一下。
这篇文章...
android消息处理机制，是android当中最重要的话题之一，来看看官方文档的分析（这里都直接粘贴处国内的镜像网站，快捷方便）：
一 .Hanler简介：
源码地址：http://wear.tec...
Android消息处理机制(Handler、Looper、MessageQueue与Message)
Android是消息驱动的，实现消息驱动有几个要素：
消息的表示：Message消息队列：...
为什么要使用Handler？
为什么在Activity中直接new Handler()一个匿名内部类就直接能sendMessage和handleMessage处理了呢？那么我在子thread中可以吗？...
Message：消息，由MessageQueue统一列队，终由Handler处理。
Handler：处理者，负责Message的发送及处理。
MessageQueue：消息队列，用来存放Handl...
Android 消息处理机制1.Android消息处理机制：消息处理机制本质：一个线程开启循环模式持续监听并依次处理其他线程给它发的消息。简单的说：一个线程开启一个无限循环模式，不断遍历自己的消息列表...
Android 消息处理机制估计都被写烂了，但是依然还是要写一下，因为Android应用程序是通过消息来驱动的，Android某种意义上也可以说成是一个以消息驱动的系统，UI、事件、生命周期都和消息处...
Android是消息驱动的，实现消息驱动有几个要素：
（1）消息的默示：Message
（2）消息队列：MessageQueue
（3）消息轮回，用于轮回取出消息进行处理惩罚：Looper
...
原文参考：/codingmyworld/archive//2174255.html  
先看一段非常经典的代码，我们从会这里入手，慢...
这是转载自网上的一篇消息处理机制，讲解得比较通俗的一篇文章。谢谢作者的分享，在这里做一个笔记，也希望对看到的人有很大的帮助。
android的消息处理有三个核心类：Looper,Handler和...
他的最新文章
讲师：王哲涵
讲师：王渊命
您举报文章：
举报原因：
原文地址：
原因补充：
(最多只允许输入30个字)}