Android 异步消息处理机制终结篇 :深入理解 Looper、Handler、Message、MessageQueue四者关系

版权声明：本文出自汪磊的博客，转载请务必注明出处。

一、概述

我们知道更新UI操作我们需要在UI线程中操作，如果在子线程中更新UI会发生异常可能导致崩溃，但是在UI线程中进行耗时操作又会导致ANR，这时异步消息处理机制就登场了，大体流程就是我们在UI线程创建一个Handler，子线程创建一个Message，利用Handler将Message发送到MessageQueue中，然后轮到Looper登场了，Looper负责从MessageQueue中不断获取Message，交给Handler处理，最后在Handler的handleMessage方法中处理相应操作即可。

好了，大体说了一下异步消息处理机制的流程，Demo就不举例了，直接分析源码。

二、源码层分析

Looper源码分析

Looper中最重要的就是prepare()以及loop()方法，首先看下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));
 }

prepare()方法调用prepare(boolean quitAllowed)方法，第6-8行首先检测当前线程中是否已经存储了Looper，如果已经存储过则抛出异常，这里我们就应该知道一个线程只能有一个Looper实例存在。sThreadLocal就是ThreadLocal，关于ThreadLocal我之前写过一篇介绍文章，这里就不详细说明了，请参照Android 异步消息处理机制前篇(一)：深入理解ThreadLocal。

第9行，如果当前线程没有存储过Looper，则new一个存储在当前线程。我们再看下Looper初始化的时候都做了什么：

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

主要就是初始化了一个MessageQueue赋值给mQueue变量，这里要明白，Looper初始化的时候会初始化一个MessageQueue与当前Looper绑定，后面会多次提到。

以上便是prepare方法的主要逻辑了，没什么复杂的，我们继续看loop(）方法：

 public static void loop() {
         final Looper me = myLooper();
         if (me == null) {
             throw new RuntimeException("No Looper; Looper.prepare() wasn't called on this thread.");
         }
         final MessageQueue queue = me.mQueue;

         // 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.
                 return;
             }

             // This must be in a local variable, in case a UI event sets the logger
             Printer logging = me.mLogging;
             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.recycleUnchecked();
         }
 }

第2行，调用myLooper()。源码如下：

 public static @Nullable Looper myLooper() {
         return sThreadLocal.get();
 }

很简单就是获取当前线程存储的Looper实例，3-5行检测是否为空，为空的话则会抛出异常，这里就提示我们loop()方法一定要放在prepare()方法之后调用，否则会抛出异常。

第6行取出与当前Looper绑定的MessageQueue。接下来就进入13-45行的死循环了。

14-18行，从MessageQueue消息队列中获取message，如果没有则阻塞。

如果消息队列中存在未处理的message，则调用 msg.target.dispatchMessage(msg)，target是什么鬼？其实就是Handler，这里先知道就可以了，后续会分析到。

44行，用完消息后对消息进行回收放进缓存池中，Message消息缓存池的实现原理请参照我之前的文章Android 异步消息处理机制前篇(二)：深入理解Message消息池。

loop()方法其实就是不断循环检查消息队列中是否存在未处理的消息，如果存在则交给Handler来处理。

Looper总结：

①Looper会在当前线程创建一个Looper实例存储在当前线程，并且会绑定一个MessageQueue。

②Looper的loop()方法，不断从MessageQueue中取消息，交给Handler的dispatchMessage去处理。

Handler源码分析

接下来我们分析Handler主要逻辑。先从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.mQueue;
         mCallback = callback;
         mAsynchronous = async;
 }

本质上调用两个参数的构造函数。

15行，Looper.myLooper()，这里还记得吧，从当前线程获取存储的Looper实例。

16-19行，判断是否为空，为空则抛出异常。

20行，获取与当前线程中Looper实例绑定的消息队列，赋值给当前Handler中mQueue变量。

通过以上逻辑，Handler就与当前线程中的Looper，MessageQueue建立上了关联。

接下来Handler最重要的功能就是发送消息了，最常用的是sendMessage(Message msg)，源码如下：

 public final boolean sendMessage(Message msg){
         return sendMessageDelayed(msg, 0);
 }

 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 = mQueue;
         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(Message msg, long uptimeMillis)方法。

13行获取MessageQueue ，14-19判断是否为空，如果不为空则执行20行逻辑，接下来我们看下enqueueMessage：

 private boolean enqueueMessage(MessageQueue queue, Message msg, long uptimeMillis) {
         msg.target = this;
         if (mAsynchronous) {
             msg.setAsynchronous(true);
         }
         return queue.enqueueMessage(msg, uptimeMillis);
 }

第2行，将当前Handler赋值给msg的targe，这里msg就会记住是哪个Handler发送的自己，在Looper的loop()方法中从消息队列中获取msg的时候，会调用 msg.target.dispatchMessage(msg)方法，交给发送自己的Handler的handleMessage方法来处理，这里说起来真绕口，不过这里一定要明白是怎么回事，面试中很可能会问到，比如，UI线程中创建Handler1,Handler2,Handler1发送msg1，Handler2发送Msg2,Handler2中的handleMessage是否会收到msg1?为什么？傻子都会回答不会，但是原理你能清清楚楚的讲解清楚吗，答案就是这里。

第6行，调用enqueueMessage方法将msg发送到消息队列。

