Android中消息機制:Handler機制源碼淺析

前言

Android中的消息機制一直都是新手頭疼的問題,對於Handler機制的理解是Android重中之重,經常在面試和日常開發中遇到,所以,這篇文章目的是通過解析源碼來幫助梳理Handler的工作機制和運行流程。再此之前先解決一下新手疑惑的問題,還有爲文章後面解析做鋪墊。

Handler機制到底幹嘛用的?

在實際開發中,最常用到Handler就是切換到UI線程中更新UI,其實Handler不止是更新UI纔會用到,對於任何切換線程執行任務都是可以做的。

爲什麼Android中只能在主線程(UI線程)中更新UI?

Android和通常的GUI程序一樣,都是單線程模型的,因爲要UI更新效率直接影響到用戶體驗,所以UI的處理一定要放在第一位。子線程可能造成UI更新發錯亂,原因是多個子線程同時對一個UI控件進行操作,結果造成界面更新不符合預期,如果用到上鎖機制,你就想想你的代碼會有多複雜吧。。而且加鎖會影響UI更新效率,所以綜上原因,Android只允許你在主線程中更新UI。

Android程序的入口在哪裏?

剛學習Java的同學都是從在main方法中寫一句System.out.println(“Hello World!”)開始的,而學了Android之後,就有疑問了:Android程序沒有main方法嗎??答案肯定是有的,在Android中入口類是ActivityThread,其中main方法就是程序啓動時入口方法。

Handler的基本用法

public class MainActivity extends AppCompatActivity {
    private TextView mTextView;
    private Button mButton;

    //點擊按鈕之後新建一個子線程,發送一個消息到Looper的消息隊列中輪循
    private Runnable mTask = new Runnable() {
        @Override
        public void run() {
            Message message = Message.obtain();
            message.obj = "Hello World";
            mHandler.sendMessage(message);
        }
    };

    //Handler對象,handleMessage方法會在Looper處理到消息時候回調
    private Handler mHandler = new Handler() {
        @Override
        public void handleMessage(Message msg) {
            mTextView.setText((CharSequence) msg.obj);
        }
    };

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        initView();
    }

    private void initView() {
        mTextView = (TextView) findViewById(R.id.tv_hello);
        mButton = (Button) findViewById(R.id.btn_set_text);

        mButton.setOnClickListener(new View.OnClickListener() {
            @Override
            public void onClick(View v) {
                new Thread(mTask).start();
            }
        });
    }
}

大家對以上的操作應該是很熟悉了吧,不熟悉你就要去看看handler怎麼使用的文檔,再接着看下面的解析。。這就是一個簡單的從子線程切換到主線程去更新UI的做法。同時Handler的應用還有HandlerThread,這裏就不展開講了,有興趣可以自行查看文檔。

Handler機制原理

下面就開始通過源碼來解析Handler機制的原理了,其實Handler機制由三個類構成,分別是Handler,Looper,MessageQueue。在此就不貼出流程圖了,個人覺得流程圖並不能完全呈現出其運作原理,而且容易誤導你對源碼的理解。

Looper的源碼淺析

Looper中主要需要關注的兩個方法是prepare和loop。這個類的主要作用是用來輪詢Handler發送的消息,能夠使得消息的處理在指定線程中執行,得益於ThreadLocal類。ThreadLocal是一個線程內部數據存儲類,有了它就可以在指定的線程中存儲數據。

首先來看下Looper的構造方法:

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

Looper的構造方法是private修飾的,意味着Looper只能在Looper類中構造,而查看源碼發現,Looper的構造只有在prepare方法出現。並且在構造的時候,Looper對象會持有一個MessageQueue的引用,並且記錄了當前的線程。下面來看下prepare方法的邏輯:

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

prepare()方法很簡單,就是創建一個Looper對象,保存在sThreadLocal中,這樣Looper對象就和當前的線程關聯起來了。

總結來說Looper的創建其實很簡單,可以理解爲將一個Looper對象存儲到當前線程中,不同線程中創建的Looper,通過Looper.myLooper()返回的Looper是不同實例。下面是Looper中的核心方法,loop方法。

