Android 源码解析Handler消息传递机制

一直想写一篇关于Android中很重要的Handler消息传递机制的讲解，无奈老哥拖延症的问题一直拖到现在才着手开始ㄟ(▔,▔)ㄏ，Handler机制大家肯定都使用过，也很简单，但一提起Handler机制的源码，对于初学者来说可能还会有些头疼（每个Android开发者都经历过的阶段），其实Handler机制的源码也很容易理解，那么本文就将在源码的角度分享一下我对Handler机制的理解。

一、简介

讲到android中的Handler的消息机制相信大家都不会陌生，android中经常使用Handler机制进行跨线程消息传递的(当然handler的用处还有很多博主不一一列举了)，为什么要跨线程呢？相信大家都很清楚android的机制工作线程（子线程）不能有更新UI操作,而UI线程（主线程）不能执行耗时操作的（activity中超过5秒的时间未能响应下一个事件、BroadcastReceive超过10未响应），耗时操作只能执行在工作线程（子线程）中，否则会报ANR(Application Not Responding) ，一旦发生ANR，程序奔溃了。那么如何解决这个问题呢？Android为我们提供了Handler消息机制用来实现在线程中执行耗时操作后，当需要更新UI时通过Handler发送消息回主线程中去执行更新UI的操作。

二、Handler机制简图和重要类&方法介绍

那么Android的Handler消息机制是如何工作的呢？那么下面我们在源码的角度详细解析一下Android的Handler消息机制。下图为handler消息传递机制的简图：

简略介绍Android中Handler机制中几个比较重要的类及其方法:（后文讲解handler消息机制调用流程时，会详细介绍）

1、Handler类，主要方法：

1.1 内置Callback接口，接收消息

  public interface Callback {
        public boolean handleMessage(Message msg);
    }

1.2 实现很多sendMessage方法用于发送消息到messageQueue（这个大家常用(～￣▽￣)～，这里不多介绍）。
1.3 Handler.post()方法传入一个Runnable回调的run方法可以执行在主线程，通常用于一些更新UI操作。
1.4 dispatchMessage(Message msg)方法，当messsage出队列时调用分发消息。
其中这个handleCallback(msg);方法和Handler.post（）、runUiThread（）方法执行相关，下文会详细介绍。

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

2、Looper类，主要方法：

2.1 prepare()方法初始化Looper和MessageQueue，同时将初始化的Looper放入ThreadLocal中。

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));
}

2.2 构造函数私有化

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

2.3 loop()方法用于轮询MessageQueue。

2.4 quitSafely()方法终止轮询MessageQueue。

3、Message类，主要方法：

3.1 属性：what arg1 arg2 obj（常用不仔细介绍了），target（Handler）：发送Message的handler对象引用，callback（Runnable）：Handler.post()方法传入的Runnable对象。

3.2 obtain()方法返回Message实例从global pool中，避免你创建太多实例。

4、MessageQueue类,主要方法:

4.1 next()出队方法，返回队首Message

5、ThreadLocal类，主要方法：

5.1 set(T value)方法，存储数据，与当前线程绑定。
5.2 get()方法，根据调用线程返回存储数据，与 set(T value)方法对应。

三、Handler机制整体调用流程&源码分析

这么多准备工作后，那接下来进入正篇，我们就拿下面这段代码结合handler消息传递机制的简图，详细讲解一下Android中Handler机制：这是一个很清晰的示例代码，告诉我们创建Handler分三个步骤，我们索性称他为：Handler机制的三部曲：
1、Looper.prepare(),初始化Looper 、MessageQueue等等；
2、sendMessage发送消息到MessageQueue消息队列，实现handleMessage(Message msg)接收消息；
3、Looper.loop();开始轮询MessageQueue，拿到Message进行分发操作。

class LooperThread extends Thread {
  *      public Handler mHandler;
  *
  *      public void run() {
  *          Looper.prepare();
  *
  *          mHandler = new Handler() {
  *              public void handleMessage(Message msg) {
  *                  // process incoming messages here
  *              }
  *          };
  *
  *          Looper.loop();
  *      }
  *

看到上面代码可能有些老哥有点疑惑，平时自己在使用handler的时候也没有调用Looper.prepare()、Looper.loop()操作啊，比如我们在activity中直接初始化handler之后就可以发消息，收消息执行相关操作了啊？

针对这个疑问我们先给出结论，随着我们对源码的深入解析你会理解的更加透彻。你创建时没有调用Looper.prepare()、Looper.loop()依然可以使用而不报错，这里有一个前提条件是：你一定是在主线程中初始化的handler。那你可能还会问为什么在主线程中初始化handler就不需要调用Looper.prepare()、Looper.loop()呢？答案是其实在主线程中程序启动时，已经帮你调用了Looper.prepare()、Looper.loop(),在ActivityThread中的main()方法中，我们可以找到相关代码如下：

