Android多線程分析之三：Handler，Looper的實現

Android多線程分析之三：Handler，Looper的實現

羅朝輝 (http://blog.csdn.net/kesalin)CC 許可，轉載請注明出處

在前文《Android多線程分析之二：Thread的實現》中已經詳細分析了Android Thread 是如何創建，運行以及銷毀的，其重點是對相應 native 方法進行分析，今天我將聚焦於 Android Framework 層多線程相關的類：Handler, Looper, MessageQueue, Message 以及它們與Thread 之間的關系。可以用一個不太妥當的比喻來形容它們之間的關聯：如果把 Thread 比作生產車間，那麼 Looper 就是放在這車間裡的生產線，這條生產線源源不斷地從 MessageQueue 中獲取材料 Messsage，並分發處理 Message (由於Message 通常是完備的，所以 Looper 大多數情況下只是調度讓 Message 的 Handler 去處理 Message)。正是因為消息需要在 Looper 中處理，而 Looper 又需運行在 Thread 中，所以不能隨隨便便在非 UI 線程中進行 UI 操作。 UI 操作通常會通過投遞消息來實現，只有往正確的 Looper 投遞消息才能得到處理，對於 UI 來說，這個 Looper 一定是運行在 UI 線程中。

在編寫 app 的過程中，我們常常會這樣來使用 Handler：

Handler mHandler = new Handler();
mHandler.post(new Runnable(){
	@Override
	public void run() {
		// do somework
	}
});

或者如這系列文章第一篇中的示例那樣：

    private Handler mHandler= new Handler(){
        @Override
        public void handleMessage(Message msg) {
        	Log.i("UI thread", " >> handleMessage()");

            switch(msg.what){
            case MSG_LOAD_SUCCESS:
            	Bitmap bitmap = (Bitmap) msg.obj;
                mImageView.setImageBitmap(bitmap);

                mProgressBar.setProgress(100);
                mProgressBar.setMessage("Image downloading success!");
                mProgressBar.dismiss();
                break;

            case MSG_LOAD_FAILURE:
                mProgressBar.setMessage("Image downloading failure!");
                mProgressBar.dismiss();
            	break;
            }
        }
    };

    Message msg = mHandler.obtainMessage(MSG_LOAD_FAILURE, null);
    mHandler.sendMessage(msg);

那麼，在 Handler 的 post/sendMessage 背後到底發生了什麼事情呢？下面就來解開這個謎團。
首先我們從 Handler 的構造函數開始分析：

    final MessageQueue mQueue; 
    final Looper mLooper; 
    final Callback mCallback; 
    final boolean mAsynchronous;

    public Handler(Looper looper, Callback callback, boolean async) {
        mLooper = looper;
        mQueue = looper.mQueue;
        mCallback = callback;
        mAsynchronous = async;
    }

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

    public Handler() {
        this(null, false);
    }

上面列出了 Handler 的一些成員變量：

mLooper：線程的消息處理循環，注意：並非每一個線程都有消息處理循環，因此 Framework 中線程可以分為兩種：有 Looper 的和無 Looper 的。為了方便 app 開發，Framework 提供了一個有 Looper 的 Thread 實現：HandlerThread。在前一篇《Thread的實現》中也提到了兩種不同 Thread 的 run() 方法的區別。

/**
 * Handy class for starting a new thread that has a looper. The looper can then be 
 * used to create handler classes. Note that start() must still be called.
 */
public class HandlerThread extends Thread {
    Looper mLooper;
    /**
     * Call back method that can be explicitly overridden if needed to execute some
     * setup before Looper loops.
     */
    protected void onLooperPrepared() {
    }

    public void run() {
        mTid = Process.myTid();
        Looper.prepare();
        synchronized (this) {
            mLooper = Looper.myLooper();
            notifyAll();
        }
        Process.setThreadPriority(mPriority);
        onLooperPrepared();
        Looper.loop();
        mTid = -1;
    }

    /**
     * This method returns the Looper associated with this thread. If this thread not been started
     * or for any reason is isAlive() returns false, this method will return null. If this thread 
     * has been started, this method will block until the looper has been initialized.  
     * @return The looper.
     */
    public Looper getLooper() {
        if (!isAlive()) {
            return null;
        }

        // If the thread has been started, wait until the looper has been created.
        synchronized (this) {
            while (isAlive() && mLooper == null) {
                try {
                    wait();
                } catch (InterruptedException e) {
                }
            }
        }
        return mLooper;
    }
}

這個 HandlerThread 與 Thread 相比，多了一個類型為 Looper 成員變量 mLooper，它是在 run() 函數中由 Looper::prepare() 創建的，並保存在 TLS 中：

/** Initialize the current thread as a looper.
      * This gives you a chance to create handlers that then reference
      * this looper, before actually starting the loop. Be sure to call
      * {@link #loop()} after calling this method, and end it by calling
      * {@link #quit()}.
      */
    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::myLooper() 獲取創建的 Looper：

    /**
     * Return the Looper object associated with the current thread.  Returns
     * null if the calling thread is not associated with a Looper.
     */
    public static Looper myLooper() {
        return sThreadLocal.get();
    }

最後通過 Looper::Loop() 方法運行消息處理循環：從 MessageQueue 中取出消息，並分發處理該消息，不斷地循環這個過程。這個方法將在後面介紹。

Handler 的成員變量 mQueue 是其成員變量 mLooper 的成員變量，這裡只是為了簡化書寫，單獨拿出來作為 Handler 的成員變量；成員變量 mCallback 提供了另一種使用Handler 的簡便途徑：只需實現回調接口 Callback，而無需子類化Handler，下面會講到的：

    /**
     * Callback interface you can use when instantiating a Handler to avoid
     * having to implement your own subclass of Handler.
     */
    public interface Callback {
        public boolean handleMessage(Message msg);
    }

成員變量 mAsynchronous 是標識是否異步處理消息，如果是的話，通過該 Handler obtain 得到的消息都被強制設置為異步的。

同是否有無 Looper 來區分 Thread 一樣，Handler 的構造函數也分為自帶 Looper 和外部 Looper 兩大類：如果提供了 Looper，在消息會在該 Looper 中處理，否則消息就會在當前線程的 Looper 中處理，注意這裡要確保當前線程一定有 Looper。所有的 UI thread 都是有 Looper 的，因為 view/widget 的實現中大量使用了消息，需要 UI thread 提供 Looper 來處理，可以參考view.java：

view.java

    public boolean post(Runnable action) {
        final AttachInfo attachInfo = mAttachInfo;
        if (attachInfo != null) {
            return attachInfo.mHandler.post(action);
        }
        // Assume that post will succeed later
        ViewRootImpl.getRunQueue().post(action);
        return true;
    }

ViewRootImpl.java

    private void performTraversals() {
        ....
        // Execute enqueued actions on every traversal in case a detached view enqueued an action
        getRunQueue().executeActions(attachInfo.mHandler);
      ...
    }

    static RunQueue getRunQueue() {
        RunQueue rq = sRunQueues.get();
        if (rq != null) {
            return rq;
        }
        rq = new RunQueue();
        sRunQueues.set(rq);
        return rq;
    }

    /**
     * The run queue is used to enqueue pending work from Views when no Handler is
     * attached.  The work is executed during the next call to performTraversals on
     * the thread.
     * @hide
     */
    static final class RunQueue {
    ...
        void executeActions(Handler handler) {
            synchronized (mActions) {
                final ArrayList actions = mActions;
                final int count = actions.size();

                for (int i = 0; i < count; i++) {
                    final HandlerAction handlerAction = actions.get(i);
                    handler.postDelayed(handlerAction.action, handlerAction.delay);
                }

                actions.clear();
            }
        }
    }

從上面的代碼可以看出，作為所有控件基類的 view 提供了 post 方法，用於向 UI Thread 發送消息，並在 UI Thread 的 Looper 中處理這些消息，而 UI Thread 一定有 Looper 這是由 ActivityThread 來保證的：

public final class ActivityThread {
...
    final Looper mLooper = Looper.myLooper();
}

UI 操作需要向 UI 線程發送消息並在其 Looper 中處理這些消息。這就是為什麼我們不能在非 UI 線程中更新 UI 的原因，在控件在非 UI 線程中構造 Handler 時，要麼由於非 UI 線程沒有 Looper 使得獲取 myLooper 失敗而拋出 RunTimeException，要麼即便提供了 Looper，但這個 Looper 並非 UI 線程的 Looper 而不能處理控件消息。為此在 ViewRootImpl 中有一個強制檢測 UI 操作是否是在 UI 線程中處理的方法 checkThread()：該方法中的 mThread 是在 ViewRootImpl 的構造函數中賦值的，它就是 UI 線程；該方法中的 Thread.currentThread() 是當前進行 UI 操作的線程，如果這個線程不是非 UI 線程就會拋出異常CalledFromWrongThreadException。

    void checkThread() {
        if (mThread != Thread.currentThread()) {
            throw new CalledFromWrongThreadException(
                    "Only the original thread that created a view hierarchy can touch its views.");
        }
    }

如果修改《使用Thread異步下載圖像》中示例，下載完圖像 bitmap 之後，在 Thread 的 run() 函數中設置 ImageView 的圖像為該 bitmap，即會拋出上面提到的異常：

W/dalvikvm(796): threadid=11: thread exiting with uncaught exception (group=0x40a71930)
E/AndroidRuntime(796): FATAL EXCEPTION: Thread-75
E/AndroidRuntime(796): android.view.ViewRootImpl$CalledFromWrongThreadException: Only the original thread that created a view hierarchy can touch its views.
E/AndroidRuntime(796): 	at android.view.ViewRootImpl.checkThread(ViewRootImpl.java:4746)
E/AndroidRuntime(796): 	at android.view.ViewRootImpl.requestLayout(ViewRootImpl.java:823)
E/AndroidRuntime(796): 	at android.view.View.requestLayout(View.java:15473)
E/AndroidRuntime(796): 	at android.view.View.requestLayout(View.java:15473)
E/AndroidRuntime(796): 	at android.view.View.requestLayout(View.java:15473)
E/AndroidRuntime(796): 	at android.view.View.requestLayout(View.java:15473)
E/AndroidRuntime(796): 	at android.view.View.requestLayout(View.java:15473)
E/AndroidRuntime(796): 	at android.widget.ImageView.setImageDrawable(ImageView.java:406)
E/AndroidRuntime(796): 	at android.widget.ImageView.setImageBitmap(ImageView.java:421)
E/AndroidRuntime(796): 	at com.example.thread01.MainActivity$2$1.run(MainActivity.java:80)

Handler 的構造函數暫且介紹到這裡，接下來介紹：handleMessage 和 dispatchMessage：

/**
     * Subclasses must implement this to receive messages.
     */
    public void handleMessage(Message msg) {
    }

    /**
     * Handle system messages here.
     */
    public void dispatchMessage(Message msg) {
        if (msg.callback != null) {
            handleCallback(msg);
        } else {
            if (mCallback != null) {
                if (mCallback.handleMessage(msg)) {
                    return;
                }
            }
            handleMessage(msg);
        }
    }

前面提到有兩種方式來設置處理消息的代碼：一種是設置 Callback 回調，一種是子類化 Handler。而子類化 Handler 其子類就要實現 handleMessage 來處理自定義的消息，如前面的匿名子類示例一樣。dispatchMessage 是在 Looper::Loop() 中被調用，即它是在線程的消息處理循環中被調用，這樣就能讓 Handler 不斷地處理各種消息。在 dispatchMessage 的實現中可以看到，如果 Message 有自己的消息處理回調，那麼就優先調用消息自己的消息處理回調：

    private static void handleCallback(Message message) {
        message.callback.run();
    }

否則看Handler 是否有消息處理回調 mCallback，如果有且 mCallback 成功處理了這個消息就返回了，否則就調用 handleMessage（通常是子類的實現） 來處理消息。

在分析 Looper::Loop() 這個關鍵函數之前，先來理一理 Thread，Looper，Handler，MessageQueue 的關系：Thread 需要有 Looper 才能處理消息（也就是說 Looper 是運行在 Thread 中），這是通過在自定義 Thread 的 run() 函數中調用 Looper::prepare() 和 Looper::loop() 來實現，然後在 Looper::loop() 中不斷地從 MessageQueue 獲取由 Handler 投遞到其中的 Message，並調用 Message 的成員變量 Handler 的 dispatchMessage 來處理消息。

下面先來看看 Looper 的構造函數：

    final MessageQueue mQueue;
    final Thread mThread;
    volatile boolean mRun;

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

Looper 的構造函數很簡單，創建MessageQueue，保存當前線程到 mThread 中。但它是私有的，只能通過兩個靜態函數 prepare()/prepareMainLooper() 來調用，前面已經介紹了 prepare(),下面來介紹 prepareMainLooper():

/**
     * Initialize the current thread as a looper, marking it as an
     * application's main looper. The main looper for your application
     * is created by the Android environment, so you should never need
     * to call this function yourself.  See also: {@link #prepare()}
     */
    public static void prepareMainLooper() {
        prepare(false);
        synchronized (Looper.class) {
            if (sMainLooper != null) {
                throw new IllegalStateException("The main Looper has already been prepared.");
            }
            sMainLooper = myLooper();
        }
    }

prepareMainLooper 是通過調用 prepare 實現的，不過傳入的參數為 false，表示 main Looper 不允許中途被中止，創建之後將looper 保持在靜態變量 sMainLooper 中。整個 Framework 框架只有兩個地方調用了 prepareMainLooper 方法：

SystemServer.java 中的 ServerThread，ServerThread 的重要性就不用說了，絕大部分 Android Service 都是這個線程中初始化的。這個線程是在 Android 啟動過程中的 init2() 方法啟動的：

public static final void init2() {
        Slog.i(TAG, "Entered the Android system server!");
        Thread thr = new ServerThread();
        thr.setName("android.server.ServerThread");
        thr.start();
    }
class ServerThread extends Thread {
    @Override
    public void run() {
        ...
        Looper.prepareMainLooper();
        ...
        Looper.loop();
        Slog.d(TAG, "System ServerThread is exiting!");
    }
}

以及 ActivityThread.java 的 main() 方法：

public static void main(String[] args) {
        ....
        Looper.prepareMainLooper();

        ActivityThread thread = new ActivityThread();
        thread.attach(false);

        if (sMainThreadHandler == null) {
            sMainThreadHandler = thread.getHandler();
        }

        AsyncTask.init();

        Looper.loop();

        throw new RuntimeException("Main thread loop unexpectedly exited");
    }

ActivityThread 的重要性也不言而喻，它是 Activity 的主線程，也就是 UI 線程。注意這裡的 AsyncTask.init() ，在後面介紹 AsyncTask 時會詳細介紹的，這裡只提一下：AsyncTask 能夠進行 UI 操作正是由於在這裡調用了 init()。

有了前面的鋪墊，這下我們就可以來分析 Looper::Loop() 這個關鍵函數了：

/**
     * Run the message queue in this thread. Be sure to call
     * {@link #quit()} to end the 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;
        ...
        for (;;) {
            Message msg = queue.next(); // might block
            if (msg == null) {
                // No message indicates that the message queue is quitting.
                return;
            }

            msg.target.dispatchMessage(msg);

            msg.recycle();
        }
    }

loop() 的實現非常簡單，一如前面一再說過的那樣：不斷地從 MessageQueue 中獲取消息，分發消息，回收消息。從上面的代碼可以看出，loop() 僅僅是一個不斷循環作業的生產流水線，而 MessageQueue 則為它提供原材料 Message，讓它去分發處理。至於 Handler 是怎麼提交消息到 MessageQueue 中，MessageQueue 又是怎麼管理消息的，且待下文分解。