天天看點
傳回

Handler異步消息處理機制，從源代碼看起

轉載注明出處：http://blog.csdn.net/xiaohanluo/article/details/51994401

1. 簡介

       在Android開發中經常會遇見異步消息處理的情況，特别是網絡請求成功或者失敗之後需要更新UI，但是更新UI隻能在UI線程裡面進行，否則就會報錯，這個時候就需要通知UI線程去更新UI，于是Handler出現了。

2. Handler的使用

Handler的使用非常簡單，直接看例子。

private static final int KEY_REQUEST_SUCCESS = ;

    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更新操作。

看見這麼好用的異步消息處理方法，肯定會去看看内部是怎麼實作消息的排程的。

3. Handler内部資訊排程

3.1 消息進入隊列

所有的消息都是使用

sendMessage

方法發送出去(還有其他類似方法)，就從

sendMessage

開始檢視。

public final boolean sendMessage(Message msg)
    {
        return sendMessageDelayed(msg, );
    }
    ...
    public final boolean sendMessageDelayed(Message msg, long delayMillis)
    {
        if (delayMillis < ) {
            delayMillis = ;
        }
        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 ==  || 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;
    }

從代碼中很清晰的可以看見。

  • 如果新消息首次加入隊列，或者新消息延遲時間要小于隊列首個消息延遲時間，就将新消息放在隊列首部。
  • 如果隊列不為空，新消息延遲時間并不是最短，就将新消息插入到隊列的某個位置。

       總之，新消息插入隊列後，消息隊列是按延遲時間長短排序的一個有序隊列，延遲時間越短，越靠近隊列首部。這樣，就可以猜測，系統一次拿去隊列中的消息，然後進行分發處理。

3.2 消息排程分發

       我們都知道了消息被加入了一個按延遲長短排序的有序隊列，消息僅僅加入了隊列還需要有地方處理才行，那我們就看看哪裡處理了這個隊列。

首先我們來檢視一下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！！！趕緊去檢視一下消息分發和處理過程吧。

3.3 消息處理

直接去檢視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時候複寫的一個方法，最終消息的具體處理過程就回到了我們手中。

4. 排程圖

Handler異步消息處理機制，從源代碼看起

       Handler發送Message消息，消息進入消息隊列，Looper不斷的從消息隊列中取出Message，然後交給Handler處理，處理的代碼交給使用者處理。這樣我們就可以在非UI線程中發送Message消息，但是最終的處理回到了UI線程，進行一些UI操作。

5. 其他用法

       雖然Handler是用于處理異步消息的，但是由于它本身有一個延遲的功能，是以Handler也可以做一個定時任務處理器，類似廣告結束倒計時等等都可以用到Handler。

6. 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 = ;
        arg1 = ;
        arg2 = ;
        obj = null;
        replyTo = null;
        sendingUid = -;
        when = ;
        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的話，這裡面有坑，慎重。

7. 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)

時候，會清空消息隊列中所有資訊。

待完善…
【Android學習】 android 源代碼 異步 android開發 Handler
上一篇: Java知識複習（前篇）内置資料類型包裝類型–引用資料類型（含相應内置資料類型）String參數傳遞類型轉換switch關鍵字
下一篇: android Handler 消息機制

繼續閱讀