深入探討Android異步精髓Handler
前言
眾所周知，Android的UI是在其主線程中進(jìn)行刷新的，所以Google建議開(kāi)發(fā)人員切勿在主線程中進(jìn)行耗時(shí)的操作否則很容易導(dǎo)致應(yīng)用程序無(wú)響應(yīng)(ANR)。鑒于此幾乎接近硬性的要求，我們常把耗時(shí)的操作(比如網(wǎng)絡(luò)請(qǐng)求)置于子線程中進(jìn)行;但是子線程不能直接訪問(wèn)UI。
至此，這個(gè)矛盾就凸顯出來(lái)了：
- 主線程可以刷新UI，但不能執(zhí)行耗時(shí)操作
- 子線程可以執(zhí)行耗時(shí)操作 ，但是不能直接刷新UI
嗯哼，那有沒(méi)有一個(gè)東西可以調(diào)和并化解這個(gè)矛盾呢?當(dāng)然是有的，Google采用Handler把主線程和子線程精巧地聯(lián)系起來(lái)——子線程中進(jìn)行耗時(shí)的業(yè)務(wù)邏輯，然后利用Handler通知主線程刷新UI。除此以外，還有別的方式可以實(shí)現(xiàn)類(lèi)似的操作么?答案是肯定的，我們也可以利用AsyncTask或者IntentService進(jìn)行異步的操作。這兩者又是怎么做到的呢?其實(shí)，在AsyncTask和IntentService的內(nèi)部亦使用了Handler實(shí)現(xiàn)其主要功能。拋開(kāi)這兩者不談，當(dāng)我們打開(kāi)Android源碼的時(shí)候也隨處可見(jiàn)Handler的身影。所以，Handler是Android異步操作的核心和精髓，它在眾多領(lǐng)域發(fā)揮著極其重要甚至是不可替代的作用。
在此，對(duì)Handler的工作原理和實(shí)現(xiàn)機(jī)制進(jìn)行系統(tǒng)的梳理。
ThreadLocal簡(jiǎn)介及其使用
對(duì)于線程Thread大家都挺熟悉的了，但是對(duì)于ThreadLocal可能就要陌生許多了。雖然我們對(duì)于它不太了解，但是它早在JDK1.2版本中就已問(wèn)世并且被廣泛的使用，比如hibernate，EventBus，Handler都運(yùn)用了ThreadLocal進(jìn)行線程相關(guān)的操作。如果單純地從ThreadLocal這個(gè)名字來(lái)看，它帶著濃濃的“本地線程”的味道; 然而，喝一口之后才發(fā)現(xiàn)根本就不是這個(gè)味兒。其實(shí)，ThreadLocal并不是用來(lái)操作什么本地線程而是用于實(shí)現(xiàn)不同線程的數(shù)據(jù)副本。當(dāng)使用ThreadLocal維護(hù)變量時(shí)，它會(huì)為每個(gè)使用該變量的線程提供獨(dú)立的變量副本;每一個(gè)線程都可以獨(dú)立地改變自己的副本并且不會(huì)影響其它線程所持有的對(duì)應(yīng)的副本。所以，ThreadLocal的實(shí)際作用并不與它的名字所暗含的意義相吻合，或許改稱(chēng)為T(mén)hreadLocalVariable(線程本地變量)會(huì)更合適一些。
接下來(lái)，我們通過(guò)一個(gè)實(shí)例來(lái)瞅瞅ThreadLocal的使用方式
- /**
- * 原創(chuàng)作者:
- * 谷哥的小弟
- *
- * 博客地址:
- * http://blog.csdn.net/lfdfhl
- */
- private void testThreadLocal(){
- mThreadLocal.set("東京熱");
- new HotThread1().start();
- new HotThread2().start();
- hot3=mThreadLocal.get();
- try{
- Thread.sleep(1000*4);
- Log.i(TAG,"HotThread1獲取到的變量值: "+hot1);
- Log.i(TAG,"HotThread2獲取到的變量值: "+hot2);
- Log.i(TAG,"MainThread獲取到的變量值: "+hot3);
- }catch (Exception e){
- }
- }
- private class HotThread1 extends Thread{
- @Override
- public void run() {
- super.run();
- mThreadLocal.set("北京熱");
- hot1=mThreadLocal.get();
- }
- }
- private class HotThread2 extends Thread{
- @Override
- public void run() {
- super.run();
- mThreadLocal.set("南京熱");
- hot2=mThreadLocal.get();
- }
- }
查看輸出結(jié)果：
- HotThread1獲取到的變量值: 北京熱
- HotThread2獲取到的變量值: 南京熱
- MainThread獲取到的變量值: 東京熱
在這段代碼中使用ThreadLocal保存String類(lèi)型的數(shù)據(jù)，并且在主線程和兩個(gè)子線程中為T(mén)hreadLocal設(shè)置了不同的值，然后再將這些值分別取出。結(jié)合輸出日志可以發(fā)現(xiàn)：在不同的線程中訪問(wèn)了同一個(gè)ThreadLocal對(duì)象，但是通過(guò)mThreadLocal.get()得到的值卻是不一樣的;也就是說(shuō)：它們之間沒(méi)有發(fā)生相互的影響而是保持了彼此的獨(dú)立。明白了ThreadLocal的這個(gè)特性之后，我們?cè)偃ダ斫釲ooper的工作機(jī)制就會(huì)容易得多了。
Looper、線程、消息隊(duì)列的關(guān)系
Google官方建議開(kāi)發(fā)人員使用Handler實(shí)現(xiàn)異步刷新UI，我們?cè)谄匠５墓ぷ髦幸埠芎玫夭杉{了這個(gè)提議：首先在主線程中建立Handler，然后在子線程中利用handler.sendMessage(message)發(fā)送消息至主線程，最終消息在handleMessage(Message msg) {}得到相應(yīng)的處理。這個(gè)套路，大家都再熟悉不過(guò)了;現(xiàn)在換個(gè)角度，我們?cè)囋囋谧泳€程中建立Handler
- private class LooperThread extends Thread{
- @Override
- public void run() {
- super.run();
- Handler handler=new Handler();
- //doing something
- }
- }
此處的代碼很簡(jiǎn)單：LooperThread繼承自Thread，并且在其run( )方法中新建一個(gè)Handler。
嗯哼，再運(yùn)行一下，喔哦，報(bào)錯(cuò)了：
- Can’t create handler inside thread that has not called Looper.prepare().
咦，有點(diǎn)出師不利呢，剛開(kāi)始試就出錯(cuò)了…….沒(méi)事，生活不就是無(wú)盡的挫折和希望嘛，這點(diǎn)小事嘛也不算。既然是在調(diào)用Handler的構(gòu)造方法時(shí)報(bào)的錯(cuò)那就從該構(gòu)造方法的源碼入手，一探究竟:
- public Handler() {
- this(null, false);
- }
- public Handler(Callback callback) {
- this(callback, 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");
- }
- }
- 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;
- }
請(qǐng)注意第20行代碼：
如果mLooper == null那么系統(tǒng)就會(huì)拋出剛才的錯(cuò)誤：Can’t create handler inside thread that has not called Looper.prepare()。這句話的意思是：如果在線程內(nèi)創(chuàng)建handler必須調(diào)用Looper.prepare()。既然這個(gè)提示已經(jīng)提示了我們?cè)撛趺醋?，那就加上這一行代碼：
- private class LooperThread extends Thread{
- @Override
- public void run() {
- super.run();
- Looper.prepare();
- Handler handler=new Handler();
- System.out.println("add code : Looper.prepare()");
- //doing something
- }
- }
嘿嘿，果然不再報(bào)錯(cuò)了，運(yùn)行一下：
既然Looper.prepare()解決了這個(gè)問(wèn)題，那我們就去瞅瞅在該方法中做了哪些操作：
- /**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
- * loop() after calling this method, and end it by calling 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));
- }
從這段源碼及其注釋文檔我們可以看出：
在prepare()中利用一個(gè)Looper來(lái)初始化當(dāng)前線程或者說(shuō)初始化一個(gè)帶有Looper的線程。
請(qǐng)注意第14行代碼，它是這段源碼的核心，現(xiàn)對(duì)其詳細(xì)分析：
- sThreadLocal.set(new Looper(quitAllowed));
在該行代碼中一共執(zhí)行了兩個(gè)操作
(1) 構(gòu)造Looper
- private Looper(boolean quitAllowed) {
- mQueue = new MessageQueue(quitAllowed);
- mThread = Thread.currentThread();
- }
在Looper的構(gòu)造方法中初始化了一個(gè)消息隊(duì)列MessageQueue和一個(gè)線程Thread。從這可看出：一個(gè)Looper對(duì)應(yīng)著一個(gè)消息隊(duì)列以及當(dāng)前線程。
當(dāng)收到消息Message后系統(tǒng)會(huì)將其存入消息隊(duì)列中等候處理。至于Looper，它在Android的消息機(jī)制中擔(dān)負(fù)著消息輪詢(xún)的職責(zé)，它會(huì)不間斷地查看MessageQueue中是否有新的未處理的消息;若有則立刻處理，若無(wú)則進(jìn)入阻塞。
(2) 將此Looper保存到sThreadLocal中。
此處的sThreadLocal是定義在Looper類(lèi)中的一個(gè)ThreadLocal類(lèi)型變量
- static final ThreadLocal<Looper> sThreadLocal = new ThreadLocal<Looper>();
Looper是framework中的一個(gè)類(lèi)，sThreadLocal是它的一個(gè)static final變量。當(dāng)在某一個(gè)Thread中執(zhí)行Looper.prepare()時(shí)系統(tǒng)就會(huì)將與該Thread所對(duì)應(yīng)的Looper保存到sThreadLocal中。不同的線程對(duì)著不同的Looper，但它們均由系統(tǒng)保存在sThreadLocal中并且互不影響，相互獨(dú)立;并且可以通過(guò)sThreadLocal.get()獲取不同線程所對(duì)應(yīng)的Looper.
在調(diào)用prepare()方法后需要調(diào)用loop()方法開(kāi)始消息的輪詢(xún)，并且在需要的時(shí)候調(diào)用quit()方法停止消息的輪詢(xún)
假若再次執(zhí)行Looper.prepare()系統(tǒng)發(fā)現(xiàn)sThreadLocal.get()的值不再為null于是拋出異常：
Only one Looper may be created per thread，一個(gè)線程只能創(chuàng)建一個(gè)Looper!
小結(jié)：
- 一個(gè)線程對(duì)應(yīng)一個(gè)Looper
- 一個(gè)Looper對(duì)應(yīng)一個(gè)消息隊(duì)列
- 一個(gè)線程對(duì)應(yīng)一個(gè)消息隊(duì)列
- 線程，Looper，消息隊(duì)列三者一一對(duì)應(yīng)
所以，在一個(gè)子線程中使用Handler的方式應(yīng)該是這樣的:
- class LooperThread extends Thread {
- public Handler mHandler;
- public void run() {
- Looper.prepare();
- mHandler = new Handler() {
- public void handleMessage(Message msg) {
- }
- };
- Looper.loop();
- }
- }
看到這個(gè)范例，有的人可能心里就犯嘀咕了：為什么我們平常在MainActivity中使用Handler時(shí)并沒(méi)有調(diào)用Looper.prepare()也沒(méi)有報(bào)錯(cuò)呢?
這是因?yàn)閁I線程是主線程，系統(tǒng)會(huì)自動(dòng)調(diào)用Looper.prepareMainLooper()方法創(chuàng)建主線程的Looper和消息隊(duì)列MessageQueue
Message的發(fā)送和處理過(guò)程
在討論完Looper、線程、消息隊(duì)列這三者的關(guān)系之后我們?cè)賮?lái)瞅瞅Android消息機(jī)制中對(duì)于Message的發(fā)送和處理。
平常最常用的方式:
handler.sendMessage(message)——>發(fā)送消息
handleMessage(Message msg){}——>處理消息
先來(lái)分析消息的入隊(duì)。
Handler可以通過(guò)post()、postAtTime()、postDelayed()、postAtFrontOfQueue()等方法發(fā)送消息，除了postAtFrontOfQueue()之外這幾個(gè)方法均會(huì)執(zhí)行到sendMessageAtTime(Message msg, long uptimeMillis)方法，源碼如下：
- 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);
- }
- public final boolean sendMessageAtFrontOfQueue(Message msg) {
- 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, 0);
- }
- private boolean enqueueMessage(MessageQueue queue, Message msg, long uptimeMillis) {
- msg.target = this;
- if (mAsynchronous) {
- msg.setAsynchronous(true);
- }
- return queue.enqueueMessage(msg, uptimeMillis);
- }
在這里可以看到sendMessageAtTime()內(nèi)部又調(diào)用了enqueueMessage()，在該方法內(nèi)的重要操作：
- ***步：
給msg設(shè)置了target，請(qǐng)參見(jiàn)代碼第25行此處的this就是當(dāng)前Handler對(duì)象本身。在這就指明了該msg的來(lái)源——它是由哪個(gè)Handler發(fā)出的，與此同時(shí)也指明了該msg的歸宿——它該由哪個(gè)Handler處理。不難發(fā)現(xiàn)，哪個(gè)Handler發(fā)出了消息就由哪個(gè)Handler負(fù)責(zé)處理。
- 第二步：
將消息放入消息隊(duì)列中，請(qǐng)參見(jiàn)代碼第29行在enqueueMessage(msg,uptimeMillis)中將消息Message存放進(jìn)消息隊(duì)列中，距離觸發(fā)時(shí)間最短的message排在隊(duì)列最前面,同理距離觸發(fā)時(shí)間最長(zhǎng)的message排在隊(duì)列的最尾端。若調(diào)用sendMessageAtFrontOfQueue()方法發(fā)送消息它會(huì)直接調(diào)用該enqueueMessage(msg,uptimeMillis)讓消息入隊(duì)只不過(guò)時(shí)間為延遲時(shí)間為0，也就是說(shuō)該消息會(huì)被插入到消息隊(duì)列頭部?jī)?yōu)先得到執(zhí)行。直覺(jué)告訴我們此處的消息隊(duì)列mQueue就是該線程所對(duì)應(yīng)的消息隊(duì)列?？墒枪庥兄庇X(jué)是不夠的甚至是不可靠的。我們?cè)倩剡^(guò)頭瞅瞅Handler的構(gòu)造方法，從源碼中找到確切的依據(jù)
- 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");
- }
- }
- 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;
- }
(1) 獲取Looper，請(qǐng)參見(jiàn)代碼第10行
(2) 利用Looper的消息隊(duì)列為mQueue賦值，請(qǐng)參見(jiàn)代碼第15行
(3) 為mCallback賦值，，請(qǐng)參見(jiàn)代碼第16行
(4) 為mAsynchronous賦值，，請(qǐng)參見(jiàn)代碼第17行
嗯哼，看到了吧，這個(gè)mQueue就是從Looper中取出來(lái)的。在之前我們也詳細(xì)地分析了Looper、線程、消息隊(duì)列這三者的一一對(duì)應(yīng)關(guān)系，所以此處的mQueue正是線程所對(duì)應(yīng)的消息隊(duì)列。
看完了消息的入隊(duì)，再來(lái)分析消息的出隊(duì)。
請(qǐng)看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 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
- final Printer logging = me.mLogging;
- if (logging != null) {
- logging.println(">>>>> Dispatching to " + msg.target + " " +
- msg.callback + ": " + msg.what);
- }
- final long traceTag = me.mTraceTag;
- if (traceTag != 0) {
- Trace.traceBegin(traceTag, msg.target.getTraceName(msg));
- }
- try {
- msg.target.dispatchMessage(msg);
- } finally {
- if (traceTag != 0) {
- Trace.traceEnd(traceTag);
- }
- }
- 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();
- }
- }
我們發(fā)現(xiàn)關(guān)于消息的處理是在一個(gè)死循環(huán)中就行的，請(qǐng)參見(jiàn)代碼第13-55行。也就是說(shuō)在該段代碼中Looper一直在輪詢(xún)消息隊(duì)列MessageQueue。假若消息隊(duì)列中沒(méi)有未處理的消息(即queue.next()==null)則其進(jìn)入阻塞block狀態(tài)，假若消息隊(duì)列中有待處理消息(即queue.next()!=null)則利用msg.target.dispatchMessage(msg)將該消息派發(fā)至對(duì)應(yīng)的Handler。
到了這，可能有的人會(huì)有一個(gè)疑問(wèn)：系統(tǒng)怎么知道把消息發(fā)送給哪個(gè)Handler呢?
嘿嘿，還記不記得enqueueMessage()中系統(tǒng)給msg設(shè)置了target從而確定了其目標(biāo)Handler么?嗯哼，所以只要通過(guò)msg.target.dispatchMessage(msg)就可以將消息派發(fā)至對(duì)應(yīng)的Handler了。那在dispatchMessage()中又會(huì)對(duì)消息做哪些操作呢?我們繼續(xù)跟進(jìn)源碼
- public void dispatchMessage(Message msg) {
- if (msg.callback != null) {
- handleCallback(msg);
- } else {
- if (mCallback != null) {
- if (mCallback.handleMessage(msg)) {
- return;
- }
- }
- handleMessage(msg);
- }
- }
哇哈，看到這，心情就舒暢多了，基本上回到了我們熟悉的地方;在此處對(duì)Message消息進(jìn)行了處理，我們來(lái)瞅瞅主要的步驟
- ***步：
處理Message的回調(diào)callback，請(qǐng)參見(jiàn)代碼第3行
比如調(diào)用handler.post(Runnable runnable)時(shí)，該runnable就會(huì)被系統(tǒng)封裝為Message的callback。
關(guān)于這點(diǎn)在源碼中也有非常直觀的體現(xiàn)：
- private static Message getPostMessage(Runnable r) {
- Message m = Message.obtain();
- m.callback = r;
- return m;
- }
- 第二步：
處理Handler的回調(diào)callback，請(qǐng)參見(jiàn)代碼第6行
比如執(zhí)行Handler handler=Handler(Callback callback)時(shí)就會(huì)將callback賦值給mCallback，關(guān)于這點(diǎn)已經(jīng)在介紹Handler構(gòu)造方法時(shí)分析過(guò)了，不再贅述。
第三步：
調(diào)用handleMessage()處理消息Message，請(qǐng)參見(jiàn)代碼第10行
handleMessage()的源碼如下：
- public void handleMessage(Message msg) {
- }
嗯哼，它是一個(gè)空的方法。所以Handler的子類(lèi)需要覆寫(xiě)該方法，并在其中處理接收到的消息。
梳理Handler工作機(jī)制
至此，關(guān)于Handler的異步機(jī)制及其實(shí)現(xiàn)原理已經(jīng)分析完了。在此，對(duì)其作一個(gè)全面的梳理和總結(jié)。
Android異步消息機(jī)制中主要涉及到:Thread、Handler、MessageQueue、Looper，在整個(gè)機(jī)制中它們扮演著不同的角色也承擔(dān)著各自的不同責(zé)任。
- Thread負(fù)責(zé)業(yè)務(wù)邏輯的實(shí)施。
線程中的操作是由各自的業(yè)務(wù)邏輯所決定的，視具體情況進(jìn)行。
- Handler負(fù)責(zé)發(fā)送消息和處理消息。
通常的做法是在主線程中建立Handler并利用它在子線程中向主線程發(fā)送消息，在主線程接收到消息后會(huì)對(duì)其進(jìn)行處理
- MessageQueue負(fù)責(zé)保存消息。
Handler發(fā)出的消息均會(huì)被保存到消息隊(duì)列MessageQueue中，系統(tǒng)會(huì)根據(jù)Message距離觸發(fā)時(shí)間的長(zhǎng)短決定該消息在隊(duì)列中位置。在隊(duì)列中的消息會(huì)依次出隊(duì)得到相應(yīng)的處理。
- Looper負(fù)責(zé)輪詢(xún)消息隊(duì)列。
Looper使用其loop()方法一直輪詢(xún)消息隊(duì)列，并在消息出隊(duì)時(shí)將其派發(fā)至對(duì)應(yīng)的Handler.
為了更好地理解這幾者的相互關(guān)系及其作用，請(qǐng)參見(jiàn)如下示圖
使用Handler的錯(cuò)誤姿勢(shì)及其潛在風(fēng)險(xiǎn)
關(guān)于Handler的具體用法，尤其是那些常規(guī)的使用方式在此就不再一一列舉了。
