Handler的原理

在使用Handler的過程當中主要涉及到如下幾個類Looper、Handler、Message、還有一個隱藏的Message Queue，它直接與Looper交互，咱們不會直接接觸。

Handler建立

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());
            }
        }
        //關聯Looper
        mLooper = Looper.myLooper();
        if (mLooper == null) {
            throw new RuntimeException(
                "Can't create handler inside thread that has not called Looper.prepare()");
        }
        //關聯MessageQueue 同時也說明了MessageQueue 屬於Looper
        mQueue = mLooper.mQueue;
       //注意這裏的mCallback 它也是消息處理方式的一種，下文會有分析
        mCallback = callback;
        mAsynchronous = async;
    }複製代碼

上面的代碼展現了Handler如何與Looper、MessageQueue關聯，下面咱們看下Looper是如何被建立得的，以及它的MessageQueue是怎麼建立的。
Looper#myLooper

static final ThreadLocal<Looper> sThreadLocal = new ThreadLocal<Looper>();

public static @Nullable Looper myLooper() {
        return sThreadLocal.get();
    }複製代碼

能夠看到Looper 是經過ThreadLocal.get獲得的，那ThreadLocal又是什麼呢？
經過註釋咱們能夠發現，ThreadLocal是一個跟線程綁定的數據存儲類，它能夠在指定的線程中存儲數據，同時也只能在指定線程中才能獲取數據，對於其餘線程來時是無效的，既然是集合確定有set和get方法。下面咱們來看下
ThreadLocal#set

public void set(T value) {
        //獲得當前正在運行的線程
        Thread t = Thread.currentThread();
        //ThreadLocalMap 是一個自定義的hash map 用來存儲數據
        ThreadLocalMap map = getMap(t);
        if (map != null)
            map.set(this, value);
        else
            createMap(t, value);
    }複製代碼

咱們說過ThreadLocal是跟指定線程綁定的，其實從下面代碼就能看出來

ThreadLocalMap getMap(Thread t) {
        return t.threadLocals;
    }

void createMap(Thread t, T firstValue) {
        t.threadLocals = new ThreadLocalMap(this, firstValue);
    }複製代碼

代碼很簡單，我就不解釋了。
好了既然咱們知道了ThreadLocal，那接下來咱們就看下Looper。既然ThreadLocal.get()獲得的是Looper，咱們就理由相信這個Looper是跟UI線程綁定的。但是這個Looper又是在哪初始化的呢？ 並且初始化確定是經過ThreadLocal.set方式調用的。
Looper#prepare

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

private Looper(boolean quitAllowed) {
        //建立Looper的同時建立了MessageQueue
        mQueue = new MessageQueue(quitAllowed);
        mThread = Thread.currentThread();
    }複製代碼

那Looper#prepare又是在哪被調用了呢？最終咱們在ActivityThread#main函數中找到了，也就是程序啓動時調用的。
ActivityThread#main

public static void main(String[] args) {
    //............. 無關代碼...............
     此時跟UI線程綁定的Looper已經建立了
    Looper.prepareMainLooper();
    //開啓無線循環來不斷的從消息隊列中拿消息
    Looper.loop();
    throw new RuntimeException("Main thread loop unexpectedly exited");
}複製代碼

Looper#loop（省略一部分代碼）

public static void loop() {
    //得到一個跟UI線程綁定的 Looper 對象
    final Looper me = myLooper();
    // 拿到 looper 對應的 mQueue 對象
    final MessageQueue queue = me.mQueue;
    //死循環監聽(若是沒有消息變化，他不會工做的) 不斷輪訓 queue 中的 Message
    for (;;) {
        // 經過 queue 的 next 方法拿到一個 Message
        Message msg = queue.next(); // might block
        //空判斷
        if (msg == null)return;
        //消息分發   此處的target其實就是綁定的Handler
        msg.target.dispatchMessage(msg);
        //回收操做  
        msg.recycleUnchecked();
    }
}複製代碼