    public static void main(String[] args) {

       .....//为了方便大家查看我删除了一下不相关代码

        Looper.prepareMainLooper();//这里开始调用Looper.prepare()
        ActivityThread thread = new ActivityThread();
        thread.attach(false);
        if (sMainThreadHandler == null) {
            sMainThreadHandler = thread.getHandler();
        }
        if (false) {
            Looper.myLooper().setMessageLogging(new
                    LogPrinter(Log.DEBUG, "ActivityThread"));
        }
        Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);
        Looper.loop();//开始调用Looper.loop()

     ......//为了方便大家查看我删除了一下不相关代码
    }

可以看到在主线程中程序的main()方法中已经调用了这两个方法，所以你不需要再去自己调用。

好那么我们回来继续介绍这三部曲：

1、Looper.prepare()

上文handler机制简图中，我们已经简单介绍了一下Looper.prepare()作用，Looper.prepare()的主要作用就是做一些初始化操作，初始化Looper放入ThreadLocal中、初始化MessageQueue，我们看一下相关源码：
补充：关于ThreadLocal这个类，由于篇幅问题，我会单独开一篇博客去详细讲解.在本文中你只需知道Looper是存储在这个类中，这个类通常使用来存储一些以线程为作用域的数据，其内部是以线程为key，数据为value进行存储的，线程之间数据是隔离开的。ThreadLocal详细解析连接

 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));
    }

我们可以看到当我们调用Looper暴露给我们的prepare()方法时，会在方法内部调用prepare(boolean quitAllowed)方法，sThreadLocal.get() != null检查ThreadLocal在当前线程下是否已经初始化过的Looper，如果有则会抛出异常"Only one Looper may be created per thread"（这段代码实际就是为了限制一个Handler的looper只能被初始化一次，即一个handler只能对应一个Looper，在一个handler内部多次调用Looper.prepare()方法时会抛出这个异常）如果没有则new Looper(quitAllowed) 存储到ThreadLocal中，我们可以注意到new Looper时，参数传递一个布尔值True，那么这个参数有什么实际意义呢？我们来看一下Looper的构造方法：

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

我们可以看到Looper的构造方法被私有化了，所以我们只能通过Looper.prepare()去创建Looper对象，在构造方法中又初始化了MessageQueue同时传入了我们传递过来的布尔值，同时获取当前线程赋值给mThread，这次我们知道我们传递的参数使用来初始化MessageQueue使用了。那我们继续追踪：

// True if the message queue can be quit.
    private final boolean mQuitAllowed;

MessageQueue(boolean quitAllowed) {
        mQuitAllowed = quitAllowed;
        mPtr = nativeInit();
    }

在MessageQueue的构造方法我们看到了这个参数的赋值给了mQuitAllowed，通过注释我们终于清楚了，这个参数的实际作用，就是设置初始化的消息队列MessageQueue是否可以被终止，在MessageQueue中我们也可以找到对应终止消息队列的方法：

 void quit(boolean safe) {
        if (!mQuitAllowed) {
            throw new IllegalStateException("Main thread not allowed to quit.");
        }

        synchronized (this) {
            if (mQuitting) {
                return;
            }
            mQuitting = true;

            if (safe) {
                removeAllFutureMessagesLocked();
            } else {
                removeAllMessagesLocked();
            }

            // We can assume mPtr != 0 because mQuitting was previously false.
            nativeWake(mPtr);
        }
    }

我们可以看到当mQuitAllowed为true时可以终止当前的MessageQueue。那老哥们可能要问了，Looper.prepare()时都默认设置设置为true是不是所有的MessageQueue都可以被终止呢？答案是否定的，我们不要忘记主线程中的activityThread类中初始化的looper，prepareMainLooper()方法：

public static void prepareMainLooper() {
        prepare(false);
        synchronized (Looper.class) {
            if (sMainLooper != null) {
                throw new IllegalStateException("The main Looper has already been prepared.");
            }
            sMainLooper = myLooper();
        }
    }

