Handler异步消息处理机制，从源代码看起

转载注明出处：http://blog.csdn.net/xiaohanluo/article/details/51994401
简书链接：http://www.jianshu.com/p/e72aba99012a

简介

在Android开发中经常会遇见异步消息处理的情况，特别是网络请求成功或者失败之后需要更新UI，但是更新UI只能在UI线程里面进行，否则就会报错，这个时候就需要通知UI线程去更新UI，于是Handler出现了。

Handler的使用

Handler的使用非常简单，直接看例子。

    private static final int KEY_REQUEST_SUCCESS = 0x01;

    private Handler mHandler = new Handler() {
        @Override
        public void handleMessage(Message msg) {
              //这里是在UI线程了
            if(msg.what == KEY_REQUEST_SUCCESS) {
                //更改UI
            }
        }
    };

    ... ...//一些其他操作

    private void changeUI() {
        Message message = mHandler.obtainMessage();
        message.what = KEY_REQUEST_SUCCESS;

        mHandler.sendMessage(message);
    }

声明了一个Handler成员变量mHandler，并复写了其中的handleMessage(Message msg)方法，然后使用mHandler发送一条消息，最终会调用到handleMessage方法，然后进行UI更新操作。

看见这么好用的异步消息处理方法，肯定会去看看内部是怎么实现消息的调度的。

Handler内部信息调度

消息进入队列

所有的消息都是使用sendMessage方法发送出去(还有其他类似方法)，就从sendMessage开始查看。

    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) {
            //异常处理
        }
        return 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);
    }

我们可以看到，Handler发送消息最终都会调用到sendMessageAtTime方法，在这个方法里面就做了一件事，将消息放入一个消息队列中。记住msg.target这个赋值操作，然后我们去看看在放入队列时候都做了些什么。

    boolean enqueueMessage(Message msg, long when) {
        //异常处理
        synchronized (this) {
            //异常处理

            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 {
                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;
                prev.next = msg;
            }

            if (needWake) {
                nativeWake(mPtr);
            }
        }
        return true;
    }

从代码中很清晰的可以看见。

• 如果新消息首次加入队列，或者新消息延迟时间要小于队列首个消息延迟时间，就将新消息放在队列首部。
• 如果队列不为空，新消息延迟时间并不是最短，就将新消息插入到队列的某个位置。

总之，新消息插入队列后，消息队列是按延迟时间长短排序的一个有序队列，延迟时间越短，越靠近队列首部。这样，就可以猜测，系统一次拿去队列中的消息，然后进行分发处理。

消息调度分发

我们都知道了消息被加入了一个按延迟长短排序的有序队列，消息仅仅加入了队列还需要有地方处理才行，那我们就看看哪里处理了这个队列。
首先我们来查看一下Handler的成员变量中的MessageQueue是在哪里初始化或者赋值的，从源头开始查找，顺藤摸瓜。

    public Handler() {
        this(null, false);
    }
    ...
    public Handler(Callback callback, boolean async) {
        ...
        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;
    }