接下来我们看下Handler中dispatchMessage(Message msg)方法：

 public void dispatchMessage(Message msg) {
         if (msg.callback != null) {
             handleCallback(msg);
         } else {
             if (mCallback != null) {
                 if (mCallback.handleMessage(msg)) {
                     return;
                 }
             }
             handleMessage(msg);
         }
 }

第2行判断msg的callbac是否为空，如果不为空则调用 handleCallback方法：

     private static void handleCallback(Message message) {
         message.callback.run();
     }

很简单，就是调用run方法，首先这里就有两个小问题，1，run方法是否在子线程执行？2，平时我们发送msg也不给msg设置callbac啊，这里什么时候会用到？

回答问题1之前我们先看问题2，Handler的post方法大家应该都用过，典型用法如下：

 public class MainActivity extends Activity {  

         private Handler handler;  

         @Override
         protected void onCreate(Bundle savedInstanceState) {
             super.onCreate(savedInstanceState);
             setContentView(R.layout.activity_main);
             handler = new Handler();
             new Thread(new Runnable() {
                 @Override
                 public void run() {
                     handler.post(new Runnable() {
                         @Override
                         public void run() {
                             //UI操作
                         }
                     });
                 }
             }).start();
         }
  }  

这样我们就可以在run方法里面进行UI操作了，显然这里run方法肯定是在主线程执行的，为什么呢？还是看下源码吧：

     public final boolean post(Runnable r)
     {
        return  sendMessageDelayed(getPostMessage(r), 0);
     }
     private static Message getPostMessage(Runnable r) {
         Message m = Message.obtain();
         m.callback = r;
         return m;
     }

第7行就将我们传入的Runnable赋值给了msg的callback，然后执行发送消息到消息队列逻辑，之后就是Looper负责取消息发送给Handler，会调用dispatchMessage方法，上面讲过首先会对msg的callback进行判断是否为null，如果不为null，则直接调用run方法，到这里问题2应该就解决了，就是我们调用post方法设置的Runnable其本质是设置给了msg。

那么问题1呢？什么时候会在子线程执行，答案就是与Handler的创建所在线程是一致的，只不过我们大部分都是用来在主线程创建，子线程的情况用的比较少。

好了，我们回到Handler中dispatchMessage(Message msg)方法继续分析：

5-9行如果mCallback不为null则调用mCallback的handleMessage方法，mCallback的赋值是在Handler创建的时候。

如果mCallback为null则就调用Handler中的handleMessage方法：

     /**
      * Subclasses must implement this to receive messages.
      */
     public void handleMessage(Message msg) {
     }

就是一个空方法，注释已经说了子类必须重写此方法接受消息进行处理。

好了到此Handler中核心部分就分析完了，小小的总结一下：

1、Handler的构造方法，会得到当前线程中保存的Looper实例，以及Looper实例中的MessageQueue，三者建立起联系。

2、Handler的sendMessage方法，会给msg的target赋值为handler自身，然后加入MessageQueue中。

MessageQueue源码分析

MessageQueue就是一个容器，用来存放message，主要就是存入，取出message的操作。

首先存入源码如下：

 boolean enqueueMessage(Message msg, long when) {
         if (msg.target == null) {
             throw new IllegalArgumentException("Message must have a target.");
         }
         if (msg.isInUse()) {
             throw new IllegalStateException(msg + " This message is already in use.");
         }

         synchronized (this) {
             if (mQuitting) {
                 IllegalStateException e = new IllegalStateException(
                         msg.target + " sending message to a Handler on a dead thread");
                 Log.w(TAG, e.getMessage(), e);
                 msg.recycle();
                 return false;
             }

             msg.markInUse();
             msg.when = when;
             Message p = mMessages;
             boolean needWake;
             if (p == null || when == 0 || when < p.when) {
                 // New head, wake up the event queue if blocked.
                 msg.next = p;
                 mMessages = msg;
                 needWake = mBlocked;
             } else {
                 // 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();
                 Message prev;
                 for (;;) {
                     prev = p;
                     p = p.next;
                     if (p == null || when < p.when) {
                         break;
                     }
                     if (needWake && p.isAsynchronous()) {
                         needWake = false;
                     }
                 }
                 msg.next = p; // invariant: p == prev.next
                 prev.next = msg;
             }

             // We can assume mPtr != 0 because mQuitting is false.
             if (needWake) {
                 nativeWake(mPtr);
             }
         }
         return true;
 }

MessageQueue内部维护了一个链表，mMessages用于记录链表头部元素。

19-45行逻辑可以看出，对于messge会有一个按照时间排序的操作，这个也不难理解，在我们发送消息的时候可以指定发送的时候，这个时间并不是推迟入队的时间，而是给message打上时间标记，MessageQueue对message的维护会按照时间来排序。

其实这里和之前文章讲过的Android 异步消息处理机制前篇(二)：深入理解Message消息池 的实现很像都是用链表实现的，只不过这里有个按照时间排序的操作。

取出的源码就不仔细分析了，大体过程说一下，在入队的时候会对message进行排序，并且mMessages会记录链表头部元素，取出message就是取出mMessages指向的消息，并且mMessages指向下一个消息，如果MessageQueue中不存在message，则阻塞一直等到有消息。

好了，讲到这里，异步消息通知最核心的部分就讲解完了。

异步消息通知总体流程总结:

老规矩，没有什么是一张图不能解决的

大部分关键点都在图中标注出来了，好了，本文到此就该结束了。

建议大家有时间看下View的post()方法以及 Activity的runOnUiThread()方法，其本质也都是使用异步消息通知这块技术点。