Android線程間異步通訊機制源碼分析

        本文首先從總體架構分析了Android整個線程間消息傳遞機制，而後從源碼角度介紹了各個組件的做用和完成的任務。文中並未對基礎概念進行介紹，關於threadLacal和垃圾回收等等機制請自行研究。

基礎架構

        首先，咱們須要從總體架構上了解一下Android線程通訊都作了哪些工做。咱們都知道，進程是操做系統分配資源的最小單位，一個進程中能夠啓動多個線程來執行任務，這些線程能夠共享進程的資源但不分配資源，這裏講的資源主要是隻內存資源。Android的線程間消息傳遞機制其實和咱們現實生活人們通訊中很類似，咱們能夠類比一下兩我的的通訊過程：假設A要給B寫信，首先將信寫好裝入信封（Message），交給B的郵遞員（handler）投入B的信箱（messageQueue）中，B的管家（looper）發現有信件須要查收，就交給B來處理。下圖是其他線程向主線程發送消息的示意圖：

    整個過程以下：

1. 子線程經過主線程的handler發送一條消息給主線程；
2. 這條線程被放入主線程的消息隊列中；
3. 整個消息隊列是由looper來建立和管理的，經過輪詢一旦發現有新消息存在就取出交給主線程處理。

組件源碼分析

        瞭解過整個架構以後，咱們就從源碼的角度體會一下Android線程之間通訊機制的精妙設計吧。

信封message

        Message類做爲發送給handler的消息，其中封裝了一份對於消息的描述以及須要傳遞的數據對象。關於消息回收機制咱們放在後面的文章中介紹，這裏先只把它看成封裝了要傳遞數據的消息類。首先，兩個int成員變量和一個obj對象用於存儲被傳遞的數據：

• what： 用戶自定義的消息碼，用於消息接收者識別該消息的類型。
• arg一、arg2： 若是隻傳遞int值，能夠採用這兩個參數存儲。
• obj ： 能夠存放須要傳遞的數據對象。

        還有一些成員變量也須要簡單瞭解一下：

• int flags ： 該消息是否正在被取用
• long when ： 時間戳
• Bundle data ： 要傳遞的數據
• Handler target ： 指定處理該消息的目標handler.
• Runnable callback ：也能夠指定處理該消息的回調函數
• message next： 指向下一個message，後面介紹messageQueue時再詳細介紹。

 

        經過obtain方法能夠獲取一條message對象使用（工廠模式）：

public static Message obtain() {
        synchronized (sPoolSync) {
            if (sPool != null) {
                Message m = sPool;
                sPool = m.next;
                m.next = null;
                m.flags = 0; // clear in-use flag
                sPoolSize--;
                return m;
            }
        }
        return new Message();
    }

        還有一些關於成員變量的存取方法，就不一一介紹了，咱們使用的時候只須要獲取到message對象，將要傳遞的數據放入該對象中就OK了。而後咱們須要調用sendToTarget方法把這個消息發送出去：

/**
     * Sends this Message to the Handler specified by {@link #getTarget}.
     * Throws a null pointer exception if this field has not been set.
     */
    public void sendToTarget() {
        target.sendMessage(this);
    }

        固然，你要指明要把該消息交給哪一個handler來處理，否則會報空指針喲。方法中調用了handler的sendMessage方法，下面咱們來研究一下handler。

郵遞員handler

        handler其實並不只僅像是傳統意義上的郵遞員而已，由於handler既負責在子線程中發送消息到主線程的messageQueue中，又負責在主線程中從looper中取出消息進行處理，你見過有這麼周到的郵遞員嗎？一個handler實例只爲一個線程以及其消息隊列服務，當你在某個線程中建立一個handler實例對象，那麼該handler對象就與該線程和它的消息隊列綁定在一塊兒，並開始爲它們進行服務了。另外須要提到的一點是，這裏的消息並不只僅是指數據，也能夠是能被主線程執行的Runnable對象。

        當應用程序的進程建立後，它的主線程維護了一個消息隊列用於管理那些頂層的應用組件（activity，broadcast receiver等）以及建立出來的窗口。而你本身開啓的線程能夠經過handler與主線程通訊，在合適的時候執行任務，或者處理消息等等。

        首先，咱們看看如何建立一個handler，構造方法以下：

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();// 獲取到當前線程的looper
        if (mLooper == null) {
            throw new RuntimeException(
                "Can't create handler inside thread that has not called Looper.prepare()");
        }
       mQueue = mLooper.mQueue;// 獲取到looper管理的消息隊列
        mCallback = callback;// 自定義的回調函數
        mAsynchronous = async;
    }

        其中有關內存泄露問題咱們稍後再談。先關注一下咱們的handler在建立時作了哪些工做。在談論整個通訊機制的時候咱們說過，一個線程只能有一個looper用來輪詢惟一的一個消息隊列，即線程，looper，消息的隊列的關係是一一對應的。而handler和looper之間是一對多的關係，即一個looper能夠由多個handler來爲它服務。在handler的構造函數中，主要工做就是把handler和它要服務的looper，消息隊列關聯起來。

        handler能夠向隊列中發送消息或者添加一個可執行的runnable對象，消息隊列會安排在某一時刻進行消息處理或者執行runnable對象run方法：

