Android Handler怎么使用

本篇內(nèi)容主要講解“Android Handler怎么使用”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實(shí)用性強(qiáng)。下面就讓小編來帶大家學(xué)習(xí)“Android Handler怎么使用”吧!

ThreadLocal簡介及其使用

對(duì)于線程Thread大家都挺熟悉的了，但是對(duì)于ThreadLocal可能就要陌生許多了。雖然我們對(duì)于它不太了解，但是它早在JDK1.2版本中就已問世并且被廣泛的使用，比如hibernate，EventBus，Handler都運(yùn)用了ThreadLocal進(jìn)行線程相關(guān)的操作。如果單純地從ThreadLocal這個(gè)名字來看，它帶著濃濃的“本地線程”的味道;  然而，喝一口之后才發(fā)現(xiàn)根本就不是這個(gè)味兒。其實(shí)，ThreadLocal并不是用來操作什么本地線程而是用于實(shí)現(xiàn)不同線程的數(shù)據(jù)副本。當(dāng)使用ThreadLocal維護(hù)變量時(shí)，它會(huì)為每個(gè)使用該變量的線程提供獨(dú)立的變量副本;每一個(gè)線程都可以獨(dú)立地改變自己的副本并且不會(huì)影響其它線程所持有的對(duì)應(yīng)的副本。所以，ThreadLocal的實(shí)際作用并不與它的名字所暗含的意義相吻合，或許改稱為ThreadLocalVariable(線程本地變量)會(huì)更合適一些。

接下來，我們通過一個(gè)實(shí)例來瞅瞅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類型的數(shù)據(jù)，并且在主線程和兩個(gè)子線程中為ThreadLocal設(shè)置了不同的值，然后再將這些值分別取出。結(jié)合輸出日志可以發(fā)現(xiàn)：在不同的線程中訪問了同一個(gè)ThreadLocal對(duì)象，但是通過mThreadLocal.get()得到的值卻是不一樣的;也就是說：它們之間沒有發(fā)生相互的影響而是保持了彼此的獨(dú)立。明白了ThreadLocal的這個(gè)特性之后，我們再去理解Looper的工作機(jī)制就會(huì)容易得多了。

Looper、線程、消息隊(duì)列的關(guān)系

Google官方建議開發(fā)人員使用Handler實(shí)現(xiàn)異步刷新UI，我們在平常的工作中也很好地采納了這個(gè)提議：首先在主線程中建立Handler，然后在子線程中利用handler.sendMessage(message)發(fā)送消息至主線程，最終消息在handleMessage(Message  msg) {}得到相應(yīng)的處理。這個(gè)套路，大家都再熟悉不過了;現(xiàn)在換個(gè)角度，我們試試在子線程中建立Handler