可以看到主线程初始化looper时传递的参数就是false，prepare(false)我们仔细思考一下自然也就能理解了，主线程的MessageQueue肯定是在整个application的生命周期内一直运行着的，直到程序退出才会被终止，所以初始化MessageQueue时设置不能被手动调用终止,也就很容易理解了，仔细观察上面quit方法的这段代码if(!mQuitAllowed) { throw new IllegalStateException("Main thread not allowed to quit.");也可以发现，当mQuitAllowed为false（即为主线程的MessageQueue）时，如果调用quit(boolean safe) 方法也会抛出异常提示Main thread not allowed to quit（主线程不被允许quit操作）

Looper.prepare()方法总结：

Looper.prepare()方法在初始化Handler前调用，用于初始化Looper、MessageQueue，由于Looper的构造函数私有化，所以为我们提供Looper.prepare()去创建一个Looper，同时在prepare()检查当前线程是否初始化过Looper，一个线程只能初始化一个looper，保证一个handler只能对应一个looper，通过调用ThreadLocal的set(T value)方法将初始化完成的Looper存储到ThreadLocal中进行线程隔离。主线程的MessageQueue不能调用quit方法终止，子线程可以调用quit方法终止消息队列。

2、sendMessage发送消息到MessageQueue消息队列

使用过handler的老哥肯定知道，实现handleMessage(Message msg)方法，用于接收消息执行相关操作，那消息是如何发送到handleMessage(Message msg)方法的呢？消息又是如何运转的呢？仔细看过本文开篇handler机制简图的老哥肯定对消息的传递有了一定认识。那么接下来我们就从源码的角度分析一下Message的运转。

我们有很多种发送消息的方法:

但是通过调用关系我们会发现他们最终几乎都会调用sendMessageAtTime(Message msg, long uptimeMillis)方法（sendMessageAtFrontOfQueue(Message msg)方法除外，这个方法后面我会单独给大家介绍）那我们就先看一下这个方法的源码：

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);
    }

方法参数1：msg 我们发送的消息对象
方法参数2：uptimeMillis=系统开机以来的毫秒数+延时毫秒数（未指定则为0）
观察源码我么会发现，首先进行的是消息队列MessageQueue初始化的检查，if (queue == null)直接抛出异常，" sendMessageAtTime() called with no mQueue"，MessageQueue如果已经初始化则会调用enqueueMessage(queue, msg, uptimeMillis)方法执行消息入队操作，继续源码追踪：

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

首先看一下这段代码msg.target = this;这段代码就是让发送的Message去持有发送此消息的handler的引用。主要是用于当消息出队时的消息分发操作（调用handler的dispatchMessage(Message msg)方法），下一部分解析Looper.loop()；时你会更加清楚他的作用，mAsynchronous用于设定同步还是异步消息，创建handler时传递参数指定，默认是同步消息，这块想要理解同步消息和异步消息需要知道一个Barrier的概念，即拦截器。handler机制中拦截器的作用是当执行到这个拦截器消息时，后面的同步消息都暂时无法执行，异步消息可以正常执行，直到这个拦截器被移除。

那么我们来看一下添加拦截器的代码：MessageQueue中的添加拦截器消息的一段代码postSyncBarrier()方法：

    public int postSyncBarrier() {
        return postSyncBarrier(SystemClock.uptimeMillis());
    }

    private int postSyncBarrier(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.markInUse();
            msg.when = when;
            msg.arg1 = token;

            Message prev = null;
            Message p = mMessages;
            if (when != 0) {
                while (p != null && p.when <= when) {
                    prev = p;
                    p = p.next;
                }
            }
            if (prev != null) { // invariant: p == prev.next
                msg.next = p;
                prev.next = msg;
            } else {
                msg.next = p;
                mMessages = msg;
            }
            return token;
        }
    }

15-29行代码就是将一个拦截器消息添加到messageQueue中（这块是如何存储到messageQueue目前可能还不太好理解，没关系当看完后面MessageQueue中消息存储的结构你会很容易理解），仔细观察这个拦截器消息我们可以发现他和普通消息的不同就是：拦截器消息没有持有handler的引用，这点很重要，消息出队时，这一点将成为判断出队消息是否是拦截器消息的依据。

接下来我们看一下简单截取一小部分消息出队的代码如下：

                if (msg != null && msg.target == null) {
                    // Stalled by a barrier.  Find the next asynchronous message in the queue.
                    do {
                        prevMsg = msg;
                        msg = msg.next;
                    } while (msg != null && !msg.isAsynchronous());
                }

当消息出队时判断if (msg != null && msg.target == null)如果不持有handler的引用，即为一个拦截器消息时，prevMsg = msg; msg = msg.next;一直执行，不断检索消息队列，直到下一个消息为异步消息才退出while循环，执行异步消息。就是通过这种方式，实现拦截器的作用。只有同步消息才会被拦截器拦截。异步消息不会被拦截。

