終於明白了Handler的運行機制

時間 2019-11-25

標籤終於明白 handler 運行機制简体版

原文原文鏈接

前言

Handler是一個Android SDK 提供給開發者方便進行異步消息處理的類。java

咱們都知道在UI線程中不能進行耗時操做，例如數據讀寫、網絡請求。Android 4.0開始，在主線程中進行網絡請求甚至會拋出Android.os.NetworkOnMainThreadException。這個時候，咱們就會開始依賴Handler。咱們在子線程進行耗時操做後，將請求結果經過Handler的sendMessge**() 方法發送出去，在主線程中經過Handler的handleMessage 方法處理請求結果，進行UI的更新。android

後來隨着AsyncTask、EventBus、Volley以及Retrofit 的出現，Handler的做用彷佛被弱化，逐漸被你們遺忘。其實否則，AsyncTask實際上是基於Handler進行了很是巧妙的封裝，Handler的使用依然是其核心。Volley一樣也是使用到了Handler。所以，咱們有必要了解一下Handler的實現機制。網絡

神奇的Handler

記得好久以前的一天，我在閱讀別人的代碼時，看到了這樣一段：多線程

new Handler().postDelayed(new Runnable() {
            @Override
            public void run() {
                Toast.makeText(mContext, "I'm new Handler !", Toast.LENGTH_SHORT).show();
            }
        }, 1000);
複製代碼

第一印象就是，這不是在子線程中進行UI操做嗎？這代碼有問題吧，因而乎馬上在本身電腦上寫了個demo試了一下，結果發現真的沒有問題。在一陣懵逼事後，我又寫出下面的代碼，測試一會兒線程中到底能不能進行UI操做。併發

new Thread(new Runnable() {
            @Override
            public void run() {
                
                try {
                    Thread.sleep(2000);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }

                Toast.makeText(mContext, "I'm new Thread !", Toast.LENGTH_SHORT).show();

            }
        }).start();
複製代碼

結果很明顯，程序一啓動馬上就奔潰了。並拋出異常java.lang.RuntimeException: Can't create handler inside thread that has not called Looper.prepare()。因而乎我又在try block 以前添加了Looper.prepare()這行代碼。再次運行程序雖然沒有奔潰，但也沒有任何反應，Toast也沒顯示。app

那麼Handler究竟是什麼呢？他怎麼就這麼神奇。less

實現機制解析

首先，咱們從總體上了解一下，在整個Handler機制中全部使用到的類，主要包括Message，MessageQueue,Looper以及Handler。異步

好了，爲了方便後面的敘述，咱們就首先了解一下這個類圖中使用到幾個類，及其關鍵方法。async

Message

首先看一下Message這個類的定義（截取部分）ide

public final class Message implements Parcelable {

    public int what;
    public int arg1; 
    public int arg2;
    public Object obj;
    /*package*/ Handler target;
    /*package*/ Runnable callback;
    
    /** * Return a new Message instance from the global pool. Allows us to * avoid allocating new objects in many cases. */
    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();
    }
    
    /** Constructor (but the preferred way to get a Message is to call {@link #obtain() Message.obtain()}). */
    public Message() {
    }
}
複製代碼

看到這個類的前四個屬性，你們應該很熟悉，就是咱們使用Handler時常常用到的那幾個屬性。用來在傳遞咱們特定的信息。其次咱們還能夠總結出如下信息：

Message 實現了Parcelable 接口，也就是說實現了序列化，這就說明Message能夠在不一樣進程之間傳遞。
包含一個名爲target的Handler 對象
包含一個名爲callback的Runnable 對象
使用obtain 方法能夠從消息池中獲取Message的實例，也是推薦你們使用的方法，而不是直接調用構造方法。

MessageQueue

MessageQueue顧名思義，就是上面所說的Message所組成的queue。

首先看一下構造方法：

MessageQueue(boolean quitAllowed) {
        mQuitAllowed = quitAllowed;
        mPtr = nativeInit();
    }
複製代碼

接收一個參數，決定當前隊列是否容許被終止。同時調用一個native方法，初始化了一個long類型的變量mPtr。

同時，在這個類當中，還定義了一個next 方法，用於返回一個Message 。

