前言：
由于Handler和Binder是Android開發的倆大利器之一，所以有必要來深入講解一下Handler，關于Binder可以參考我上一篇博客《IPC機制 Binder》，廢話不多說，今天我將圖文并茂，一節一節解剖Handler，一節一節的總結Handler相關知識點，
一:Handler的定義
Handler的定義我覺得可以用一句話高度概括，那就是：Handler是Android提供的一套完整的訊息傳遞機制，
二:Handler的作用
我們都知道，在Android種，一般情況下View是不能在作業執行緒更新的，除了surfaceview(特殊)，那么如果我們非要在作業執行緒中更新UI那該怎么辦了，那只能借助handler了，所以handler的作用就是：在多執行緒的應用場景中，將作業執行緒中需更新UI的操作資訊傳遞到UI主執行緒，從而間接的實作作業執行緒對UI的更新處理，最終實作異步訊息的處理，
三:為什么要使用Handler訊息傳遞機制
我們既然知道了使用handler可以間接實作作業執行緒對UI的更新，那你是否奇怪，為什么更新非要使用Handler，而不能是其它，那是因為，多個執行緒并發更新UI的同時要保證執行緒安全，詳細描述見下表(圖片來自：https://www.jianshu.com/p/f0b23ee5a922)
四:Handler必須掌握的相關概念
關于Handler的先關概念主要包括如下4大點，即 Handler、Message、Message Queue、Looper，希望大家先熟悉相關概念，下圖大致高度介紹相關概念:(圖片來自:https://www.jianshu.com/p/f0b23ee5a922)
五:Handler作業原理和原始碼分析
在第四步我們主要明白了幾個相關概念，接下來，會深層次的揭破他們的原始碼，從原始碼里搞清他們之間的作業關系和作業原理，
5.1：Handler Looper Message 關系是什么？
5.1.1分析Handler
首先我們來分析分析一下 Handler 的用法，我們知道，要創建一個 Handler 物件
非常的簡單明了，直接進行 new 一個物件即可，但是這里會隱
藏著什么注意點呢，現在可以試著寫一下下面的一小段代碼，然后自己運行看看：
public class MainActivity extends AppCompatActivity{
private Handler mHandler0;
private Handler mHandler1;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
mHandler0 = new Handler();
new Thread(new Runnable() {
@Override
public void run() {
mHandler1 = new Handler();
}
}).start();
}
這一小段程式代碼主要創建了兩個 Handler 物件，其中，一個在主執行緒中創建，
而另外一個則在子執行緒中創建，現在運行一下程式，則你會發現，在子執行緒創建
的Handler物件竟然會導致程式直接崩潰，奔潰例外資訊如下：
2021-07-23 12:06:19.034 14393-14451/com.pcl.lpr.debug E/AndroidRuntime: FATAL EXCEPTION: Thread-10
Process: com.pcl.lpr.debug, PID: 14393
java.lang.RuntimeException: Can't create handler inside thread Thread[Thread-10,5,main] that has not called Looper.prepare()
at android.os.Handler.<init>(Handler.java:207)
at android.os.Handler.<init>(Handler.java:119)
at com.pcl.ocr.ui.TestActivity$1.run(TestActivity.java:23)
at java.lang.Thread.run(Thread.java:919)
提示的錯誤竟然是：Can't create handler inside thread that has not called Looper.prepare()
于是我們按照 logcat 中所說，在子執行緒中加入 Looper.prepare(),即代碼如下：
public class TestActivity extends AppCompatActivity {
private Handler mHandler0;
private Handler mHandler1;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_test);
mHandler0 = new Handler();
new Thread(new Runnable() {
@Override
public void run() {
Looper.prepare();
mHandler1 = new Handler();
}
}).start();
}
}
再次運行一下程式，發現程式不會再崩潰了，可是，單單只加這句Looper.prepare()是否就能解決問題了，我們探討問題，就要知其然，才能了解得更多，我們還是先分析一下原始碼吧，看看為什么在子執行緒中沒有加Looper.prepare()就會出現崩潰，而主執行緒中為什么不用加這句代碼？我們看下Handler()建構式：
public Handler() {
this(null, false);
}
建構式非常簡單,直接呼叫 this(null, false)，于是接著看其呼叫的函式:
public Handler(Callback callback, boolean async) {
if (FIND_POTENTIAL_LEAKS) {
final Class<? extends Handler> klass = getClass();
if ((klass.isAnonymousClass() || klass.isMemberClass() || kla
ss.isLocalClass()) &&
(klass.getModifiers() & Modifier.STATIC) == 0) {
Log.w(TAG, "The following Handler class should be static o
r leaks might occur: " +
klass.getCanonicalName());
}
}
mLooper = Looper.myLooper();
if (mLooper == null) {
throw new RuntimeException(
"Can't create handler inside thread that has not called Lo
oper.prepare()");
}
mQueue = mLooper.mQueue;mCallback = callback;
mAsynchronous = async;
}
不難看出，原始碼中呼叫了 mLooper = Looper.myLooper()方法獲取一個 Looper物件，若此時 Looper 物件為 null，則會直接拋出一個“Can't create handlerinside thread that has not called Looper.prepare()”例外，那什么時候造成 mLooper 是為空呢？那就接著分析 Looper.myLooper()，
public static Looper myLooper() {
return sThreadLocal.get();
}
這個方法在 sThreadLocal 變數中直接取出 Looper 物件，若 sThreadLocal 變數中存在 Looper 物件，則直接回傳，若不存在，則直接回傳 null，而 sThreadLocal變數是什么呢？
static final ThreadLocat<Looper> sThreadLocal = new ThreadLocal<Looper>();
它是本地執行緒變數，存放在 Looper 物件，由這也可看出，每個執行緒只有存有一個 Looper 物件，可是，是在哪里給 sThreadLocal 設定 Looper 的呢，通過前面的試驗，我們不難猜到，應該是在Looper.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));}
由此看到，我們的判斷是正確的，在 Looper.prepare()方法中給 sThreadLocal變數設定 Looper 物件，這樣也就理解了為什么要先呼叫 Looper.prepare()方法，才能創建 Handler 物件，才不會導致崩潰，但是，仔細想想，為什么主執行緒就不用呼叫呢？不要急，我們接著分析一下主執行緒，我們查看一下ActivityThread中的 main()方法，代碼如下：
public static void main(String[] args) {
SamplingProfilerIntegration.start();// CloseGuard defaults to true and can be quite spammy
// disable it here, but selectively enable it later (via
// StrictMode) on debug builds, but using DropBox, not logs.
CloseGuard.setEnabled(false);
Environment.initForCurrentUser();
// Set the reporter for event logging in libcore
EventLogger.setReporter(new EventLoggingReporter());
Security.addProvider(new AndroidKeyStoreProvider());
// Make sure TrustedCertificateStore looks in the right place for CAcertificates
final File configDir = Environment.getUserConfigDirectory(UserHandle.myUserId());
TrustedCertificateStore.setDefaultUserDirectory(configDir);
Process.setArgV0("<pre-initialized>");
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"));
}
Looper.loop();
throw new RuntimeException("Main thread loop unexpectedly exited");
}
代碼中呼叫了 Looper.prepareMainLooper()方法，而這個方法又會繼續呼叫了Looper.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();
}}
分析到這里已經真相大白，主執行緒中 google 工程師已經自動幫我們創建了一個Looper 物件了，因而我們不再需要手動再呼叫 Looper.prepare()再創建，而子執行緒中，因為沒有自動幫我們創建 Looper 物件，因此需要我們手動添加，呼叫方法是 Looper.prepare()，這樣，我們才能正確地創建 Handler 物件，
5.1.2發送訊息
當我們正確的創建 Handler 物件后，接下來我們來了解一下怎么發送訊息，有一點基礎的朋友肯定對這個方法已經了如指掌了，具體是先創建出一個 Message物件，然后可以利用一些方法，如 setData()或者使用 arg 引數等方式來存放資料于訊息中，再借助 Handler 物件將訊息發送出去就可以了，
new Thread(new Runnable() {
@Override
public void run() {
Message msg = Message.obtain();
msg.arg1 = 1;
msg.arg2 = 2;
Bundle bundle = new Bundle();
bundle.putChar("key", 'v');
bundle.putString("key","value");
msg.setData(bundle);
mHandler0.sendMessage(msg);
}
}).start();
通過 Message 物件進行傳遞訊息，在訊息中添加各種資料，之后訊息通過mHandler0 進行傳遞，之后我們再利用 Handler 中的 handleMessage()方法將此時傳遞的 Message 進行捕獲出來，再分析得到存盤在 msg 中的資料，但是，這個流程到底是怎么樣的呢？具體我們還是來分析一下原始碼，首先分析一下發送方法sendMessage():
public final boolean sendMessage(Message msg){
return sendMessageDelayed(msg, 0);
}
通過呼叫 sendMessageDelayed(msg, 0)方法:
public final boolean sendMessageDelayed(Message msg, long delayMillis){
if (delayMillis < 0) {
delayMillis = 0;
}
return sendMessageAtTime(msg, SystemClock.uptimeMillis() + delayMillis);
}
再能過呼叫 sendMessageDelayed(Message msg, long delayMillis),方法中第一個引數是指發送的訊息 msg,第二個引數是指延遲多少毫秒發送，我們著重看一下此方法：
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);
}
由這里可以分析得出，原來訊息 Message 物件是建立一個訊息佇列 MessageQueue, 這個物件MessageQueue 由 mQueue 賦值，而由原始碼分析得出 mQueue =mLooper.mQueue，而 mLooper 則是 Looper 物件，我們由上面已經知道，每個執行緒只有一個 Looper，因此，一個 Looper 也就對應了一個 MessageQueue 物件，之后呼叫 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);
}
方 法 通 過 調 用 MessageQueue 的 enqueueMessage(Message msg, long uptimeMills)方法：
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("MessageQueue", 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;
}
首先要知道，原始碼中用 mMessages 代表當前等待處理的訊息，MessageQueue 也沒有使用一個集合保存所有的訊息，觀察中間的代碼部分，佇列中根據時間 when來時間排序，這個時間也就是我們傳進來延遲的時間 uptimeMills 引數，之后再根據時間的順序呼叫 msg.next,從而指定下一個將要處理的訊息是什么，如果只是通過 sendMessageAtFrontOfQueue()方法來發送訊息
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);
}
它也是直接呼叫 enqueueMessage()進行入隊，但沒有延遲時間，此時會將傳遞的此訊息直接添加到隊頭處，現在入隊操作已經了解得差不多了，接下來應該來了解一下出隊操作，那么出隊在哪里進行的呢，不要忘記 MessageQueue 物件是在 Looper 中賦值，因此我們可以在 Looper 類中找，來看一看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
Printer logging = me.mLogging;
if (logging != null) {
logging.println(">>Dispatching to " + msg.target + " " +msg.callback + ": " + msg.what);
}
msg.target.dispatchMessage(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();
}
}
代碼比較多，我們只挑重要的分析一下，我們可以看到下面的代碼用 for(;;)進入了一個死回圈，之后不斷的從 MessageQueue 物件 queue 中取出訊息 msg，而我們不難知道，此時的 next()就是進行佇列的出隊方法，next()方法代碼有點長，有興趣的話可以自行翻閱查看，主要邏輯是判斷當前的 MessageQueue 是否存在待處理的 mMessages 訊息，如果有，則將這個訊息出隊，然后讓下一個消成為 mMessages，否則就進入一個阻塞狀態，一直等到有新的訊息入隊喚醒，回看 loop()方法，可以發現當執行 next()方法后會執行msg.target.dispatchMessage(msg)方法，而不難看出，此時 msg.target 就是Handler 物件，繼續看一下 dispatchMessage()方法：
public void dispatchMessage(Message msg) {
if (msg.callback != null) {
handleCallback(msg);
} else {
if (mCallback != null) {
if (mCallback.handleMessage(msg)) {
return;
}
}
handleMessage(msg);
}
}
先進行判斷 mCallback 是否為空，若不為空則呼叫 mCallback 的 handleMessage()方法，否則直接呼叫 handleMessage()方法，并將訊息作為引數傳出去，這樣我們就完全一目了然，為什么我們要使用handleMessage()來捕獲我們之前傳遞過去的資訊，現在我們根據上面的理解，不難寫出異步訊息處理機制的執行緒了，
class myThread extends Thread{
public Handler myHandler;
@Override
public void run() {
Looper.prepare();
myHandler = new Handler(){
@Override
public void handleMessage(Message msg) {
super.handleMessage(msg);
//處理訊息
}
};
Looper.loop();
}
}
當然除了發送訊息外，還有以下幾個方法可以在子執行緒中進行 UI 操作：
- View 的 post()方法
- Handler 的 post()方法
- Activity 的 runOnUiThread()方法
其實這幾個方法的本質都是一樣的，只要我們勤于查看這幾個方法的原始碼，不難
看出最后呼叫的也是 Handler 機制，也是借用了異步訊息處理機制來實作的，
5.1.3:總結
通過上面對異步訊息處理執行緒的講解，我們不難真正地理解到了 Handler、Looper以及 Message 之間的關系，概括性來說，Looper 負責的是創建一個 MessageQueue物件，然后進入到一個無限回圈體中不斷取出訊息，而這些訊息都是由一個或者多個 Handler 進行創建處理，
5.2:Messagequeue 的資料結構是什么？為什么要用這個資料結構？
5.2.1:為什么要用 Message Queue
為什么要用 Message Queue，我覺得要從一下十個方面考慮：
解耦
在專案啟動之初來預測將來專案會碰到什么需求，是極其困難的，訊息佇列在處理程序中間插入了一個隱含的、基于資料的介面層，兩邊的處理程序都要實作這一介面，這允許你獨立的擴展或修改兩邊的處理程序，只要確保它們遵守同樣的介面約束.冗余
有些情況下，處理資料的程序會失敗，除非資料被持久化，否則將造成丟失，訊息佇列把資料進行持久化直到它們已經被完全處理，通過這一方式規避了資料丟失風險，在被許多訊息佇列所采用的”插入-獲取-洗掉”范式中，在把一個訊息從佇列中洗掉之前，需要你的處理程序明確的指出該訊息已經被處理完畢，確保你的資料被安全的保存直到你使用完畢，擴展性
因為訊息佇列解耦了你的處理程序，所以增大訊息入隊和處理的頻率是很容易的；只要另外增加處理程序即可，不需要改變代碼、不需要調節引數，擴展就像調大電力按鈕一樣簡單，靈活性 & 峰值處理能力
在訪問量劇增的情況下，應用仍然需要繼續發揮作用，但是這樣的突發流量并不常見；如果為以能處理這類峰值訪問為標準來投入資源隨時待命無疑是巨大的浪費，使用訊息佇列能夠使關鍵組件頂住突發的訪問壓力，而不會因為突發的超負荷的請求而完全，
崩潰，可恢復性
當體系的一部分組件失效，不會影響到整個系統，訊息佇列降低了行程間的耦合度，所以即使一個處理訊息的行程掛掉，加入佇列中的訊息仍然可以在系統恢復后被處理，而這種允許重試或者延后處理請求的能力通常是造就一個略感不便的用戶和一個沮喪透頂的用戶之間的區別，送達保證
訊息佇列提供的冗余機制保證了訊息能被實際的處理，只要一個行程讀取了該佇列即可，在此基礎上，IronMQ 提供了一個”只送達一次”保證，無論有多少行程在從佇列中領取資料，每一個訊息只能被處理一次，這之所以成為可能，是因為獲取一個訊息只是”預定”了這個訊息，暫時把它移出了佇列，除非客戶端明確的表示已經處理完了這個訊息，否則這個訊息會被放回佇列中去，在一段可配置的時間之后可再次被處理，順序保證
在大多使用場景下，資料處理的順序都很重要，訊息佇列本來就是排序的，并且能保證資料會按照特定的順序來處理，IronMO 保證訊息通過 FIFO（先進先出）的順序來處理，因此訊息在佇列中的位置就是從佇列中檢索他們的位置，緩沖
在任何重要的系統中，都會有需要不同的處理時間的元素，例如,加載一張圖片比應用過濾器花費更少的時間，訊息佇列通過一個緩沖層來幫助任務最高效率的執行—寫入佇列的處理會盡可能的快速，而不受從佇列讀的預備處理的約束，該緩沖有助于控制和優化資料流經過系統的速度，理解資料流
在一個分布式系統里，要得到一個關于用戶操作會用多長時間及其原因的總體印象，是個巨大的挑戰，訊息系列通過訊息被處理的頻率，來方便的輔助確定那些表現不佳的處理程序或領域，這些地方的資料流都不夠優化，異步通信
很多時候，你不想也不需要立即處理訊息，訊息佇列提供了異步處理機制，允許你把
一個訊息放入佇列，但并不立即處理它，你想向佇列中放入多少訊息就放多少，然后
在你樂意的時候再去處理它們，
5.2.2:Messagequeue 的資料結構是什么？
基礎資料結構中“先進先出”的一種資料結構
5.3:如何在子執行緒中創建 Handler?
在子執行緒中創建 handler，只要確保子執行緒有 Looper,UI 執行緒默認包含 Looper，此時，我們需要用到一個特殊類HandlerThread，這個類可以輕松的創建子執行緒 handler，
創建步驟如下：
- 創建一個 HandlerThread，即創建一個包含 Looper 的執行緒
HandlerThread 的建構式有兩個:
public HandlerThread(String name) {
super(name);
mPriority = Process.THREAD_PRIORITY_DEFAULT;
}
/**
* Constructs a HandlerThread. * @param name * @param priority The priority to run the thread at. The value supplied must be from
* {@link android.os.Process} and not from java.lang.Thread. */
public HandlerThread(String name, int priority) {super(name);
mPriority = priority;
}
這里我們使用第一個就好:
HandlerThread handlerThread=new HandlerThread(“xuan”);
//創建 HandlerThread 后一定要記得 start();
handlerThread.start();
//通過 HandlerThread 的 getLooper 方法可以獲取 Looper
Looper looper=handlerThread.getLooper();
//通過 Looper 我們就可以創建子執行緒的 handler 了
Handlr handler=new Handler(looper);
通過該 handler 發送訊息，就會在子執行緒執行;
提示:如果要 handlerThread 停止:handlerThread.quit()，完整測驗代碼:
HandlerThread hanlerThread = new HandlerThread("子執行緒");
hanlerThread.start();
final Handler handler = new Handler(hanlerThread.getLooper()) {
@Override
public void handleMessage(Message msg) {
super.handleMessage(msg);
Log.d("----->", "執行緒:" + Thread.currentThread().getName());
}
};
findViewById(R.id.bt).setOnClickListener(new View.OnClickListener() {
@Override
public void onClick(View v) {
handler.sendEmptyMessage(100);
}
});
在 intentService(子執行緒)中,如果要回掉在 UI 執行緒怎么辦呢?
new Handler(getMainLooper()).post(new Runnable() {
@Override
public void run() {
// person.getName() Realm objects can only be accessed on the thread they were created. Toast.makeText(getApplicationContext(), "Loaded Person from
broadcast-receiver->intent-service: " + info, Toast.LENGTH_LONG).show();
}
});
5.4:Handler post 方法原理？
5.4.1:原始碼分析
5.4.1.1:點進去看 postDelayed()中的方法，里面呼叫 sendMessageDelayed 方法，和post() 里面呼叫的方法一樣，
public final boolean postDelayed(Runnable r, long delayMillis)
{
return sendMessageDelayed(getPostMessage(r), delayMillis);
}
5.4.1.2:分析sendMessageDelayed()方法
public final boolean sendMessageDelayed(Message msg, long delayMillis){
if (delayMillis < 0) {
delayMillis = 0;
}
return sendMessageAtTime(msg, SystemClock.uptimeMillis() + delayMillis);
}
里面呼叫了 sendMessageAtTime（）,這里的 SystemClock.uptimeMillis()是獲取系統從開機啟動到現在的時間,期間不包括休眠的時間,這里獲得到的時間是一個相對的時間,而不是通過獲取當前的時間(絕對時間)，而之所以使用這種方式來計算時間，而不是獲得當前 currenttime 來計算，在于handler 會受到阻塞，掛起狀態，睡眠等，這些時候是不應該執行的；如果使用絕對時間的話，就會搶占資源來執行當前 handler 的內容，顯然這是不應該出現的情況，所以要避免，
5.4.1.3:分析sendMessageAtTime()方法
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);
}
追到這里依然沒有看到，他在存放的時候有什么不同，但是顯然證實了訊息不是延遲放進 MessageQueen 的，那是腫么處理的，是在輪訓的時候處理的嗎？
5.4.1.4:我們點進 Looper 中看一下，主要代碼，Looper 中的 looper 呼叫了 MessageQueen中的 next 方法，難道是在 next()方法中處理的？
public static void loop() {
···
for (;;) {
Message msg = queue.next(); // might block
if (msg == null) {
// No message indicates that the message queue is quitting.
return;
}
}
5.4.1.5:分析MessageQueen 中的 next()方法
for (;;) {
if (nextPollTimeoutMillis != 0) {
Binder.flushPendingCommands();
}
nativePollOnce(ptr, nextPollTimeoutMillis);
···
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;
}
}
}
很貼心的給出了注釋解釋：“ Next message is not ready. Set a timeout to wake up when it is ready，翻譯“下一條訊息尚未準備好，設定一個超時，以便在準備就緒時喚醒，”
when 就是 uptimeMillis， for (；；) 相當于 while(true)，如果頭部的這個 Message是有延遲而且延遲時間沒到的（now < msg.when），不回傳 message 而且會計算一下時間（保存為變數nextPollTimeoutMillis），然后再回圈的時候判斷如果這個 Message 有延遲，就呼叫nativePollOnce(ptr, nextPollTimeoutMillis)進行阻塞，nativePollOnce()的作用類似與 object.wait()，得出結論是通過阻塞實作的，
5.4.1.6：但是如果在阻塞這段時間里有無延遲 message 又加入MessageQueen 中又是怎么實作立即處理這個 message 的呢?我們看MessageQueen 中放入訊息enqueueMessage()方法
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 inthe 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;
}
在這里 p 是現在訊息佇列中的頭部訊息，我們看到 when < p.when 的時候它交換了放入 message 與原來訊息佇列頭部 P 的位置，并且 needWake = mBlocked;（在 next()中當訊息為延遲訊息的時候mBlocked=true），繼續向下看 ,當needWake =true 的時候 nativeWake(mPtr)（喚起執行緒）一切都解釋的通了，如果當前插入的訊息不是延遲 message，或比當前的延遲短，這個訊息就會插入頭部并且喚起執行緒來，
好了，經過上面一系列的原始碼決議，我們把我們跟蹤的所有資訊整理下，
5.4.2:跟蹤整理
跟蹤的所有資訊整理如下:
- 訊息是通過
MessageQueen中的enqueueMessage()方法加入訊息隊列中的，并且它在放入中就進行好排序，鏈表頭的延遲時間小，尾部延遲時間最大 Looper.loop()通過MessageQueue中的next()去取訊息next()中如果當前鏈表頭部訊息是延遲訊息，則根據延遲時間進行訊息佇列會阻塞，不回傳給Looper message，知道時間到了，回傳給message- 如果在阻塞中有新的訊息插入到鏈表頭部則喚醒執行緒
Looper將新訊息交給回呼給handler中的handleMessage后，繼續呼叫MessageQueen的next()方法，如果剛剛的延遲訊息還是時間未到，則計算時間繼續阻塞
5.4.3:總結
handler.postDelay() 的實作 是通過 MessageQueue 中執行時間順序排列，訊息佇列阻塞，和喚醒的方式結合實作的，如果真的是通過延遲將訊息放入到 MessageQueen 中，那放入多個延遲訊息就要維護多個定時器，
5.5:Android 訊息機制的原理及原始碼決議
5.5.1:訊息機制概括
5.5.1.1:訊息機制的簡介
在 Android 中使用訊息機制，我們首先想到的就是 Handler，沒錯，Handler 是Android 訊息機制的上層介面，Handler 的使用程序很簡單，通過它可以輕松地將一個任務切換到 Handler 所在的執行緒中去執行，通常情況下，Handler 的使用場景就是更新 UI，
下面簡單看一個訊息機制的一個簡單實體：
public class Activity extends android.app.Activity {
private Handler mHandler = new Handler(){
@Override
public void handleMessage(Message msg) {
super.handleMessage(msg);
System.out.println(msg.what);
}
};
@Override
public void onCreate(Bundle savedInstanceState, PersistableBundle persistentState) {
super.onCreate(savedInstanceState, persistentState);
setContentView(R.layout.activity_main);
new Thread(new Runnable() {
@Override
public void run() {
//...............耗時操作
Message message = Message.obtain();
message.what = 1;
mHandler.sendMessage(message);
}
}).start();
}
}
在子執行緒中，進行耗時操作，執行完操作后，發送訊息，通知主執行緒更新 UI，這便是訊息機制的典型應用場景，我們通常只會接觸到 Handler 和 Message 來完成訊息機制，其實內部還有兩大助手來共同完成訊息傳遞，
5.5.1.2:訊息機制的模型
訊息機制主要包含：MessageQueue，Handler和Looper這三大部分，以及Message，下面我們一一介紹，Message：需要傳遞的訊息，可以傳遞資料；MessageQueue：訊息佇列，但是它的內部實作并不是用的佇列，實際上是通過一個單鏈表的資料結構來維護訊息串列，因為單鏈表在插入和洗掉上比較有優勢，主要功能向訊息池投遞訊息(MessageQueue.enqueueMessage)和取走訊息池的訊息(MessageQueue.next)；Handler：訊息輔助類，主要功能向訊息池發送各種訊息事件(Handler.sendMessage)和處理相應訊息事件(Handler.handleMessage)；Looper：不斷回圈執行(Looper.loop)，從 MessageQueue 中讀取訊息，按分發機制將訊息分發給目標處理者，
5.5.1.3:訊息機制的架構
訊息機制的運行流程：
在子執行緒執行完耗時操作，當
Handler發送訊息時，將會呼叫MessageQueue.enqueueMessage，向訊息佇列中添加訊息，當通過Looper.loop開啟回圈后，會不斷地從執行緒池中讀取訊息，即呼叫MessageQueue.next，然后呼叫目標Handler（即發送該訊息的Handler）的dispatchMessage方法傳遞訊息，然后回傳到Handler所在執行緒，目標Handler收到訊息，呼叫handleMessage方法，接收訊息，處理訊息，
MessageQueue，Handler和Looper三者之間的關系：每個執行緒中只能存在一個Looper，Looper是保存在ThreadLocal中的，主執行緒（UI 執行緒）已經創建了一個Looper，所以在主執行緒中不需要再創建Looper，但是在其他執行緒中需要創建Looper，每個執行緒中可以有多個Handler，即一個Looper可以處理來自多個Handler的訊息，Looper中維護一個MessageQueue，來維護訊息佇列，訊息佇列中的Message可以來自不同的Handler，
下面是訊息機制的整體架構圖，接下來我們將慢慢解剖整個架構，
從中我們可以看出：Looper有一個MessageQueue訊息佇列；MessageQueue有一組待處理的Message；Message中記錄發送和處理訊息的Handler；Handler中有Looper和MessageQueue，
5.5.2:訊息機制的原始碼決議
5.5.2.1:Looper
1:初始化Looper
要想使用訊息機制，首先要創建一個 Looper，初始化 Looper，無參情況下，默認呼叫 prepare(true);表示的是這個 Looper 可以退出，而對于false 的情況則表示當前 Looper 不可以退出，
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，只能創建一個，創建 Looper,并保存在ThreadLocal，其中 ThreadLocal 是執行緒本地存盤區（Thread Local Storage，簡稱為 TLS），每個執行緒都有自己的私有的本地存盤區域，不同執行緒之間彼此不能訪問對方的 TLS 區域，
2:開啟Looper
public static void loop() {
final Looper me = myLooper(); //獲取 TLS 存盤的 Looper 物件
if (me == null) {
throw new RuntimeException("No Looper; Looper.prepare() wasn't called on this thread.");
}
final MessageQueue queue = me.mQueue; //獲取 Looper 物件中的訊息佇列
Binder.clearCallingIdentity();
final long ident = Binder.clearCallingIdentity();
for (;;) { //進入 loop 的主回圈方法
Message msg = queue.next(); //可能會阻塞,因為 next()方法可能會無限回圈
if (msg == null) { //訊息為空，則退出回圈
return;
}
//默認為 null，可通過 setMessageLogging()方法來指定輸出,用于debug 功能
Printer logging = me.mLogging;
if (logging != null) {
logging.println(">>>>> Dispatching to " + msg.target + " " +
msg.callback + ": " + msg.what);
}
msg.target.dispatchMessage(msg); //獲取 msg 的目標 Handler，然后用于分發 Message
if (logging != null) {
logging.println("<<<<< Finished to " + msg.target + " " + msg.
callback);
}
final long newIdent = Binder.clearCallingIdentity();
if (ident != newIdent) {
-------
}
msg.recycleUnchecked();
}
}
loop()進入回圈模式，不斷重復下面的操作，直到訊息為空時退出回圈:讀取 MessageQueue 的下一條 Message（關于 next()，后面詳細介紹）；把 Message 分發給相應的 target，當 next()取出下一條訊息時，佇列中已經沒有訊息時，next()會無限回圈，產生阻塞，等待 MessageQueue 中加入訊息，然后重新喚醒，主執行緒中不需要自己創建 Looper，這是由于在程式啟動的時候，系統已經幫我們自動呼叫了 Looper.prepare()方法，查看 ActivityThread 中的 main()方法，代碼如下所示：
public static void main(String[] args) {..........................
Looper.prepareMainLooper();
..........................
Looper.loop();
..........................
}
其中prepareMainLooper()方法會呼叫 prepare(false)方法，
5.5.2.2:Handler
創建 Handler：
public Handler() {
this(null, false);
}
public Handler(Callback callback, boolean async) {
.................................
//必須先執行 Looper.prepare()，才能獲取 Looper 物件，否則為 null.
mLooper = Looper.myLooper(); //從當前執行緒的 TLS 中獲取 Looper 物件
if (mLooper == null) {
throw new RuntimeException("");
}
mQueue = mLooper.mQueue; //訊息佇列，來自 Looper 物件
mCallback = callback; //回呼方法
mAsynchronous = async; //設定訊息是否為異步處理方式}
對于 Handler 的無參構造方法，默認采用當前執行緒 TLS 中的 Looper 物件，并且callback 回呼方法為 null，且訊息為同步處理方式，只要執行的 Looper.prepare()方法，那么便可以獲取有效的 Looper 物件，
5.5.2.3:發送訊息
發送訊息有幾種方式，但是歸根結底都是呼叫了 sendMessageAtTime()方法，在子執行緒中通過 Handler 的 post()方式或 send()方式發送訊息，最終都是呼叫了sendMessageAtTime()方法，
post 方法
public final boolean post(Runnable r)
{
return sendMessageDelayed(getPostMessage(r), 0);
}
public final boolean postAtTime(Runnable r, long uptimeMillis)
{
return sendMessageAtTime(getPostMessage(r), uptimeMillis);
}
public final boolean postAtTime(Runnable r, Object token, long uptimeMillis)
{
return sendMessageAtTime(getPostMessage(r, token), uptimeMillis);
}
public final boolean postDelayed(Runnable r, long delayMillis)
{
return sendMessageDelayed(getPostMessage(r), delayMillis);
}
send 方法
public final boolean sendMessage(Message msg)
{
return sendMessageDelayed(msg, 0);
}
public final boolean sendEmptyMessage(int what)
{
return sendEmptyMessageDelayed(what, 0);
}
public final boolean sendEmptyMessageDelayed(int what, long delayMillis) {
Message msg = Message.obtain();
msg.what = what;
return sendMessageDelayed(msg, delayMillis);
}
public final boolean sendEmptyMessageAtTime(int what, long uptimeMillis)
{
Message msg = Message.obtain();
msg.what = what;
return sendMessageAtTime(msg, uptimeMillis);
}
public final boolean sendMessageDelayed(Message msg, long delayMillis)
{
if (delayMillis < 0) {
delayMillis = 0;
}
return sendMessageAtTime(msg, SystemClock.uptimeMillis() + delayMillis);
}
就連子執行緒中呼叫 Activity 中的 runOnUiThread()中更新 UI，其實也是發送訊息通知主執行緒更新 UI，最終也會呼叫 sendMessageAtTime()方法，
public final void runOnUiThread(Runnable action) {
if (Thread.currentThread() != mUiThread) {
mHandler.post(action);
} else {
action.run();
}
}
如果當前的執行緒不等于 UI 執行緒(主執行緒)，就去呼叫 Handler 的 post()方法，最侄訓呼叫 sendMessageAtTime()方法，否則就直接呼叫 Runnable 物件的 run()方法，下面我們就來一探究竟，到底 sendMessageAtTime()方法有什么作用？
public boolean sendMessageAtTime(Message msg, long uptimeMillis) {
//其中 mQueue 是訊息佇列，從 Looper 中獲取的
MessageQueue queue = mQueue;
if (queue == null) {
RuntimeException e = new RuntimeException(
this + " sendMessageAtTime() called with no mQueue");
Log.w("Looper", e.getMessage(), e);
return false;
}
//呼叫 enqueueMessage 方法
return enqueueMessage(queue, msg, uptimeMillis);
}
private boolean enqueueMessage(MessageQueue queue, Message msg, long uptimeMillis) {
msg.target = this;
if (mAsynchronous) {
msg.setAsynchronous(true);
}
//呼叫 MessageQueue 的 enqueueMessage 方法
return queue.enqueueMessage(msg, uptimeMillis);
}
可以看到 sendMessageAtTime()方法的作用很簡單，就是呼叫MessageQueue的enqueueMessage()方法，往訊息佇列中添加一個訊息，下面來看enqueueMessage()`方法的具體執行邏輯，
boolean enqueueMessage(Message msg, long when) {
// 每一個 Message 必須有一個 target
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) {
//正在退出時，回收 msg，加入到訊息池
msg.recycle();
return false;
}
msg.markInUse();
msg.when = when;
Message p = mMessages;
boolean needWake;
if (p == null || when == 0 || when < p.when) {
//p 為 null(代表 MessageQueue 沒有訊息） 或者 msg 的觸發時間是佇列中最早的,則進入該該分支
msg.next = p;
mMessages = msg;
needWake = mBlocked;
} else {
//將訊息按時間順序插入到 MessageQueue，一般地，不需要喚醒事件佇列，除非訊息隊頭存在 barrier，并且同時 Message 是佇列中最早的異步訊息，
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;
prev.next = msg;
}
if (needWake) {
nativeWake(mPtr);
}
}
return true;
}
MessageQueue 是按照 Message 觸發時間的先后順序排列的，隊頭的訊息是將要最早觸發的訊息，當有訊息需要加入訊息佇列時，會從佇列頭開始遍歷，直到找到訊息應該插入的合適位置，以保證所有訊息的時間順序，
5.5.2.4:獲取訊息
當發送了訊息后，在 MessageQueue 維護了訊息佇列，然后在 Looper 中通過 loop()方法，不斷地獲取訊息，上面對 loop()方法進行了介紹，其中最重要的是呼叫了 queue.next()方法,通過該方法來提取下一條資訊，下面我們來看一下 next()方法的具體流程，
dispatchMessage():
Message next() {
final long ptr = mPtr;
if (ptr == 0) { //當訊息回圈已經退出，則直接回傳
return null;
}
int pendingIdleHandlerCount = -1; // 回圈迭代的首次為-1
int nextPollTimeoutMillis = 0;
for (;;) {
if (nextPollTimeoutMillis != 0) {
Binder.flushPendingCommands();
}
//阻塞操作，當等待 nextPollTimeoutMillis 時長，或者訊息佇列被喚醒，都會回傳
nativePollOnce(ptr, nextPollTimeoutMillis);
synchronized (this) {
final long now = SystemClock.uptimeMillis();
Message prevMsg = null;
Message msg = mMessages;
if (msg != null && msg.target == null) {
//當訊息 Handler 為空時，查詢 MessageQueue 中的下一條異步訊息 msg，為空則退出回圈，
do {
prevMsg = msg;
msg = msg.next;
} while (msg != null && !msg.isAsynchronous());
}
if (msg != null) {
if (now < msg.when) {
//當異步訊息觸發時間大于當前時間，則設定下一次輪詢的超時時長
nextPollTimeoutMillis = (int) Math.min(msg.when - now,Integer.MAX_VALUE);
} else {
// 獲取一條訊息，并回傳
mBlocked = false;
if (prevMsg != null) {
prevMsg.next = msg.next;
}
else {
mMessages = msg.next;
}
msg.next = null;
//設定訊息的使用狀態，即 flags |= FLAG_IN_USE
msg.markInUse();
return msg; //成功地獲取 MessageQueue 中的下一條即將要執行的訊息
}
} else {
//沒有訊息
nextPollTimeoutMillis = -1;
}
//訊息正在退出，回傳 null
if (mQuitting) {
dispose();
return null;
}
...............................
}}
nativePollOnce 是阻塞操作，其中 nextPollTimeoutMillis 代表下一個訊息到來前，還需要等待的時長；當 nextPollTimeoutMillis = -1 時，表示訊息佇列中無訊息，會一直等待下去，可以看出 next()方法根據訊息的觸發時間，獲取下一條需要執行的訊息,佇列中訊息為空時，則會進行阻塞操作，
5.5.2.5:分發訊息
在 loop()方法中，獲取到下一條訊息后，執行 msg.target.dispatchMessage(msg)，來分發訊息到目標 Handler 物件，下面就來具體看下 dispatchMessage(msg)方法的執行流程，
public void dispatchMessage(Message msg) {
if (msg.callback != null) {
//當 Message 存在回呼方法，回呼 msg.callback.run()方法；
handleCallback(msg);
} else {
if (mCallback != null) {
//當 Handler 存在 Callback 成員變數時，回呼方法 handleMessage()；
if (mCallback.handleMessage(msg)) {
return;
}
}
//Handler 自身的回呼方法 handleMessage()
handleMessage(msg);
}}
private static void handleCallback(Message message) {
message.callback.run();
}
分發訊息流程:
當 Message 的 msg.callback 不為空時，則回呼方法 msg.callback.run();當 Handler 的 mCallback 不為空時，則回呼方法 mCallback.handleMessage(msg)；最后呼叫 Handler 自身的回呼方法handleMessage()，該方法默認為空，Handler子類通過覆寫該方法來完成具體的邏輯:
訊息分發的優先級:
Message 的回呼方法：message.callback.run()，優先級最高；Handler 中 Callback 的回呼方法：Handler.mCallback.handleMessage(msg)，優先級僅次于 1；Handler 的默認方法：Handler.handleMessage(msg)，優先級最低，對于很多情況下，訊息分發后的處理方法是第 3 種情況，即Handler.handleMessage()，一般地往往通過覆寫該方法從而實作自己的業務邏輯，
5.5.3:總結
以上便是訊息機制的原理，以及從原始碼角度來決議訊息機制的運行程序，可以簡單地用下圖來理解:
六:Handler的延伸
Handler 雖然簡單易用，但是要用好它還是需要注意一點，另外 Handler 相關 還有些鮮為人知的知識技巧，比如 IdleHandler，由于 Handler 的特性，它在 Android 里的應用非常廣泛，比如： AsyncTask、
HandlerThread、Messenger、IdleHandler 和 IntentService 等等，這些我會講解一些，我沒講到的可以自行搜索相關內容進行了解，
6.1 Handler 引起的記憶體泄露原因以及最佳解決方案
Handler 允許我們發送延時訊息，如果在延時期間用戶關閉了 Activity，那么該Activity 會泄露，這個泄露是因為 Message 會持有 Handler，而又因為 Java 的特性，內部類會持有外部類，使得 Activity 會被 Handler 持有，這樣最終就導致 Activity 泄露，解決該問題的最有效的方法是：將 Handler 定義成靜態的內部類，在內部持有Activity 的弱參考，并及時移除所有訊息，示例代碼如下：
private static class SafeHandler extends Handler {
private WeakReference<HandlerActivity> ref;
public SafeHandler(HandlerActivity activity) {
this.ref = new WeakReference(activity);
}
@Override
public void handleMessage(final Message msg) {
HandlerActivity activity = ref.get();
if (activity != null) {
activity.handleMessage(msg);
}
}
}
并且再在 Activity.onDestroy() 前移除訊息，加一層保障：
@Override
protected void onDestroy() {
safeHandler.removeCallbacksAndMessages(null);
super.onDestroy();
}
這樣雙重保障，就能完全避免記憶體泄露了，
注意：
單純的在
onDestroy移除訊息并不保險，因為 onDestroy 并不一定執行，
6.2 為什么我們能在主執行緒直接使用 Handler，而不需要創建 Looper ？
前面我們提到了每個 Handler 的執行緒都有一個 Looper ，主執行緒當然也不例外，但是我們不曾準備過主執行緒的 Looper 而可以直接使用，這是為何？注意：通常我們認為 ActivityThread 就是主執行緒，事實上它并不是一個執行緒，而是主執行緒操作的管理者，所以吧，我覺得把 ActivityThread 認為就是主執行緒無可厚非，另外主執行緒也可以說成 UI 執行緒，在 ActivityThread.main() 方法中有如下代碼：
//android.app.ActivityThread
public static void main(String[] args) {
//...
Looper.prepareMainLooper();
ActivityThread thread = new ActivityThread();
thread.attach(false);
if (sMainThreadHandler == null) {
sMainThreadHandler = thread.getHandler();
}
//...
Looper.loop();
throw new RuntimeException("Main thread loop unexpectedly exited");
}
//Looper.prepareMainLooper(); 代碼如下：
/**
* 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();
}}
可以看到在 ActivityThread 里 呼叫了 Looper.prepareMainLooper() 方法,創建了主執行緒的 Looper ,并且呼叫了 loop() 方法，所以我們就可以直接使用Handler 了，
注意:
Looper.loop()是個死回圈，后面的代碼正常情況不會執行，
6.3 主執行緒的 Looper 不允許退出
如果你嘗試退出 Looper,你會得到以下錯誤資訊：
Caused by: java.lang.IllegalStateException: Main thread not allowed to q
uit.
at android.os.MessageQueue.quit(MessageQueue.java:415)
at android.os.Looper.quit(Looper.java:240)
why? 其實原因很簡單，主執行緒不允許退出，退出就意味 APP 要掛，那樣就沒有任何意義了，
6.4 Handler 里藏著的 Callback 能干什么？
在 Handler 的構造方法中有幾個 要求傳入 Callback ，那它是什么，又能做什么呢？來看看 Handler.dispatchMessage(msg) 方法：
public void dispatchMessage(Message msg) {
//這里的 callback 是 Runnable
if (msg.callback != null) {
handleCallback(msg);
} else {
//如果 callback 處理了該 msg 并且回傳 true， 就不會再回呼 handleMessage
if (mCallback != null) {
if (mCallback.handleMessage(msg)) {
return;
}
}
handleMessage(msg);
}
}
可以看到 Handler.Callback 有優先處理訊息的權利 ，當一條訊息被 Callback 處理并攔截（回傳 true），那么 Handler 的 handleMessage(msg) 方法就不會被呼叫了；如果 Callback 處理了訊息，但是并沒有攔截，那么就意味著一個訊息可以同時被 Callback 以及 Handler 處理，
這個就很有意思了，這有什么作用呢？
我們可以利用 Callback 這個攔截機制來攔截 Handler 的訊息！
場景：Hook ActivityThread.mH ， 在 ActivityThread 中有個成員變數 mH ，它是個 Handler，又是個極其重要的類，幾乎所有的插件化框架都使用了這個方法，
6.5 創建 Message 實體的最佳方式
由于 Handler 極為常用，所以為了節省開銷，Android 給 Message 設計了回識訓制，所以我們在使用的時候盡量復用 Message ,減少記憶體消耗，方法有二種：
通過 Message 的靜態方法 Message.obtain();獲取.通過 Handler 的公有方法 handler.obtainMessage().
6.6 子執行緒里彈 Toast 的正確姿勢
有時候遇到過這種情況，當我們嘗試在子執行緒里直接去彈 Toast 的時候，會 crash ：
java.lang.RuntimeException: Can't create handler inside thread that has
not called Looper.prepare()
本質上是因為 Toast 的實作依賴于 Handler，按子執行緒使用 Handler 的要求修改即可，同理的還有 Dialog，正確示例代碼如下：
new Thread(new Runnable() {
@Override
public void run() {
Looper.prepare();
Toast.makeText(HandlerActivity.this, "不會崩潰啦！", Toast.LENGTH_SHORT).show();
Looper.loop();
}
});
6.7 妙用 Looper 機制
我們可以利用 Looper 的機制來幫助我們做一些事情：
將 Runnable post 到主執行緒執行；利用 Looper 判斷當前執行緒是否是主執行緒，
完整示例代碼如下：
public final class MainThread {
private MainThread() {
}
private static final Handler HANDLER = new Handler(Looper.getMainLooper());
public static void run(@NonNull Runnable runnable) {
if (isMainThread()) {
runnable.run();
}else{
HANDLER.post(runnable);
}
}
public static boolean isMainThread() {
return Looper.myLooper() == Looper.getMainLooper();
}
}
七:總結
- Handler 的 背 后 有 Looper 、 MessageQueue 支 撐 ， Looper 負 責 消 息 分 發 ，MessageQueue 負責訊息管理
- 在創建 Handler 之前一定需要先創建 Looper
- Looper 有退出的功能，但是主執行緒的 Looper 不允許退出
- 異步執行緒的 Looper 需要自己呼叫 Looper.myLooper().quit(); 退出
- Runnable 被封裝進了 Message，可以說是一個特殊的 Message
- Handler.handleMessage() 所在的執行緒是 Looper.loop() 方法被呼叫的執行緒，也可
以說成 Looper 所在的執行緒，并不是創建 Handler 的執行緒 - 使用內部類的方式使用 Handler 可能會導致記憶體泄露，即便在 Activity.onDestroy
里移除延時訊息，必須要寫成靜態內部類
更好的博客可以參考：Android Handler：圖文決議 Handler通信機制 的作業原理，
請點贊關注加品論！因為你的鼓勵是我寫作的最大動力！
轉載請註明出處，本文鏈接：https://www.uj5u.com/yidong/290123.html
標籤：其他