private class LooperThread  extends Thread{         @Override         public void run() {             super.run();             Handler handler=new Handler();             //doing something         }     }

此處的代碼很簡單：LooperThread繼承自Thread，并且在其run( )方法中新建一個(gè)Handler。

嗯哼，再運(yùn)行一下，喔哦，報(bào)錯(cuò)了：

Can’t create handler inside thread that has not called Looper.prepare().

咦，有點(diǎn)出師不利呢，剛開始試就出錯(cuò)了…….沒事，生活不就是無盡的挫折和希望嘛，這點(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)提示了我們該怎么做，那就加上這一行代碼：

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

既然Looper.prepare()解決了這個(gè)問題，那我們就去瞅瞅在該方法中做了哪些操作：

/**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來初始化當(dāng)前線程或者說初始化一個(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ù)著消息輪詢的職責(zé)，它會(huì)不間斷地查看MessageQueue中是否有新的未處理的消息;若有則立刻處理，若無則進(jìn)入阻塞。

(2) 將此Looper保存到sThreadLocal中。

此處的sThreadLocal是定義在Looper類中的一個(gè)ThreadLocal類型變量

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

Looper是framework中的一個(gè)類，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ú)立;并且可以通過sThreadLocal.get()獲取不同線程所對(duì)應(yīng)的Looper.

在調(diào)用prepare()方法后需要調(diào)用loop()方法開始消息的輪詢，并且在需要的時(shí)候調(diào)用quit()方法停止消息的輪詢

假若再次執(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é)：

1. 一個(gè)線程對(duì)應(yīng)一個(gè)Looper

2. 一個(gè)Looper對(duì)應(yīng)一個(gè)消息隊(duì)列

3. 一個(gè)線程對(duì)應(yīng)一個(gè)消息隊(duì)列

4. 線程，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í)并沒有調(diào)用Looper.prepare()也沒有報(bào)錯(cuò)呢?

這是因?yàn)閁I線程是主線程，系統(tǒng)會(huì)自動(dòng)調(diào)用Looper.prepareMainLooper()方法創(chuàng)建主線程的Looper和消息隊(duì)列MessageQueue

Message的發(fā)送和處理過程

在討論完Looper、線程、消息隊(duì)列這三者的關(guān)系之后我們再來瞅瞅Android消息機(jī)制中對(duì)于Message的發(fā)送和處理。

平常最常用的方式:

handler.sendMessage(message)——>發(fā)送消息

handleMessage(Message msg){}——>處理消息

先來分析消息的入隊(duì)。

Handler可以通過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)參見代碼第25行此處的this就是當(dāng)前Handler對(duì)象本身。在這就指明了該msg的來源——它是由哪個(gè)Handler發(fā)出的，與此同時(shí)也指明了該msg的歸宿——它該由哪個(gè)Handler處理。不難發(fā)現(xiàn)，哪個(gè)Handler發(fā)出了消息就由哪個(gè)Handler負(fù)責(zé)處理。

• 第二步：

將消息放入消息隊(duì)列中，請(qǐng)參見代碼第29行在enqueueMessage(msg,uptimeMillis)中將消息Message存放進(jìn)消息隊(duì)列中，距離觸發(fā)時(shí)間最短的message排在隊(duì)列最前面,同理距離觸發(fā)時(shí)間最長的message排在隊(duì)列的最尾端。若調(diào)用sendMessageAtFrontOfQueue()方法發(fā)送消息它會(huì)直接調(diào)用該enqueueMessage(msg,uptimeMillis)讓消息入隊(duì)只不過時(shí)間為延遲時(shí)間為0，也就是說該消息會(huì)被插入到消息隊(duì)列頭部優(yōu)先得到執(zhí)行。直覺告訴我們此處的消息隊(duì)列mQueue就是該線程所對(duì)應(yīng)的消息隊(duì)列?？墒枪庥兄庇X是不夠的甚至是不可靠的。我們再回過頭瞅瞅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)參見代碼第10行

(2) 利用Looper的消息隊(duì)列為mQueue賦值，請(qǐng)參見代碼第15行

(3) 為mCallback賦值，，請(qǐng)參見代碼第16行

(4) 為mAsynchronous賦值，，請(qǐng)參見代碼第17行

嗯哼，看到了吧，這個(gè)mQueue就是從Looper中取出來的。在之前我們也詳細(xì)地分析了Looper、線程、消息隊(duì)列這三者的一一對(duì)應(yīng)關(guān)系，所以此處的mQueue正是線程所對(duì)應(yīng)的消息隊(duì)列。

看完了消息的入隊(duì)，再來分析消息的出隊(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)參見代碼第13-55行。也就是說在該段代碼中Looper一直在輪詢消息隊(duì)列MessageQueue。假若消息隊(duì)列中沒有未處理的消息(即queue.next()==null)則其進(jìn)入阻塞block狀態(tài)，假若消息隊(duì)列中有待處理消息(即queue.next()!=null)則利用msg.target.dispatchMessage(msg)將該消息派發(fā)至對(duì)應(yīng)的Handler。

到了這，可能有的人會(huì)有一個(gè)疑問：系統(tǒng)怎么知道把消息發(fā)送給哪個(gè)Handler呢?

嘿嘿，還記不記得enqueueMessage()中系統(tǒng)給msg設(shè)置了target從而確定了其目標(biāo)Handler么?嗯哼，所以只要通過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)行了處理，我們來瞅瞅主要的步驟

• ***步：

處理Message的回調(diào)callback，請(qǐng)參見代碼第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)參見代碼第6行

比如執(zhí)行Handler handler=Handler(Callback  callback)時(shí)就會(huì)將callback賦值給mCallback，關(guān)于這點(diǎn)已經(jīng)在介紹Handler構(gòu)造方法時(shí)分析過了，不再贅述。

第三步：

調(diào)用handleMessage()處理消息Message，請(qǐng)參見代碼第10行

handleMessage()的源碼如下：

public void handleMessage(Message msg) {  }

嗯哼，它是一個(gè)空的方法。所以Handler的子類需要覆寫該方法，并在其中處理接收到的消息。

梳理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í)間的長短決定該消息在隊(duì)列中位置。在隊(duì)列中的消息會(huì)依次出隊(duì)得到相應(yīng)的處理。

• Looper負(fù)責(zé)輪詢消息隊(duì)列。

Looper使用其loop()方法一直輪詢消息隊(duì)列，并在消息出隊(duì)時(shí)將其派發(fā)至對(duì)應(yīng)的Handler.

到此，相信大家對(duì)“Android Handler怎么使用”有了更深的了解，不妨來實(shí)際操作一番吧！這里是億速云網(wǎng)站，更多相關(guān)內(nèi)容可以進(jìn)入相關(guān)頻道進(jìn)行查詢，關(guān)注我們，繼續(xù)學(xué)習(xí)！