Message next() {
        // Return here if the message loop has already quit and been disposed.
        // This can happen if the application tries to restart a looper after quit
        // which is not supported.
        final long ptr = mPtr;
        if (ptr == 0) {
            return null;
        }
	……
    }
複製代碼

因爲這個方法中有一些native調用，未能徹底理解，只知道會返回一個Message對象。

這個next方法至關因而隊列出棧，有出棧必然有進棧，enqueueMessage 方法就是完成這個操做；這個咱們後面再說。

Looper

上面說到了MessageQueue，那麼這個Queue又是由誰建立的呢？其實就是Looper。關於Looper有兩個關鍵方法：

prepare() 和 loop()

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));
    }
複製代碼

能夠看到，對於每個線程只能有一個Looper。也就是說執行prepare方法時，必然執行最後一行代碼 sThreadLocal.set(new Looper(quitAllowed));

咱們再看Looper(quitAllowed)方法：

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

這樣，MessageQueue 就被建立了。這裏也能夠看到，默認狀況下，一個MessageQueue的quiteAllow=true。

這裏使用到的sThreadLocal 是一個ThreadLocal對象。簡單來講，使用它能夠用來解決多線程程序的併發問題。使用set方法，將此線程局部變量的當前線程副本中的值設置爲指定值；使用get方法，返回此線程局部變量的當前線程副本中的值。

Looper-loop()

再看一下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.recycleUnchecked();
        }
    }
複製代碼

首先看第一句代碼執行的方法：

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

很明顯，這樣返回的Looper就是剛纔prepare時set進去的那個，由於都是在同一線程。再明確一下，一個線程對應一個Looper。

這樣就確保咱們能夠在不一樣的線程中建立各自的Handler，進行各自的通訊而不會互相干擾

回到代碼，後面邏輯就很簡單了，在一個死循環中，經過隊列出棧的形式，不斷從MessageQueue 中取出新的Message，而後執行msg.target.dispatchMessage(msg) 方法，還記的前面Message類的定義嗎，這個target屬性其實就是一個Handler 對象，所以在這裏就會不斷去執行Handler 的dispatchMessage 方法。若是取出的Message對象爲null，就會跳出死循環，一次Handler的工做整個就結束了。

Handler

上面說了這麼多終於輪到Handler，那麼就看看在Handler中到底發生了什麼。回到咱們一開始的代碼。

new Handler().postDelayed(new Runnable() {
            @Override
            public void run() {
                String currentName=Thread.currentThread().getName();
                Toast.makeText(mContext, "I'm new Thread "+currentName, Toast.LENGTH_SHORT).show();
            }
        }, 4000);
複製代碼

這裏咱們用Toast彈出了當前線程的name，結果發現這個線程的名字竟然是main，這也是必然結果

讓咱們一步一步看看，神奇的Handler究竟是怎樣工做的。就從這個代碼開始解讀。首先看一下Handler的構造方法。

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

    ---------------

    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();
        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;
    }
複製代碼

這裏作的事情很簡單，就是完成了一些初始化的工做，調用Looper.myLooper()賦值給當前mLooper，關聯MessageQueue；這裏因爲代碼中調用的是不帶任何參數的構造函數，所以會建立一個mCallback=null且非異步執行的Handler 。

接下看postDelayed 方法。

public final boolean postDelayed(Runnable r, long delayMillis) {
        return sendMessageDelayed(getPostMessage(r), delayMillis);
    }

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

複製代碼

這裏經過getPostMessage(Runnable r) 方法，把咱們在Activity裏寫的Runnable 這個線程賦給了Message 的callback這個屬性。

平時你們使用Handler也發現了，他爲咱們提供了不少方法

所以，上面的postDelayed通過了各類展轉反側，最終來到了這裏：

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);
    }
複製代碼

通過以前的構造方法，mQueue顯然不爲null，繼續往下看

private boolean enqueueMessage(MessageQueue queue, Message msg, long uptimeMillis) {
        msg.target = this;
        if (mAsynchronous) {
            msg.setAsynchronous(true);
        }
        return queue.enqueueMessage(msg, uptimeMillis);
    }
複製代碼

注意，注意，注意 這裏進行了一次賦值：

msg.target = this;
複製代碼