到這裏的時候我先你的腦子確定會閃過一個念頭進入死循環那程序不就卡死了嗎，程序還在嗎執行呢？這個問題咱們先放放，下面會簡答，這裏能夠先說結論。首先MessageQueue不是傳統的阻塞隊列，由於它沒有繼承任何隊列，同時內部也沒有持有任何阻塞隊列的對象，那它是如何實現阻塞隊列的效果的呢？其實這裏使用了linux的epoll技術，感興趣的朋友能夠深刻研究下，下次若是有時間的話我也會寫一篇相關的博文來介紹。下面是摘自百度的epoll介紹：

epoll是Linux內核爲處理大批量文件描述符而做了改進的poll，是Linux下多路複用IO接口select/poll的加強版本，它能顯著提升程序在大量併發鏈接中只有少許活躍的狀況下的系統CPU利用率。另外一點緣由就是獲取事件的時候，它無須遍歷整個被偵聽的描述符集，只要遍歷那些被內核IO事件異步喚醒而加入Ready隊列的描述符集合就好了。epoll除了提供select/poll那種IO事件的水平觸發（Level Triggered）外，還提供了邊緣觸發（Edge Triggered），這就使得用戶空間程序有可能緩存IO狀態，減小epoll_wait/epoll_pwait的調用，提升應用程序效率

Handler建立的另外一種姿式
上文咱們分析了在UI線程（主線程）中建立的Handler，並會獲得一個UI Looper，那假如咱們新建一個線程並在其中建立Handler會發生什麼？

public class LooperThread extends Thread {
    private Handler handler1;
    private Handler handler2;
    @Override
    public void run() {
        // 將當前線程初始化爲Looper線程
        Looper.prepare();
        // 實例化兩個handler
        handler1 = new Handler();
        handler2 = new Handler();
        // 開始循環處理消息隊列
        Looper.loop();
    }
}複製代碼

在子線程中咱們能夠建立多個Handler，可是必須手動調用Looper.prepare();和Looper.loop();並且Looper.prepare()必須在Handler建立以前，這是爲何呢？咱們回到上文中的代碼。由於在建立Handler的時候會檢查mLooper 是否爲null，爲null會拋出異常,而且此處的Looper是跟當前線程綁定的。

public Handler(Callback callback, boolean async) {
        //關聯Looper
        mLooper = Looper.myLooper();
        if (mLooper == null) {
            throw new RuntimeException(
                "Can't create handler inside thread that has not called Looper.prepare()");
        }
    }複製代碼

要保證mLooper 不爲null，必需要先調用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));
    }複製代碼

在建立完Handler以後還須要手動調用Looper.loop()開啓消息循環隊列。

階段總結
好了到這，咱們已經分析完Handler以及Looper和MessageQueue的建立和關聯，而且還知道，建立完Looper和MessageQueue以後會進入一個死循環一直等待消息的到來並拿出消息進行分發處理，不然會一直阻塞，其中這裏的阻塞隊列利用了linux的epoll技術。另外，咱們還知道一個線程能夠有多個Handler，可是隻能有一個Looper！

Handler發送消息

有了handler以後，咱們就可使用 post(Runnable), postAtTime(Runnable, long), postDelayed(Runnable, long), sendEmptyMessage(int), sendMessage(Message), sendMessageAtTime(Message, long)和 sendMessageDelayed(Message, long)這些方法向MQ上發送消息了。從上面這些方法你可能會覺得咱們能夠發送2中消息類型：Message和Runnable，但其實發出的Runnable最終也會被封裝成Message，下面咱們來看代碼：
Handler#xxx

public final boolean post(Runnable r)
    {
       return  sendMessageDelayed(getPostMessage(r), 0);
    }

private static Message getPostMessage(Runnable r) {
        Message m = Message.obtain();
        m.callback = r;
        return m;
    }


public final boolean sendMessage(Message msg)
    {
        return sendMessageDelayed(msg, 0);
    }

 public final boolean sendMessageDelayed(Message msg, long delayMillis)
    {
        if (delayMillis < 0) {
            delayMillis = 0;
        }
        return sendMessageAtTime(msg, SystemClock.uptimeMillis() + delayMillis);
    }

 public boolean sendMessageAtTime(Message msg, long uptimeMillis) {
        //獲得消息隊列
        MessageQueue queue = mQueue;
        if (queue == null) {
            RuntimeException e = new RuntimeException(
                    this + " sendMessageAtTime() called with no mQueue");
            Log.w("Looper", e.getMessage(), e);
            return false;
        }
        return enqueueMessage(queue, msg, uptimeMillis);
    }複製代碼