//省略的代碼大部分是非邏輯的日誌記錄相關代碼
    public static void loop() {

        //省略若干代碼
        for (;;) {
            Message msg = queue.next(); // queue是當前的消息隊列對象,這裏可能堵塞線程
            if (msg == null) {
                return;
            }


            //省略若干代碼
            try {
                msg.target.dispatchMessage(msg);
            } finally {
                //省略若干代碼
            }

            //省略若干代碼
        }
    }

這裏的代碼也很簡單,就是一個死循環,不停從Looper持有的MessageQueue對象中排隊出message。然後調用msg.target.despatchMessage(msg),注意:這裏都是在Looper所在線程中調用的。msg.target就是發送了這條消息的主人,也就是handler對象,調用dispatchMessage方法就會按照一定的邏輯順序回調處理信息的方法,具體邏輯下面再講,這樣就講完了Looper的核心工作原理了,並沒有多複雜,當然源碼還是看着有點繞的,感興趣的同學可以去看下源碼。

Handler的源碼淺析

Handler的主要作用是發送message和處理message,handler是怎麼和looper關聯起來的呢,其實就是通過handler的構造方法,其中Handler總共有7個構造方法,最終調用的就是以下兩個中的一個:

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


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,沒有傳入的話,當前Handler中的mLooper默認就是當前線程中的Looper,如果當前線程沒有Looper對象就會拋出異常。因此,handler必須是要有looper關聯着的,缺少了Looper的Handler是不能工作的。

我們剛學習handler用法的時候都是從sendMessage(msg)開始的,其實handler發送message的方式有很多,比如post,postDelay,sendMessageAtTime等等···其實不論是以什麼樣的形式發送的消息,最後都是調用了enqueueMessage(MessageQueue queue, Message msg, long uptimeMillis)方法,這個方法再調用了消息隊列的中的enqueueMessage(Message msg, long when)方法,這樣就將該消息放入消息隊列中排隊了。

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

上面講過了,在Looper的loop方法中,如果輪詢當一條消息時會調用發送該消息的dispatchMessage方法,這樣就分發了該消息交給handler來處理,dispatchMessage有一定的分發邏輯,我們來看代碼分析:

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

首先判斷msg是否存在callback,如果存在就是調用該callback(Runnable對象)的run方法;否則先判斷該handler的mCallback是否爲空,如果不爲空,則調用它的handleMessage方法,如果它的handleMessage返回false,則還會調用handler中的handleMessage方法;如果其返回了true,則不會調用handler中的handleMessage方法;如果mCallback爲空,那也只會調用handler中的handleMessage方法。感覺很繞是吧···最好還是自己畫一個流程圖,這樣就能清楚知道這個邏輯了。爲毛弄這麼複雜的邏輯呢?其實這樣就滿足你的多種體位,啊,呸··滿足你的多種實現方式,比如能message多次分發,比如這種寫法:

private Handler mHandler = new Handler(new Handler.Callback() {
    @Override
    public boolean handleMessage(Message msg) {
        Log.d(TAG, "首先回調此方法 " + msg.obj);
        return false;
    }
}) {
    @Override
    public void handleMessage(Message msg) {
        Log.d(TAG, "然後後回調此方法 " + msg.obj);
    }
};

這樣的寫法既給handler傳入了一個callback又重載了其handleMessage方法,只要callback中的handleMessage返回爲false,表示不攔截信息,就會繼續分發消息,最終調用handler的handleMessage方法。handler主要要關注的核心原理就在此,其他細節部分就省略不講了,自己可以嘗試看源碼學習。

MessageQueue的源碼淺析

MessageQueue顧名思義,消息隊列,這是一個用單鏈表實現的隊列結構,作用就是存儲排隊進來的消息,主要的操作就是插入和移除,分別對應了enqueueMessage(Message msg, long when)和next()方法。下面貼出代碼:

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