那么我们接着上面分析，这个方法queue.enqueueMessage(msg, uptimeMillis)就是实际的入队操作了，将handler发送的消息存入消息队列MessageQueue中，我们继续分析MessageQueue是如何存储的消息的：

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;
    }

通过观察源码（11-45行代码）我们可以看的很明白，首先消息队列MessageQueue并不是我们想的那样用一集合存储所有的消息，放到MessageQueue中，代替的是MessageQueue只存储当前需要处理的消息mMessages，每当有新消息msg入队时，总是和当前消息mMessages比较先执行哪一个消息，比较的规则就是根据我们传入的参数uptimeMillis，uptimeMillis越小越先执行，同时通过msg.next去指定下一需要执行的消息，整体结构和C语言中的链表很像，每个非末尾消息中都存储着下一个需要执行的消息。其结构如同一个链表如下图：


我看在看一下这一段代码if (p == null || when == 0 || when < p.when)，p == null很好理解即当前队列中没有需要执行的Message，when < p.when也很好理解新入队的消息msg比当前队列中消息的uptimeMillis更小，需要优先执行，但是when == 0是一种什么情况呢？记住我们上面讲过这个 uptimeMillis=系统开机以来的毫秒数+延时毫秒数（未指定则为0）的,看似这个值是不能为0的啊，的确这个值确实理论上不可能为0，当我们似乎忘记我们还有一个特别的方法没有讲解，上文介绍消息发送方法时，我们说话几乎所有方法都是调用了sendMessageAtTime(Message msg, long uptimeMillis)，但是有个方法除外，那就是sendMessageAtFrontOfQueue(Message msg)方法，那么现在我们就去分析一下这个特别的方法：

public final boolean sendMessageAtFrontOfQueue(Message msg) {
        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, 0);
    }

看到源码之后，一切都揭晓了，enqueueMessage(queue, msg, 0);就造就了when == 0，这种看似不可能的情况，他们没有通过sendMessageAtTime(Message msg, long uptimeMillis)方法入队，而是直接调用了入队方法enqueueMessage(queue, msg, 0)，指定uptimeMillis=0，那么可能会有个疑惑，就是这样做到底为了什么呢？也很容易解答，这个方法就是让你可以发送一个消息让其在消息队列的队首，可以最先执行。因为他手动指定了uptimeMillis=0，是一个最小值，所以通过这个方法发送的消息会一直在消息队列MessageQueue的队首。

其实我们还会经常使用的一个方法就是Handler的post(Runnable r)方法传入一个Runnable，回调的run方法可以在主线程去执行，可做更新UI等操作。通过查看源码我们也可以发现其实他最终主要也是调用sendMessageAtTime(Message msg, long uptimeMillis)方法，只不过调用前先通过getPostMessage(Runnable r)方法将Runnable封装成一个Message（即将Runnable赋值给Message的callback属性），具体代码如下：

private static Message getPostMessage(Runnable r) {
        Message m = Message.obtain();
        m.callback = r;
        return m;
    }

但需要注意的是postAtFrontOfQueue(Runnable r)是调用的sendMessageAtFrontOfQueue(Message msg)方法。

public final boolean post(Runnable r)
    {
       return  sendMessageDelayed(getPostMessage(r), 0);
    }

最终同样是调用sendMessageAtTime(Message msg, long uptimeMillis)方法实现消息入队。

同样的的方法还有一个就是activity类下的runUiThread()方法：

    public final void runOnUiThread(Runnable action) {
        if (Thread.currentThread() != mUiThread) {
            mHandler.post(action);
        } else {
            action.run();
        }
    }

简单易懂，如果当前线程不是主线程则调用的是handler的post方法，如果是主线程则直接调用run放法。具体为什么post方法的run方法就可以执行在主线程，将在下一部分Looper.loop()方法中给出的详细的讲解。

sendMessage发送消息到MessageQueue消息队列小结:

handler的sendMessage和post都是主要通过sendMessageAtTime(Message msg, long uptimeMillis)将消息发送到MessageQueue中，当然也有列外就是sendMessageAtFrontOfQueue(Message msg)（注意post方法中的postAtFrontOfQueue(Runnable r)其实最终也是调用的sendMessageAtFrontOfQueue(Message msg)）方法直接将消息发送至MessageQueue中并指定其在队首，优先执行（他是通过直接指定uptimeMillis=0完成的）。MessageQueue的消息排序是通过uptimeMillis（uptimeMillis=系统开机以来的毫秒数+延时毫秒数（未指定则为0））排序的，uptimeMillis越小越先执行。同时MessageQueue并不是通过集合存储所有消息，而是只存储当前需要执行的消息，而每个消息去存储下一个需要执行的消息。类似一个链表结构。如下图所示：