能夠看到無論經過哪一種方法發送消息，最終都會進入到sendMessageAtTime方法，並執行enqueueMessage入隊操做。
Handler#enqueueMessage

private boolean enqueueMessage(MessageQueue queue, Message msg, long uptimeMillis) {
        //注意看這行代碼 咱們將Handler賦值給Message的target 
        msg.target = this;
        if (mAsynchronous) {
            msg.setAsynchronous(true);
        }
        return queue.enqueueMessage(msg, uptimeMillis);
    }複製代碼

階段總結
經過上面的代碼獲得一條原則就是：消息發送和處理遵循『誰發送，誰處理』的原則。過程仍是比較簡單的，下面有2點要注意的地方：

1. 咱們發送的2中類型消息最終都會被封裝成Message對象進行發送
2. 在建立完消息以後咱們會將Message和Handler經過msg.target = this進行綁定，方便下面進行處理。

Handler處理消息

Looper#loop

public static void loop() {
    //得到一個 Looper 對象
    final Looper me = myLooper();
    // 拿到 looper 對應的 mQueue 對象
    final MessageQueue queue = me.mQueue;
    //死循環監聽(若是沒有消息變化，他不會工做的) 不斷輪訓 queue 中的 Message
    for (;;) {
        // 經過 queue 的 next 方法拿到一個 Message
        Message msg = queue.next(); // might block
        //空判斷
        if (msg == null)return;
        //消息分發   
        msg.target.dispatchMessage(msg);
        //回收操做  
        msg.recycleUnchecked();
    }
}複製代碼

MessageQueue的工做方式是當有消息被放入的時候MessageQueue.next()會返回Message對象，不然就會阻塞在這，拿到消息之後會調用Message綁定的Handler來出來消息，而後回回收消息。下面讓咱們看下消息是如何被處理。
Handler#dispatchMessage

public void dispatchMessage(Message msg) {
      //callback對應Runnable對象 
        if (msg.callback != null) {
            handleCallback(msg);
        } else {
            if (mCallback != null) {
                if (mCallback.handleMessage(msg)) {
                    return;
                }
            }
            handleMessage(msg);
        }
    }

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

 public void handleMessage(Message msg) {
    }複製代碼

能夠看到，消息處理分紅了2中方式，一種是咱們傳遞的Runnable對象，另外一種是普通的Message對象。代碼很簡單，handleCallback直接調用了Runnable.run,而handleMessage是空實現，須要咱們重寫而且實現它。還有一種處理方式就是mCallback，是在建立Handler的時候經過都找參數傳入的，你們回去最上面經過註釋能夠看到。

階段總結
經過上面獲得代碼，咱們瞭解到在處理消息的時候有三種方式，而且是有順序的。

1. 若是有Runnable消息就直接處理Runnable消息，而後忽略其餘消息，因此Runnable的優先級是最高的。
2. 沒有Runnable消息，查找時候有經過構造函數傳入的Callback對象，有就處理並檢查時候處理成功，成功就直接returan，不然才調用最普通的Message對象處理。
3. 普通Message的優先級是最低的，而且須要咱們本身來實現handleMessage方法。
4. 從上面的代碼中咱們也驗證了Handler誰發送就誰處理的原則，實現方式是經過將Handler賦值給Message.target來實現的。

epoll的真相

到此關於Handler的建立、消息發送以及消息處理都分析完畢了。如今還剩下那個死循環的問題一直困擾着咱們，那就是linux底層epoll究竟是如何處理消息的呢。原本這段代碼想本身分析的，但在查找資料的時候發現已經有好多人分析過了，而且分析的比較透徹，其中MessageQueue涉及到不少native方法，我這裏就不分析，下面放上2篇分析的比較好的博文供你們本身來參考。
深刻理解 MessageQueue
Looper 中的 loop() 方法是如何實現阻塞的