前面提到，這個target就是一個Handler對象，所以這裏Message就和當前Handler關聯起來了。enqueueMessage，哈哈，這就是咱們以前在MessageQueue中提到的進棧操做的方法，咱們看一下：

boolean enqueueMessage(Message msg, long when) {
        if (msg.target == null) {
            throw new IllegalArgumentException("Message must have a target.");
        }
        if (msg.isInUse()) {
            throw new IllegalStateException(msg + " This message is already in use.");
        }

        synchronized (this) {
            if (mQuitting) {
                IllegalStateException e = new IllegalStateException(
                        msg.target + " sending message to a Handler on a dead thread");
                Log.w(TAG, e.getMessage(), e);
                msg.recycle();
                return false;
            }

            msg.markInUse();
            msg.when = when;
            Message p = mMessages;
            boolean needWake;
            if (p == null || when == 0 || when < p.when) {
                // New head, wake up the event queue if blocked.
                msg.next = p;
                mMessages = msg;
                needWake = mBlocked;
            } else {
                // Inserted within the middle of the queue. Usually we don't have to wake
                // up the event queue unless there is a barrier at the head of the queue
                // and the message is the earliest asynchronous message in the queue.
                needWake = mBlocked && p.target == null && msg.isAsynchronous();
                Message prev;
                for (;;) {
                    prev = p;
                    p = p.next;
                    if (p == null || when < p.when) {
                        break;
                    }
                    if (needWake && p.isAsynchronous()) {
                        needWake = false;
                    }
                }
                msg.next = p; // invariant: p == prev.next
                prev.next = msg;
            }

            // We can assume mPtr != 0 because mQuitting is false.
            if (needWake) {
                nativeWake(mPtr);
            }
        }
        return true;
    }
複製代碼

這個方法就是典型的隊列入隊操做，只不過會根據Message這個對象特有的一些屬性，以及當前的狀態是否inUse，是否已經被quit等進行一些額外的判斷。

這樣，咱們就完成消息入隊的操做。還記得咱們在Looper中說過，在loop方法中，會從MessageQueue中取出Message 並執行他的dispatchMessage 方法。

**dispatchMessage **

public void dispatchMessage(Message msg) {
        if (msg.callback != null) {
            handleCallback(msg);
        } else {
            if (mCallback != null) {
                if (mCallback.handleMessage(msg)) {
                    return;
                }
            }
            handleMessage(msg);
        }
    }
複製代碼

到這裏，就很明確了，在以前的postDelayed 方法中，已經經過getPostMessage，實現了 m.callback = r；這樣這裏就會執行第一個if語句：

private static void handleCallback(Message message) {
        message.callback.run();
    }
複製代碼

這樣，就會執行咱們在Activity 的Runnable 中的run 方法了，也就是顯示Toast。

到了這裏，咱們終於明白了，使用Handler 的postDelay 方法時，其Runnable中的run方法並非在子線程中執行，而是把這個Runnable賦值給了一個Message對象的callback屬性，而這個Message會被傳遞到建立Handler所在的線程，也就是這裏的主線程，因此這個Toast的顯示依舊是在主線程中。這也和postDelay API 中所聲明的內容是一致的。

/** * Causes the Runnable r to be added to the message queue, to be run * after the specified amount of time elapses. * The runnable will be run on the thread to which this handler * is attached. */

到這裏，一開始所說的第一個代碼塊所執行的邏輯已經理清楚了，可是仍是有一點疑問，咱們並無在Handler的構造方法中看到Looper 的prepare()方法和loop() 方法被執行，那麼他們究竟是在哪裏執行的呢？這個問題我也是疑惑了好久，最終才明白是在 ActivityThread的main方法中執行。簡單來講，ActivityThread是Java層面一個Android程序真正的入口。關於ActivityThread更多的內容能夠看看這篇文章。

ActivityThread-main方法（截取主要部分）

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

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

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

        if (false) {
            Looper.myLooper().setMessageLogging(new
                    LogPrinter(Log.DEBUG, "ActivityThread"));
        }

        // End of event ActivityThreadMain.
        Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);
        Looper.loop();

        throw new RuntimeException("Main thread loop unexpectedly exited");
    }
複製代碼