原来是直接用Looper赋值的，那会不会对这个消息队列的处理就在Lopper当中呢？赶紧去看看。Looper的代码不多，很快就看到了loop()这个方法。

    public static void loop() {
        final Looper me = myLooper();

        //异常处理

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

就是在这里！！在loop()方法中有一个循环一直在取出消息队列中的消息然后进行分发工作。我们注意这一行代码msg.target.dispatchMessage(msg)，调用了msg.tartget中的一个分发消息的方法，还记得在上面消息进入消息队列时候，注意的msg.target的赋值操作吗？msg.target其实就是我们发送消息的Handler！！！赶紧去查看一下消息分发和处理过程吧。

消息处理

直接去查看Handler中的dispatchMessage(msg)方法，发现这个方法比较简单。

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

很容易理解如果Message和Handler的CallBack成员变量都为空的话，直接调用Handler本身的handlerMessage(Message msg)方法，这个方法就是我们在实例化Handler时候复写的一个方法，最终消息的具体处理过程就回到了我们手中。

调度图

Handler发送Message消息，消息进入消息队列，Looper不断的从消息队列中取出Message，然后交给Handler处理，处理的代码交给用户处理。这样我们就可以在非UI线程中发送Message消息，但是最终的处理回到了UI线程，进行一些UI操作。

其他用法

虽然Handler是用于处理异步消息的，但是由于它本身有一个延迟的功能，所以Handler也可以做一个定时任务处理器，类似广告结束倒计时等等都可以用到Handler。

Tips

Handler虽然看起来使用简单，但是如果仔细的话，会发现，这一套机制对Message的管理是非常严格的。将消息从消息队列中删除或者消息处理完毕之后，并不是直接将Message舍弃，而是调用了Message本身的recycleUnchecked()方法。

    void recycleUnchecked() {
        // Mark the message as in use while it remains in the recycled object pool.
        // Clear out all other details.
        flags = FLAG_IN_USE;
        what = 0;
        arg1 = 0;
        arg2 = 0;
        obj = null;
        replyTo = null;
        sendingUid = -1;
        when = 0;
        target = null;
        callback = null;
        data = null;

        synchronized (sPoolSync) {
            if (sPoolSize < MAX_POOL_SIZE) {
                next = sPool;
                sPool = this;
                sPoolSize++;
            }
        }
    }

首先将Message里面一些成员变量进行了重置操作，在最后面我们发现了MAX_POOL_SIZE这个属性！！这说明在这一套机制中，Message数量是有上限的。心细的人就会发现，如果每次使用Message时候都使用new实例化一个的话，总会有一个时间点，Message数量会超出最大限制数。
所以我们在获取Message的时候，一定要使用Handler.obtainMessage()方法或者Message.obtain(Handler h)方法。

如果使用new去实例化Message的话，这里面有坑，慎重。

Q&A

Looper类的loop()方法处理完队列之后就会停止循环，如果有新的消息加入，系统是怎么调用到Looper的loop()的呢？

在将信息加入到消息队列后，会运行nativeWake(mPtr)这一行代码，nativeWake()是一个本地的方法，是通过这个方法在系统的底层去调用Looper.loop()方法。

由Handler发送出一个延迟任务消息，这个消息还未被处理，怎么撤回？

Handler撤回消息有五种方法。

• removeCallbacks(Runnable r)
• removeCallbacks(Runnable r, Object object)
• removeMessages(int what)
• removeMessages(int what, Object object)
• removeCallbacksAndMessages(Object object)

但是实际上是在MessageQueue队列中删除了消息，MessageQueue提供了三种删除消息方法

• removeMessages(Handler h, int what, Object object)
• removeMessages(Handler h, Runnable r, Object object)
• removeCallBackAndMessage(Handle h, Runnable r, Object object)

参数都是Message中的成员变量(Handler参数会在Handler调用MessageQueue删除消息方法传入，也就是Handler本身)，当传入参数与Message中属性相等时候会将消息从消息队列中删除。参数object是补充条件，object传入null，则前面条件满足即可；object不为空，所有条件都需要满足。

    void removeCallbacksAndMessages(Handler h, Object object) {
        if (h == null) {
            return;
        }

        synchronized (this) {
            Message p = mMessages;

            // Remove all messages at front.
            while (p != null && p.target == h
                    && (object == null || p.obj == object)) {
                Message n = p.next;
                mMessages = n;
                p.recycleUnchecked();
                p = n;
            }

            // Remove all messages after front.
            while (p != null) {
                Message n = p.next;
                if (n != null) {
                    if (n.target == h && (object == null || n.obj == object)) {
                        Message nn = n.next;
                        n.recycleUnchecked();
                        p.next = nn;
                        continue;
                    }
                }
                p = n;
            }
        }
    }

从代码中很容易看出来，如果调用MessageQueue的removeCallbacksAndMessage方法时候，object传入是null，会将消息队列中所有消息都给清空。所以这样调用mHandler.removeCallbacksAndMessage(null)时候，会清空消息队列中所有信息。

待完善…