3、Looper.loop()

第二部分我们了解了当我们发送消息的时候，消息进入消息队列的过程以及消息队列中消息是如何存储和排序的，那么接下来我们就来讲解一下handler机制三部曲的最后一部分，轮询消息队列—-Looper.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
            final Printer logging = me.mLogging;
            if (logging != null) {
                logging.println(">>>>> Dispatching to " + msg.target + " " +
                        msg.callback + ": " + msg.what);
            }

            final long traceTag = me.mTraceTag;
            if (traceTag != 0 && Trace.isTagEnabled(traceTag)) {
                Trace.traceBegin(traceTag, msg.target.getTraceName(msg));
            }
            try {
                msg.target.dispatchMessage(msg);
            } finally {
                if (traceTag != 0) {
                    Trace.traceEnd(traceTag);
                }
            }

            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();
        }
    }

通过观察loop()的源码（13行开始）我们可以发现loop()方*序消息队列是采用的方式是一个阻塞式的死循环for (;;)，首先通过Message msg = queue.next();获取队列中的Message，然后在32行将取出来的消息通过msg.target.dispatchMessage(msg);方法进行分发，在第二部分我们讲过发送消息进入消息队列的时候，有这样的一行代码msg.target = this;就是让消息持有发送他的handler的引用，当时介绍我们说这行代码是为了消息出队后的分发操作，也就是调用msg.target.dispatchMessage(msg);进行消息分发的，好那么我们继续分析dispatchMessage(msg)方法的源码：

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

观察源码我们发现，首先dispatchMessage(Message msg)方法判断了消息中的msg.callback属性是否为null，是不是看着有点眼熟？好像前面的的某一部分见过，没错！在第二部分讲解handler的post()方法时，我们提到过post方法首先将传入的Runnable对象封装成Message对象，我们再看一下这个过程源码：

 private static Message getPostMessage(Runnable r) {
        Message m = Message.obtain();
        m.callback = r;
        return m;
    }

这下清楚了吧，原来msg的这个callback属性就是我们post方法传过来的Runnable对象，那么这段if (msg.callback != null) { handleCallback(msg);}代码的含义也就很容易理解了，就是为了区分这个消息是通过post(Runnable r)系列还是通过sendMessage(Message msg)系列发送出去的，如果msg.callback != null证明是post发送出去的消息则执行handleCallback(msg);这个方法源码：

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

直接拿到这个callback（Runnable）对象执行它的run方法，所以这个run方法不确定执行在哪个线程。听到这里很多老哥可能有点疑惑，我们用的post方法的run回调不都是执行在主线程吗？怎么还不确定了？其实还是最初的情况，当你在主线程去初始化Handler时，系统在主线程中调用Looper.loop（），所以消息的分发操作即dispatchMessage(Message msg) 方法也在主线程中调用，自然handleCallback(Message message)方法也执行在主线程，所以直接调用run方法也会在主线程中回调。反之，如果在子线程中初始化handler子线程中调用Looper.loop（）方法时，自然run回调就会在子线程中执行。

注*这里是直接调用Runnable的run方法，并不会新开辟个新线程。

我们继续分析dispatchMessage(Message msg)方法中的下面一部分代码：

if (mCallback != null) {
      if (mCallback.handleMessage(msg)) {
              return;
        }
   }
   handleMessage(msg);

很简单首先通过判断mCallback != null，决定用mCallback.handleMessage(msg)回调还是直接调用handleMessage(msg)方法，这个和你初始化handler选用的构造方法有关，也很好理解，具体查看handler的构造方法。Callback 接口如下：

   public interface Callback {
        public boolean handleMessage(Message msg);

Looper.loop()小结

handler机制中通过Looper.loop()方法采用阻塞是死循环的方式去轮询消息队列MessageQueue，取出消息，通过Handler的dispatchMessage(Message msg)方法进行分发，同时在分发操作时区分了是post方法还是sendMessage方法发送的消息，执行不同的处理，post消息直接通过handleCallback(msg);方法调用Runnable的run方法。sendMessage消息之直接分发给handleMessage(Message msg)去执行相关操作。注意：这里post方法的run回调的执行线程和Looper.loop()的执行线程一致

那么到这里，Handler消息机制的源码分析的分享也就大体完成了，写这篇文章的主要目的是希望对初次接触handler机制源码无从下手的老哥提供一些分享，希望能对大家有所帮助，同时也是自己学习Handler机制的一次记录。

如有疑问欢迎大家留言指正。祝大家生活愉快。

最后欢迎对Android开发感兴趣的老哥一起讨论。