Android異步消息處理機制掌握,從源碼了解常使用的Handler
1、概述:
大家都知道,在Android中,UI線程是不安全的,更新UI在UI線程中處理,其他耗時工作都不能在該線程執行,相信大家在面試的時候也知道Handler是面試官非常喜歡問的一個問題。同樣我面試的也如此,每次面試前去復習不如寫一遍博客記錄下來更深刻。
2、Handler的簡單使用:
private Handler handler = new Handler(){ @Override public void handleMessage(Message msg) { super.handleMessage(msg); } };
上面這樣使用可能會引起內存泄露的風險,因為當使用內部類(匿名內部類)來創建Handler的時候,Handler隱式持有一個外部類對象(Activity)的引用,而Handler常伴有一個耗時的後臺線程操作,當在後臺線程訪問過程中,Activity不再使用了,那麽它就在特定情況下會被GC回收,但由於這時線程尚未執行完,而該線程持有Handler的引用(不然它怎麽發消息給Handler?),這個Handler又持有Activity的引用,就導致該Activity無法被回收(即內存泄露),直到網絡請求結束(例如圖片下載完畢)。(摘自:https://www.cnblogs.com/xujian2014/p/5025650.html)。今天這篇不是寫該內容的解決方式,具體的解決方案就看這篇文章吧。
3、Looper消息循環:
Handler的發送的消息發送到哪裏,由誰來承載,由誰來發出呢。
Handler發送的消息都發送到MessageQueue,而MessageQueue由Looper創建,進入一個無限循環不斷從該MessageQueue讀取消息並回調處理。
根據上面的描述,我們先來看看Looper的源碼,對於Looper主要有prepare()和loop()兩個方法;
我們經常會在當前線程調用Looper.prepare()和Looper.loop(),首先來看看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的有參構造函數,sThreadLocal是一個ThreadLocal對象,可以在一個線程中存儲變量,我們可以看到sThreadLocal.set(new Looper(quitAllowed))函數往該對象中存儲了一個Looper對象,並在前面判斷該get()方法是否為空,不為空則拋出異常,該異常相信大家都見到過,在同一個線程內調用多次prepare()方法,這就說明了Looper.prepare()方法不能被調用兩次,同時也保證了一個線程中僅有一個Looper對象。
下面我們看Looper的構造方法:
private Looper(boolean quitAllowed) { mQueue = new MessageQueue(quitAllowed); mThread = Thread.currentThread(); }
構造方法創建了一個MessageQueue(消息隊列),同時變量mThread指向當前線程;
好的,上面我們看完了Looper.prepare()的源碼,我們再來看看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(); // Allow overriding a threshold with a system prop. e.g. // adb shell ‘setprop log.looper.1000.main.slow 1 && stop && start‘ final int thresholdOverride = SystemProperties.getInt("log.looper." + Process.myUid() + "." + Thread.currentThread().getName() + ".slow", 0); boolean slowDeliveryDetected = false; 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; long slowDispatchThresholdMs = me.mSlowDispatchThresholdMs; long slowDeliveryThresholdMs = me.mSlowDeliveryThresholdMs; if (thresholdOverride > 0) { slowDispatchThresholdMs = thresholdOverride; slowDeliveryThresholdMs = thresholdOverride; } final boolean logSlowDelivery = (slowDeliveryThresholdMs > 0) && (msg.when > 0); final boolean logSlowDispatch = (slowDispatchThresholdMs > 0); final boolean needStartTime = logSlowDelivery || logSlowDispatch; final boolean needEndTime = logSlowDispatch; if (traceTag != 0 && Trace.isTagEnabled(traceTag)) { Trace.traceBegin(traceTag, msg.target.getTraceName(msg)); } final long dispatchStart = needStartTime ? SystemClock.uptimeMillis() : 0; final long dispatchEnd; try { msg.target.dispatchMessage(msg); dispatchEnd = needEndTime ? SystemClock.uptimeMillis() : 0; } finally { if (traceTag != 0) { Trace.traceEnd(traceTag); } } if (logSlowDelivery) { if (slowDeliveryDetected) { if ((dispatchStart - msg.when) <= 10) { Slog.w(TAG, "Drained"); slowDeliveryDetected = false; } } else { if (showSlowLog(slowDeliveryThresholdMs, msg.when, dispatchStart, "delivery", msg)) { // Once we write a slow delivery log, suppress until the queue drains. slowDeliveryDetected = true; } } } if (logSlowDispatch) { showSlowLog(slowDispatchThresholdMs, dispatchStart, dispatchEnd, "dispatch", msg); } 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(); } }
看源碼,我們可以看到Looper對象是通過myLooper()方法獲取的,該方法也就是上面prepare()方法中說過的sThreadLocal對象調用get()方法獲取到存入進去的Looper對象。繞不繞口繞不繞口我就問你,我都差點沒明白,看下面,就是如此簡單。
public static @Nullable Looper myLooper() { return sThreadLocal.get(); }
1、MessageQueue queue = me.mQueue獲取到該消息隊列;
2、在循環體for(;;)中進入我們前面所說的無限循環;
3、Message msg = queue.next()獲取消息,沒有消息則返回;
4、msg.target.dispatchMessage(msg)把消息給msg.target處理,msg.tartget其實就是發送該msg的Handler對象,解析到Handler的時候就會看到;
總結:Looper兩個靜態方法,一個是prepare(),一個是loop(),prepare()方法主要是綁定當前線程,創建一個Looper對象,且當前線程唯一,同時也創建了一個MessageQueue(消息隊列);loop()方法主要是
循環消息隊列中的Message,並交給msg的target屬性處理。
4、Handler解析:
通常我們使用Handler的時候都會new一個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 " + Thread.currentThread() + " that has not called Looper.prepare()"); } mQueue = mLooper.mQueue; mCallback = callback; mAsynchronous = async; }
同樣,調用的依然是有參構造函數,在if(mLooper == null)裏拋出的異常就是我們經常能遇到的,現在看本質這個異常其實就是當前線程Looper對象為null,我們通常解決就是在該線程中調用Looper.prepare()
和Looper.loop()方法;mQueue = mLooper.mQueue獲取到Looper對象中的消息隊列,那麽我們的Handler就跟MessageQueue消息隊列關聯上了。
OK,Handler我們知道是如何構造的了,我們看看我們常用的sendMessage(Message msg)方法是如何工作的,ctrl+左鍵進去看看源碼:
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); }
private boolean enqueueMessage(MessageQueue queue, Message msg, long uptimeMillis) { msg.target = this; if (mAsynchronous) { msg.setAsynchronous(true); } return queue.enqueueMessage(msg, uptimeMillis); }
很明顯,是調用的這些方法。sendMessageAtTime(Message msg, long uptimeMillis)方法判斷了MessageQueue(消息隊列)對象是否null;重點來了,enqueueMessage(MessageQueue queue, Message msg, long uptimeMillis)
中的msg.target = this,剛剛我們提到的,將msg給msg.target屬性處理,我們這裏能看到,msg.target指向了this,也就是我們的Handler,所以前面說的,msg.target屬性其實就是當前消息的Handler對象,那麽前面的流程就是looper
循環處理MessageQueue(消息隊列),獲取到消息就給發送該消息的Handler對象的dispatchMessage()方法處理;
so,我們來看看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是否為null,不為null,則執行該回調,否則執行handleMessage(msg)方法,我們使用sendMessage()方法的時候,是沒有給到callback的,那麽我們就是調用handleMessage()方法,看看該方法實現了什麽:
/** * Subclasses must implement this to receive messages. */ public void handleMessage(Message msg) { }
handleMessage(Message msg)是一個空方法,沒錯,該方法是由我們自己實現的,上面我們創建的Handler對象實現了handlerMessage(Message msg)方法,就是調用的我們自己實現的這個方法。
什麽時候會調用handleCallback(Message msg)方法呢,其實handler.post(new Runnable{})就是回調的我們這個方法,看看 post(Runnable run) 方法的源碼吧:
public final boolean post(Runnable r) { return sendMessageDelayed(getPostMessage(r), 0); } public final boolean sendMessageDelayed(Message msg, long delayMillis) { if (delayMillis < 0) { delayMillis = 0; } return sendMessageAtTime(msg, SystemClock.uptimeMillis() + delayMillis); }
我們可以看到,post方法其實還是調用了我們前面所看到的sendMessageDelayed()方法,不同的是,我們處理了一下傳進來的Runnable對象,我們看看getPostMessage(r)方法:
private static Message getPostMessage(Runnable r) { Message m = Message.obtain(); m.callback = r; return m; }
這裏我們創建了一個Message對象,該對象的callback屬性指向我們傳進來的Runnable對象,so,前面我們看到的判空部分,handleCallback(Message msg) 那麽就會執行,
private static void handleCallback(Message message) { message.callback.run(); }
所以,Runnable其實不是一個新的線程在工作,只是作為一個回調實現;
總結:
整個異步消息處理流程其實並不復雜,明白他們之間的關系就很容易理解,我來畫個圖更好的理解下這整個流程:
Ok,大概就是這樣理解的,網上大佬們的解析也很多,借鑒了很多大佬的語言描述,感激不盡。這裏只是簡單記錄我對知識的理解,如有錯誤請指出。
Android異步消息處理機制掌握,從源碼了解常使用的Handler