歡迎來到Linux教程網
Linux教程網
Linux教程網
Linux教程網
您现在的位置: Linux教程網 >> UnixLinux >  >> Linux編程 >> Linux編程

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

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

基礎架構

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

整個過程如下:

子線程通過主線程的handler發送一條消息給主線程;

這條線程被放入主線程的消息隊列中;

整個消息隊列是由looper來創建和管理的,通過輪詢一旦發現有新消息存在就取出交給主線程處理。

組件源碼分析

了解過整個架構之後,我們就從源碼的角度體會一下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來處理,不然會報空指針喲。方法中調用了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對象的回收,具體細節有空再補上。

更多Android相關信息見Android 專題頁面 http://www.linuxidc.com/topicnews.aspx?tid=11

Copyright © Linux教程網 All Rights Reserved