從 sendEmptyMessage 開始，一步步解剖Handler
工做的時候發現本身對於不少東西用起來駕輕就熟，原理機制也背誦的倒背如流，可是一問到源碼腦子就....瓦特了！因此最近準備從頭開始學習源碼，學習大神們優秀的思想！緩存
本文是對Handler機制的源碼分析，目的是爲了可以從源碼角度一點點的理解Handler機制，裏面會出現大量的源碼，因此會比較枯燥，可是隻要認真看完，相信你必定會對Handler機制的實現方法有更加清晰的認識 Handler是用起來很是簡單！安全
private Handler handler = new Handler(){
@Override
public void handleMessage(Message msg) {
super.handleMessage(msg);
//處理接收到的消息
}
};
複製代碼
初始化以後，在子線程進行完耗時操做以後，使用bash
handler.sendEmptyMessage(what)
複製代碼
好了，如今就從sendEmptyMessage 方法開始，一步步的解析handler整個工做流程 — — 注意，Handler開始向消息隊列發送消息了；
點進去以後，咱們會發現，sendEmptyMessage 、sendMessage 最終都是在調用 sendMessageAtTime 方法，將發送的消息放入messgeQueue；須要注意的一點是，sendMessageDelayed方法中，已經將 delayMillis 延遲時間轉換成了 SystemClock.uptimeMillis() + delayMillis，指的是該消息被取出來執行的時間，這一點會在MessageQueue中顯的比較重要app
//直接調用 sendEmptyMessageDelayed 方法
public final boolean sendEmptyMessage(int what){
//直接調用 sendEmptyMessageDelayed 方法
return sendEmptyMessageDelayed(what, 0);
}
// 被sendEmptyMessage方法調用，delayMillis 爲0，同時將參數轉換成message後調用 sendMessageDelayed 此處已經和 sendMessage方法調用同一個路徑了
public final boolean sendEmptyMessageDelayed(int what, long delayMillis) {
//將參數進行復制，轉換成 Message
Message msg = Message.obtain();
msg.what = what;
return sendMessageDelayed(msg, delayMillis);
}
public final boolean sendMessageDelayed(Message msg, long delayMillis)
{
if (delayMillis < 0) {
delayMillis = 0;
}
//此處的 SystemClock.uptimeMillis() + delayMillis 用來計算消息的執行時間
return sendMessageAtTime(msg, SystemClock.uptimeMillis() + delayMillis);
}
//最終，發送消息的方法都會走到這裏，將消息放入MessageQueue
public boolean sendMessageAtTime(Message msg, long uptimeMillis) {
//mQueue 是從哪裏來的？此處先放下，待會回頭來分析
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);
}
複製代碼
在sendMessageAtTime 方法中，消息放入了咱們熟知的 handler機制中的MessageQueue；如今咱們分析 sendMessageAtTime 方法，這個方法中主要執行了一個 MessageQueue 的非空判斷，而後就直接執行了enqueueMessage方法，mQueue 是從哪裏來的呢？爲了邏輯的連貫性，此處先不分析，會放到下面進行分析，這裏先接着enqueueMessage進行分析；less
private boolean enqueueMessage(MessageQueue queue, Message msg, long uptimeMillis) {
//將此Hanlder賦值給Message，用來在分發消息時候接收消息的hanlder
msg.target = this;
if (mAsynchronous) {//是不是異步，此處爲false，不會執行
msg.setAsynchronous(true);
}
return queue.enqueueMessage(msg, uptimeMillis);
}
複製代碼
enqueueMessage方法也很簡單，主要就是將此Hanlder賦值給Message，用來在分發消息時候接收消息的hanlder，而後將消息交給messageQueue來處理； 好了，到這裏，咱們開始進入messageQueue 了-- 固然，並非Handler源碼已經分析完畢了，只是我按照代碼的腳步一步一步的走下去，目的是爲了讓本身能清除的看到Handler機制走過的全部道路，以便於最終可以完整、清晰的理解Handler消息機制，最後仍是會回到Handler中的；異步
如今，咱們進入MessageQueue — — 注意：Handler發送的消息，要進入消息隊列了；
直接找到 Handler中 enqueueMessage方法裏面執行的MessageQueue方法， enqueueMessage(Message msg, long when)；async
boolean enqueueMessage(Message msg, long when) {
// msg.target ，這個參數是否是很熟悉，對的，就是在Handler進入MessageQueue以前的enqueueMessage方法中賦值的，是當前的Handler
if (msg.target == null) {
throw new IllegalArgumentException("Message must have a target.");
}
if (msg.isInUse()) {//此處判斷當前Message是不是被執行了，一個消息不能被執行使用兩次
throw new IllegalStateException(msg + " This message is already in use.");
}
synchronized (this) {
if (mQuitting) {//mQuitting默認一直是false，只有執行quit 方法，而且該MessageQueue能被安全退出的時候回被賦值爲true，主線程中是不能被退出的，因此一直都是false，所以不會被執行進來，直接跳過去
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;
//此處進行判斷，若是mMessages爲Null（p == null），則表示如今消息隊列裏面已經沒有消息緩存了，能夠直接放入消息隊列的最頂端，同時喚醒正在阻塞的消息隊列
//when==0，表示該消息須要被當即執行
//若是mMessages！=null,表示目前消息隊列裏面已經有消息了，此時比較消息隊列裏最頂端要被取出來的消息使用時間，若是when < p.when，表示新傳入的消息執行的時間在消息隊列中最靠前，因此也放到頂端（注意：mMessages 是一個鏈表結構，且mMessages是該鏈表中最頂端的消息）
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 {
//若是不知足以上三個條件，就把該消息放到隊列裏對應的位置
//是否須要喚醒此時的阻塞
//msg.isAsynchronous();這個是否是很熟悉？沒錯，就是在Handler的enqueueMessage方法中，有這麼一行代碼： msg.setAsynchronous(true);在這裏能夠看到，若是message是Asynchronous的話，纔會須要喚醒阻塞的線程
needWake = mBlocked && p.target == null && msg.isAsynchronous();
Message prev;
//下面一個循環，將傳入進來的消息根據執行的時間 when 插入到消息隊列中指定的位置
for (;;) {
prev = p;
p = p.next;
if (p == null || when < p.when) {
//此處，（when < p.when）表示最新傳入進來等待插入消息隊列的消息執行時間早於當前這個消息的執行時間，則將最新傳入的消息插入這個位置，
//（p==null）當隊列中的消息已經遍歷完成，每一個消息的執行時間都早於最新傳入的消息，那就把這個消息放到最後
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;
}
複製代碼
消息已進入隊列，開始等待被取出消費了 — — 注意，Looper開始表演了；
到這裏，消息隊列的插入已經完成了，根據咱們熟知的Handler機制，這時候就要開始等待隊列中的消息被取出來執行了；可是消息是在哪裏被取出來進行執行的呢，到這裏好像代碼已經斷掉了，根本沒有找到下一步調用的方法啊！ 彆着急，Hanlder的使用除了sendEmptyMessage的調用，還有初始化操做啊，咱們點進去以後，發現最終會執行到這個構造方法；ide
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 被賦值，Hanlder和MessageQueue關聯起來了
mQueue = mLooper.mQueue;
mCallback = callback;
mAsynchronous = async;
}
複製代碼
還記得我再Handler中爲了避免打斷邏輯連貫性忽略掉的那一行代碼嗎？oop
MessageQueue queue = mQueue;
複製代碼
這個MessageQueue 是從哪裏來的呢，在這裏咱們已經找到了賦值地方，在構造方法中，mQueue被賦值，而且來自Looper，這裏，已經將Hanlder、MessageQueue、Looper關聯起來了；源碼分析
如今開始進入Looper了； Looper自己是一個輪詢器，用來從消息隊列中取出消息；咱們知道，Handler是在主線程進行初始化並執行的，所以，在Handler構造方法中的代碼：
mLooper = Looper.myLooper();
mQueue = mLooper.mQueue;
mCallback = callback;
mAsynchronous = async;
複製代碼
咱們打開 Looper.myLooper()，發現只有一行代碼，mLooper 來自ThreadLocal；而且在在sThreadLocal 上發現 是在prepare（）中進行的初始化
// sThreadLocal.get() will return null unless you've called prepare(). static final ThreadLocal<Looper> sThreadLocal = new ThreadLocal<Looper>(); ...... public static @Nullable Looper myLooper() { return sThreadLocal.get(); } 複製代碼
咱們來看一下prepare()方法；
/** 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
* {@link #loop()} after calling this method, and end it by calling
* {@link #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));
}
/**
* Initialize the current thread as a looper, marking it as an
* application's main looper. The main looper for your application * is created by the Android environment, so you should never need * to call this function yourself. See also: {@link #prepare()} */ public static void prepareMainLooper() { prepare(false); synchronized (Looper.class) { if (sMainLooper != null) { throw new IllegalStateException("The main Looper has already been prepared."); } sMainLooper = myLooper(); } } private Looper(boolean quitAllowed) { mQueue = new MessageQueue(quitAllowed); mThread = Thread.currentThread(); } 複製代碼
好了，經過這三個方法，咱們知道 prepare（）和loop()方法是同步出現的，而且prepare（）中進行了Looper的初始化，此時也找到了MessageQueue的初始化；
看到這裏，對於不熟悉Looper和Handler機制的童鞋來講，Handler裏面也沒有調用初始化方法啊！！！！
此處線索已掉線，你們散了吧！
恩，我再想一想辦法，串起來！
Handler自己是在主線程中初始化的，而且ThreadLocal只能在當前線程中才能獲取到裏面的信息，因此初始化操做確定是在 主線程完成的；所以，咱們在ActivityThread 的main方法中，找到了Looper的初始化和啓動； 還有一個方法prepareMainLooper（），這個方法一樣是Looper的初始化方法，而且做爲Application的主線程中的Looper使用，而且建議咱們本身永遠不要調用； ok，這個意思大概就是咱們能在主線程中找到初始化方法prepareMainLooper（）吧。。。。 最後，確實是在ActivityThread 的main方法中找到了Looper的初始化操做；
public static void main(String[] args) {
//省略掉部分不相關代碼
//.........
Looper.prepareMainLooper();
//..........
Looper.loop();
throw new RuntimeException("Main thread loop unexpectedly exited");
}
複製代碼
到這裏，Looper終於開始啓動循環了；
喜大普奔，來看看loop是怎麼循環的吧
public static void loop() {
//此處確保已經初始化，調用過prepare方法
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 (;;) {
//第一步就是從MessageQueue中取出最頂端的消息,next（）方法可能會被阻塞
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
//僅僅打印log，跳過
final Printer logging = me.mLogging;
if (logging != null) {
logging.println(">>>>> Dispatching to " + msg.target + " " +
msg.callback + ": " + msg.what);
}
final long slowDispatchThresholdMs = me.mSlowDispatchThresholdMs;
final long traceTag = me.mTraceTag;
if (traceTag != 0 && Trace.isTagEnabled(traceTag)) {
Trace.traceBegin(traceTag, msg.target.getTraceName(msg));
}
final long start = (slowDispatchThresholdMs == 0) ? 0 : SystemClock.uptimeMillis();
final long end;
//到這裏，開始對取出來的消息進行分發
// msg.target 這個是否是很熟悉，沒錯，就是Handler，在Handler的enqueueMessage方法中進行的賦值，目的就是用來判斷當前消息處理的Hanlder，在此處終於顯示出來他的做用了，沒錯，就是調用了Hanlder的dispatchMessage方法，在此處，全部的流程終於又回到了Handler，分發完成以後，loop（）方法的代碼對於Hanlder已經不是很重要了，能夠直接跳過不看
try {
msg.target.dispatchMessage(msg);
end = (slowDispatchThresholdMs == 0) ? 0 : SystemClock.uptimeMillis();
} finally {
if (traceTag != 0) {
Trace.traceEnd(traceTag);
}
}
if (slowDispatchThresholdMs > 0) {
final long time = end - start;
if (time > slowDispatchThresholdMs) {
Slog.w(TAG, "Dispatch took " + time + "ms on "
+ Thread.currentThread().getName() + ", h=" +
msg.target + " cb=" + msg.callback + " msg=" + msg.what);
}
}
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(); } } 複製代碼
如今，咱們從新回到Handler
繞了半天，終於回來了 趕忙看看，dispatchMessage(msg)這個方法；
/**
* Handle system messages here.
*/
public void dispatchMessage(Message msg) {
if (msg.callback != null) {
handleCallback(msg);
} else {
if (mCallback != null) {
if (mCallback.handleMessage(msg)) {
return;
}
}
//整了半天，終於出現了
handleMessage(msg);
}
}
複製代碼
handleMessage(msg);方法終於出現了有木有，這個就是咱們處裏Handler方法的地方；到此，終於把Handler機制的源碼過了一遍！
再補充一下：
在Looper.loop()方法中，從消息列表MessageQueue中取出Message的方法 queue.next()是一個可阻塞的方法，阻塞也是
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();
}
//一個navtie方法，nextPollTimeoutMillis表示阻塞時間，0阻塞，-1表明意義阻塞，直到被喚醒，在消息隊列裏面沒有消息的時候，就會一直阻塞下去，直到被喚醒，這也是loop方法不會執行完的緣由，由於在消息爲空的時候就被阻塞在這裏了，直到有消息進來喚醒線程，調用nativeWake（）喚醒線程纔會繼續走下去
nativePollOnce(ptr, nextPollTimeoutMillis);
synchronized (this) {
// 次數開始獲取下一條Message，若是有就返回
final long now = SystemClock.uptimeMillis();
Message prevMsg = null;
Message msg = mMessages;
if (msg != null && msg.target == null) {
// 經過循環，返回當前處於隊列最底部，須要被取出來的消息
do {
prevMsg = msg;
msg = msg.next;
} while (msg != null && !msg.isAsynchronous());
}
if (msg != null) {
//msg.when表示當前消息須要被執行的時間，now < msg.when，表示當前時間還沒到隊列底部部（最後一條）消息被執行的時間
//隊列執行是先進先出，因此此時的消息位於隊列的最底部，會被首先被取出來的，這個位置我統一稱爲底部（方便理解）
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 {
// 若是此時消息應該被當即執行
mBlocked = false;
if (prevMsg != null) {
//若是消息隊列不只僅有一個消息，則此時將倒數第二條消息的下一條消息只想meg.next（是null）
prevMsg.next = msg.next;
} else {
//此時表示僅有一條消息，被取出來後mMessages 就爲null
mMessages = msg.next;
}
msg.next = null;
if (DEBUG) Log.v(TAG, "Returning message: " + msg);
msg.markInUse();
//此時返回被取出來的消息，next（）方法結束
return msg;
}
} else {
// 若是此時消息隊列裏面已經沒有消息了，則等待時間更爲-1
nextPollTimeoutMillis = -1;
}
// 是不是退出狀態，主線程裏面不會有退出，mQuitting 恆爲false，不會執行
if (mQuitting) {
dispose();
return null;
}
//到這裏正常的Message消息已經結束了，可是google大大巧妙的設計了另外一種消息類型，IdleHandler，這種消息類型並不會定義執行時間，而是會在Message 消息阻塞時，利用阻塞的空閒時間來執行
// 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.
//此處獲取IdleHandler的數量；
if (pendingIdleHandlerCount < 0
&& (mMessages == null || now < mMessages.when)) {
pendingIdleHandlerCount = mIdleHandlers.size();
}
//若是沒有IdleHandler消息，則繼續等待，再也不向下執行
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.
//若是有IdleHandler消息，則取出來執行了，並移出已經執行的消息
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;
//當即執行 IdleHandler 再也不阻塞線程
nextPollTimeoutMillis = 0;
}
}
複製代碼
最後總結一下
Handler機制到這裏已經徹底串聯起來了，整個流程最後總結起來其實確實很簡單： 一、ActivityThread中，初始化Looper，Looper初始化時候會建立MessageQueue；Looper初始化完成以後調用loop()開啓死循環，不斷取出MessageQueue中的消息，並分發出去 二、Handler初始化後，將Looper，MessageQueue、Handler關聯起來，並等待接受來自MessageQueue中的消息 三、Handler經過send相關方法，發送消息到MessageQueue，MessageQueue經過Message信息，將Message放到隊列中相應位置，等待被取出使用； 四、Looper取出消息，並根據Message中的信息分發出去，給相應的Handler使用，此時Hanlder接收到消息，咱們開始處理消息，進行更新UI等主線程的操做
相關文章
- 1. 一步一步，從零開始開發asp.net
- 2. 一步一步學Remoting之一：從簡單開始
- 3. Android JNI的第一步——從HelloWorld開始
- 4. Android教程-從零開始一步一步接入SDK
- 5. 一步一步教你從零開始寫C語言鏈表
- 6. 從0開始一步一步配置SQL Server 2000 數據庫同步
- 7. handler異步
- 8. 從零開始一步一步寫一個簡單的Virtual DOM實現
- 9. Android從零開始之一步一步教你實現聯繫人功能（一）
- 10. 從零開始水安卓——UI初步
- 更多相關文章...
- • MySQL下載步驟詳解 - MySQL教程
- • 您已經學習了 ASP，下一步呢？ - ASP 教程
- • PHP開發工具
- • RxJava操作符（一）Creating Observables
相關標籤/搜索
每日一句
-
每一个你不满意的现在，都有一个你没有努力的曾经。
歡迎關注本站公眾號,獲取更多信息
