Android線程間非同步通訊機制源碼分析，android源碼

Android線程間非同步通訊機制源碼分析，android源碼

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

基礎架構

        首先，我們需要從整體架構上瞭解一下Android線程通訊都做了哪些工作。我們都知道，進程是作業系統分配資源的最小單位，一個進程中可以啟動多個線程來執行任務，這些線程可以共用進程的資源但不分配資源，這裡講的資源主要是只記憶體資源。Android的線程間訊息傳遞機制其實和我們現實生活人們通訊中很相似，我們可以類比一下兩個人的通訊過程：假設A要給B寫信，首先將信寫好裝入信封（Message），交給B的郵遞員（handler）投入B的信箱（messageQueue）中，B的管家（looper）發現有信件需要查收，就交給B來處理。是其餘線程向主線程發送訊息的：

    整個過程如下：

組件源碼分析

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

信封message

        Message類作為發送給handler的訊息，其中封裝了一份對於訊息的描述以及需要傳遞的資料對象。關於訊息回收機制我們放在後面的文章中介紹，這裡先只把它當作封裝了要傳遞資料的訊息類。首先，兩個int成員變數和一個obj對象用於儲存被傳遞的資料：

• what： 使用者自訂的訊息碼，用於訊息接收者識別該訊息的類型。
• arg1、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來處理，不然會報null 指標喲。方法中調用了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對象的回收，具體細節有空再補上。