這個類藏的比較深，你能夠在Android-SDK\sources\android-24\android\app 這個目錄中找到。

也就是說，在一個Android 程序啓動之初，系統會幫咱們爲這個主線程建立好Looper。只不過這個方法名字比較特殊，叫作prepareMainLooper。

public static void prepareMainLooper() {
        prepare(false);
        synchronized (Looper.class) {
            if (sMainLooper != null) {
                throw new IllegalStateException("The main Looper has already been prepared.");
            }
            sMainLooper = myLooper();
        }
    }
複製代碼

注意這裏調用prepare時傳遞的參數值爲false，和咱們以前建立普通Looper時是不一樣的，這也能夠理解，由於這是主線程，怎麼能夠被容許被外部代碼終止呢。

到這裏，咱們終於完整的理解了開頭咱們提到的第一個代碼塊的內容了。

至於第二種使用寫法出錯的緣由也在明顯不過了，主線程會在程序啓動時在main方法中幫咱們主動建立Looper，調用loop方法；而咱們本身建立的線程就得咱們主動去調用Looper.prepare()，這樣才能保證MessageQueue被建立，程序不會奔潰；可是咱們所指望的Toast依然沒有顯示出來，這是爲何呢？由於，咱們沒有調用loop方法。消息被加入隊列了，可是沒有辦法彈出。所以咱們將代碼修改以下：

new Thread(new Runnable() {
            @Override
            public void run() {

                Looper.prepare();

                try {
                    Thread.sleep(2000);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }

                Toast.makeText(mContext, "I'm new Thread !", Toast.LENGTH_SHORT).show();

                Looper.loop();

            }
        }).start();
複製代碼

這樣就沒問題了，Toast就能夠顯示出來了。實際上，平時寫代碼確定不會這麼寫，這裏只是爲了說明問題。

handleMessage

回想一下，咱們使用Handler最多見的場景：

handler = new MyHandler();

private class MyCallback implements Callback {

        @Override
        public void onFailure(Call call, IOException e) {
            Message msg = new Message();
            msg.what = 100;
            msg.obj = e;
            handler.sendMessage(msg);
        }

        @Override
        public void onResponse(Call call, Response response) throws IOException {
            Message msg = new Message();
            msg.what = 200;
            msg.obj = response.body().string();
            handler.sendMessage(msg);
        }
    }
複製代碼

上面的代碼是OKHttp的回調方法，因爲其回調方法不處於UI 線程，所以須要咱們經過Handler將結果發送到主線中取執行。那麼這又是怎樣實現的呢？

前面咱們截圖說過，Handler爲咱們提供許多sendMessage 相關的方法，所以這裏咱們在onResponse 中執行的sendMessage 通過層層傳遞，異曲同工依然會回到MessageQueue的enqueueMessage方法，也就是說全部的sendMessageXXX方法完成的工做無非就是隊列入棧的工做，就是將包含特定信息的Message加入到MessageQueue中。而咱們也知道，經過loop方法，會從MessageQueue中取出Message，執行每個Message 所對應Handler的dispatchMessage方法，咱們再看一次這個方法：

public void dispatchMessage(Message msg) {
        if (msg.callback != null) {
            handleCallback(msg);
        } else {
            if (mCallback != null) {
                if (mCallback.handleMessage(msg)) {
                    return;
                }
            }
            handleMessage(msg);
        }
    }
複製代碼

這一次，咱們建立的Message很簡單，其callback屬性必然是空的，並且在實例化Handler時，調用的是其無參構造函數，所以這個時候，就會執行最後一行代碼handleMessage(msg) ；

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

空的 ! 沒錯，這個方法就是空的，由於這是須要咱們在Handler的繼承類中本身實現的方法呀。好比下面這樣；

class MyHandler extends Handler {
        @Override
        public void handleMessage(Message msg) {
            super.handleMessage(msg);
            loading.setVisibility(View.GONE);
            switch (msg.what) {
                case 100:
                    Object e = msg.obj;
                    Toast.makeText(mContext, e.toString(), Toast.LENGTH_SHORT).show();
                    break;
                case 200:
                    String response = (String) msg.obj;
                    tv.setText(response);
                    break;
                default:
                    break;
            }
        }
    }
複製代碼