實質上enqueueMessage就是一個單鏈表插入的操作。

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

        int pendingIdleHandlerCount = -1; // -1 only during first iteration
        int nextPollTimeoutMillis = 0;

        for (;;) {
            if (nextPollTimeoutMillis != 0) {
                Binder.flushPendingCommands();
            }

            nativePollOnce(ptr, nextPollTimeoutMillis);

            synchronized (this) {
                // Try to retrieve the next message.  Return if found.
                final long now = SystemClock.uptimeMillis();
                Message prevMsg = null;
                Message msg = mMessages;
                if (msg != null && msg.target == null) {
                    // Stalled by a barrier.  Find the next asynchronous message in the queue.
                    do {
                        prevMsg = msg;
                        msg = msg.next;
                    } while (msg != null && !msg.isAsynchronous());
                }
                if (msg != null) {
                    if (now < msg.when) {
                        // Next message is not ready.  Set a timeout to wake up when it is ready.
                        nextPollTimeoutMillis = (int) Math.min(msg.when - now, Integer.MAX_VALUE);
                    } else {
                        // Got a message.
                        mBlocked = false;
                        if (prevMsg != null) {
                            prevMsg.next = msg.next;
                        } else {
                            mMessages = msg.next;
                        }
                        msg.next = null;
                        if (DEBUG) Log.v(TAG, "Returning message: " + msg);
                        msg.markInUse();
                        return msg;
                    }
                } else {
                    // No more messages.
                    nextPollTimeoutMillis = -1;
                }

                // Process the quit message now that all pending messages have been handled.
                if (mQuitting) {
                    dispose();
                    return null;
                }

                // If first time idle, then get the number of idlers to run.
                // Idle handles only run if the queue is empty or if the first message
                // in the queue (possibly a barrier) is due to be handled in the future.
                if (pendingIdleHandlerCount < 0
                        && (mMessages == null || now < mMessages.when)) {
                    pendingIdleHandlerCount = mIdleHandlers.size();
                }
                if (pendingIdleHandlerCount <= 0) {
                    // No idle handlers to run.  Loop and wait some more.
                    mBlocked = true;
                    continue;
                }

                if (mPendingIdleHandlers == null) {
                    mPendingIdleHandlers = new IdleHandler[Math.max(pendingIdleHandlerCount, 4)];
                }
                mPendingIdleHandlers = mIdleHandlers.toArray(mPendingIdleHandlers);
            }

            // Run the idle handlers.
            // We only ever reach this code block during the first iteration.
            for (int i = 0; i < pendingIdleHandlerCount; i++) {
                final IdleHandler idler = mPendingIdleHandlers[i];
                mPendingIdleHandlers[i] = null; // release the reference to the handler

                boolean keep = false;
                try {
                    keep = idler.queueIdle();
                } catch (Throwable t) {
                    Log.wtf(TAG, "IdleHandler threw exception", t);
                }

                if (!keep) {
                    synchronized (this) {
                        mIdleHandlers.remove(idler);
                    }
                }
            }

            // Reset the idle handler count to 0 so we do not run them again.
            pendingIdleHandlerCount = 0;

            // While calling an idle handler, a new message could have been delivered
            // so go back and look again for a pending message without waiting.
            nextPollTimeoutMillis = 0;
        }
    }

next方法是一個死循環,所以在調用next方法的時候,如果消息隊列中沒有消息的話就會堵塞,如果有消息進入就會移除該消息。

以上就是handler機制的整個流程解析,其實把核心內容拿出來其實還是很容易理解的。

UI線程中的Looper創建過程

大家在使用handler時,大多會直接在UI線程中直接new Handler(),並沒有傳入looper對象,爲什麼可以依然運行呢?其實上面就講到了,沒有傳入looper給handler的時候,構造方法會默認傳入當前線程中的looper對象給handler,那說明UI線程中默認給我們提供了一個looper對象,那這個looper對象是在哪裏創建的呢?其實就是在程序入口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.

        //.....
        Looper.loop();

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

可以看出來,在UI線程中,首先調用了Looper的prepareMainLooper方法,其實就是給UI線程關聯一個looper對象,並且記錄到Looper中的sMainLooper中了,然後調用了Looper.loop()方法,開始輪詢消息,這裏loop方法會堵塞線程,如果looper意外停止工作則會拋出異常。

在此Android消息機制淺析結束,希望能幫助到一些初學者,如果文中有誤請大家指出,謝謝~~

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章