• post(Runnable r)：將runnable對象加入消息隊列，該runnable對象將會被消息隊列所在線程執行。
• postAtTime(Runnable, long)： 將runnable對象加入消息隊列，在指定的時間執行該runnable對象。
• postDelayed(Runnable r, long delayMillis)：將runnable對象加入消息隊列，通過指定延遲時間後執行。
• sendEmptyMessage(int what)：將一條僅包含what值的消息發送給消息隊列
• sendMessage(Message msg)：將一條消息加入消息隊列
• sendMessageAtTime(Message msg, long uptimeMillis)：在指定時間將一條消息加入隊列尾部
• sendMessageDelayed(Message msg, long delayMillis)： 在通過指定時間延遲後，將一條消息加入隊列尾部
  

        經過這些方法，handler將message對象交給了消息隊列messageQueue。looper從消息隊列中取出message後，會調用message所持有的handlerdispatch方法，分發給handler來處理該消息：

public void dispatchMessage(Message msg) {
        if (msg.callback != null) {// 若是message對象持有回調對象，則執行它
            handleCallback(msg);
        } else {
            if (mCallback != null) {// 若是當前handler持有消息處理的回調函數，則執行它
                if (mCallback.handleMessage(msg)) {
                    return;
                }
            }
            handleMessage(msg);// 若是都沒有，則執行用戶自定義的消息處理方法
        }
    }

 

管家Looper和信箱MessageQueue

        從上面的分析咱們能夠了解，message對象是經過handler間接的加入到消息隊列中的，而後消息隊列將message對象組織成一個隊列提供給looper分發。若是隻看名字，咱們會猜測這個類中使用隊列這種數據結構來組織message，然而並非這樣的。MessageQueue將message對象按時間順序組織成一個鏈表的形式來管理。

        在建立handler對象的時候，咱們經過looper.myLooper方法從threadLocal中獲取到與當前線程一一對應的looper對象。那麼當前線程是什麼時候建立了整個looper對象並將其放入threadLocal呢？在Android的UI線程中，早已自動替咱們建立好了looper；而若是是咱們本身建立的線程，那麼就須要調用prepare方法來建立出looper對象：

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對象的時候也建立了它要輪詢的消息隊列，並獲取了當前線程的引用：

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

        因爲線程和looper對象是一一對應的關係，因此咱們有時候判斷當前線程是否爲UI線程的時候，會調用getMainLooper方法來判斷：

public static Looper getMainLooper() {
        synchronized (Looper.class) {
            return sMainLooper;
        }
}

        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，有可能會阻塞

            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);
            }
 // 把從隊列中取到的message交給handler來處理
            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();
        }
    }

到此爲止，在子線程中建立的message對象就被處理好了。下面咱們須要談論一下handler的泄露問題以及解決方法。

Handler泄露問題

        談論整個問題以前，咱們須要瞭解JAVA的GC機制，這裏就不作詳細介紹了。當咱們在activity中建立一個handler對象時，每每會繼承一個匿名內部類，裏面複寫了handler的handleMessage方法。這時，該匿名內部類就會持有當前activity的對象引用。同時，持有該handler的子線程對象每每會進行一些耗時的操做，建立message對象並把handler對象的引用賦給它。此時若是用戶關閉了activity，那麼此activity對象是應該被系統回收的。可是，因爲子線程的耗時操做，而且它和未處理的message對象都持有handler的引用，而handler又持有activity的引用，這就會致使該activity沒法回收，出現內存泄露。

        目前主要有兩種解決方案：

• 第一種，在activity關閉時，停掉該子線程，而後調用handler的removeCallbacks方法，把消息隊列中的message刪除掉。
• 第二種，讓匿名內部類做爲一個靜態內部類出現，這樣就不持有activity的對象引用了，activity就能夠被回收掉了。可是，不持有activity的引用，怎麼操做其中的對象呢？只好本身聲明一個弱引用了：

static class myHandler extends Handler {
    WeakReference<Activity > mActivityReference;

    myHandler(Activity activity) {
        mActivityReference= new WeakReference<Activity>(activity);
    }

    @Override
    public void handleMessage(Message msg) {
    //消息處理......
    }
}

        弱引用在垃圾回收的時候會被忽略，因此能夠被安全回收。我的比較傾向於第二種寫法，比較簡單。

總結

        本文簡單介紹了Android系統線程之間異步通訊的機制，從源碼的角度簡單談論了線程通訊時的基本工做。其中未詳細深刻到messageQueue的具體管理操做，只是簡單說起了message對象的回收，具體細節有空再補上。