Android Handler機制之Message及Message回收機制
該文章屬於《Android Handler機制之》系列文章，若是想了解更多，請點擊 《Android Handler機制之總目錄》安全
前言
在前面的文章中咱們講解了Handler、Looper、MessageQueue的具體關係，瞭解了具體的消息循環的流程。下面將一塊兒來探討最爲整個消息循環的消息載體Message。bash
Message中能夠攜帶的信息
Message中能夠攜帶的數據比較豐富，下面對一些經常使用的數據進行了分析。oop
/**
* 用戶定義的消息代碼，以便當接受到消息是關於什麼的。其中每一個Hanler都有本身的命名控件，不用擔憂會衝突
*/
public int what;
/**
* 若是你只想存不多的整形數據，那麼能夠考慮使用arg1與arg2,
* 若是須要傳輸不少數據可使用Message中的setData(Bundle bundle)
*/
public int arg1;
/**
* 若是你只想存不多的整形數據，那麼能夠考慮使用arg1與arg2,
* 若是須要傳輸不少數據可使用Message中的setData(Bundle bundle)
*/
public int arg2;
/**
* 發送給接受方的任意對象，在使用跨進程的時候要注意obj不能爲null
*/
public Object obj;
/**
* 在使用跨進程通訊Messenger時，能夠肯定須要誰來接收
*/
public Messenger replyTo;
/**
* 在使用跨進程通訊Messenger時，能夠肯定須要發消息的uid
*/
public int sendingUid = -1;
/**
* 若是數據比較多，能夠直接使用Bundle進行數據的傳遞
*/
Bundle data;
複製代碼
其中關於what的值爲何不會衝突的緣由是，以前咱們講過的handler是與線程進行綁定的。也就是說不一樣消息循環消息的發送，處理的線程是不同的。固然是不會衝突的。對於Messenger，由於涉及到Binder機制，這裏就不過多的描述了，有興趣的小夥伴能夠自行查詢相關資料學習。post
建立消息的方式
官方建議使用Message.obtain()系列方法來獲取Message實例，由於其Message實例是直接從Handler的消息池中獲取的，能夠循環利用，沒必要另外開闢內存空間，效率比直接使用new Message（）建立實例要高。其中具體建立消息的方式，我已經爲你們分好類了。具體分類以下：學習
//無參數
public static Message obtain() {...}
//帶Messag參數
public static Message obtain(Message orig) {}
//帶Handler參數
public static Message obtain(Handler h) {}
public static Message obtain(Handler h, Runnable callback){}
public static Message obtain(Handler h, int what){}
public static Message obtain(Handler h, int what, Object obj){}
public static Message obtain(Handler h, int what, int arg1, int arg2){}
public static Message obtain(Handler h, int what,int arg1, int arg2, Object obj) {}
複製代碼
其中在Message的obtain帶參數的方法中，內部都會調用無參的obtain()方法來獲取消息後。而後並根據其傳入的參數，對Message進行賦值。（關於具體的obtain方法會在下方消息池實現原理中具體描述）ui
消息池實現原理
既然官方建議使用消息池來獲取消息，那麼在瞭解其內部機制以前，咱們來看看Message中的消息池的設計。具體代碼以下：this
private static final Object sPoolSync = new Object();//控制獲取從消息池中獲取消息。保證線程安全
private static Message sPool;//消息池
private static int sPoolSize = 0;//消息池中回收的消息數量
private static final int MAX_POOL_SIZE = 50;//消息池最大容量
複製代碼
從Message的消息池設計，咱們大概能看出如下幾點：spa
- 該消息池在同一個消息循環中是共享的（sPool聲明爲static)，
- 消息池中的最大容量爲50，
- 從消息池獲取消息是線程安全的。
從消息池中獲取消息
在上文中，咱們已經知道了在使用消息池得到消息時，都會調用無參的obtain（）方法。具體代碼以下：線程
public static Message obtain() {
synchronized (sPoolSync) {
if (sPool != null) {
Message m = sPool;
sPool = m.next;
m.next = null;
m.flags = 0; //從新標識當前Message沒有使用過
sPoolSize--;
return m;
}
}
return new Message();//若是爲空直接返回
}
複製代碼
從上述代碼中，咱們能夠了解，也就是當前 消息池不爲空（sPool !=null)的狀況下，那麼咱們就能夠從消息池中獲取數據，相應的消息池中的消息數量會減小。消息池的內部實現是以鏈表的形式，其中spol指針指向當前鏈表的頭結點，從消息池中獲取消息是以移除鏈表中sPool所指向的節點的形式，具體原理以下圖所示： 設計
回收消息到消息池
在Meaage的消息回收中，消息的實際回收方法是recycleUnchecked（）方法，具體以下圖所示：
void recycleUnchecked() {
//用於表示當前Message消息已經被使用過了
flags = FLAG_IN_USE;
//狀況以前Message的數據
what = 0;
arg1 = 0;
arg2 = 0;
obj = null;
replyTo = null;
sendingUid = -1;
when = 0;
target = null;
callback = null;
data = null;
//判斷當前消息池中的數量是否是小於最大數量，其中 MAX_POOL_SIZE=50
synchronized (sPoolSync) {
if (sPoolSize < MAX_POOL_SIZE) {
next = sPool;
sPool = this;
sPoolSize++;//記錄當前消息池中的數量
}
}
}
複製代碼
在recycleUnchecked（）方法中，大體分爲三步，第一步將該條回收的消息狀態設置爲正在使用，第二步將Message全部的存儲信息都變爲初始值，第三步，若是當前消息池仍可以存儲回收的消息，那麼就將消息存儲在消息池中。其中將回收消息加入消息池中是使用鏈表的形式，具體回收消息到消息池以下圖所示：
Message 消息回收時機
這裏爲了方便你們梳理邏輯，我提早將幾種會調用消息進行回收的狀況都描述出來了，具體的狀況以下所示：
當Handler指定刪除單條消息，或全部消息的時候
void removeMessages(Handler h, int what, Object object)
void removeMessages(Handler h, Runnable r, Object object)
void removeCallbacksAndMessages(Handler h, Object object)
複製代碼
當使用Handler刪除某條消息的時候，會分別調用MessageQueue的
- removeMessages(Handler h, int what, Object object)
- removeCallbacksAndMessages(Handler h, Object object)
- removeMessages(Handler h, Runnable r, Object object)
這三個方法邏輯比較相似。這裏直接選取removeCallbacksAndMessages（）方法來進行講解。具體代碼以下：
void removeCallbacksAndMessages(Handler h, Object object) {
if (h == null) {
return;
}
synchronized (this) {
Message p = mMessages;
// 第一次循環
while (p != null && p.target == h
&& (object == null || p.obj == object)) {
//下面操做會將知足回收條件的消息，從消息隊列中移除
Message n = p.next;
mMessages = n;
p.recycleUnchecked();
p = n;
}
// 第二次循環
while (p != null) {
Message n = p.next;
if (n != null) {
if (n.target == h && (object == null || n.obj == object)) {
//下面操做會將知足回收條件的消息，從消息隊列中移除
Message nn = n.next;
n.recycleUnchecked();
p.next = nn;
continue;
}
}
p = n;
}
}
}
複製代碼
在removeCallbacksAndMessages(Handler h, Object object)方法中，在該方法中分別進行了兩次循環，確定有不少讀者朋友會很好奇，爲何這裏會進行兩次循環呢？下面我就具體來說解一下。
咱們都知道，在Handler機制中，多個handler對應同一個MessageQueue對應同一個Looper，Handler與MessageQueue與Looper之間的關係是N：1：1。也就是說在MessageQueue中咱們能夠有多個不一樣Handler發送的Message。那麼咱們再結合上面的代碼，咱們來分析這兩次循環。
第一次循環
根據上文對代碼的理解，第一次循環會將MessageQueue中，當前Handler發送的全部消息移除，注意!!!!!!!!!這裏並不會將整個MessageQueue中的當前Handler發送的消息所有移除，而是在遍歷過程當中，若是有其餘Handler發送的消息,那麼就會將mMessages指向頭結點並跳出循環。以下圖所示：
第二次循環
通過上文的分析，咱們已經知道了，在進行第一次循環後，已經將在removeCallbacksAndMessages方法執行時全部對應的Handler發送的消息移除掉了，可是MessageQueue中可能任然會殘留沒有移除掉的消息。那麼第二次循環，根據代碼來理解的話，咱們能夠獲得下圖：
因此爲了保證將整個MessageQueue中該Handler發送的消息所有被移除，在第一次循環移除以後，咱們必需要再執行一次循環移除操做。
ps:很是感謝@承香墨影指出的錯誤的地方，以前沒有考慮到同步的關係，誤導了你們。心裏感到無比的愧疚。
當Loooper取出消息時
public static void loop() {
//省略部分代碼
for (;;) {
Message msg = queue.next(); // might block
if (msg == null) {
// No message indicates that the message queue is quitting.
return;
}
//省略部分代碼
try {
msg.target.dispatchMessage(msg);
end = (slowDispatchThresholdMs == 0) ? 0 : SystemClock.uptimeMillis();
} finally {
if (traceTag != 0) {
Trace.traceEnd(traceTag);
}
}
//省略部分代碼
//回收消息
msg.recycleUnchecked();
}
}
複製代碼
咱們都知道消息的取出是經過Looper類中的loop方法。從代碼中咱們能夠看出，當消息取出並執行相應操做後。最後會將消息回收。
當Looper取消循環消息隊列的時候
public void quitSafely() { mQueue.quit(true);}
public void quit() { mQueue.quit(false); }
複製代碼
當退出消息隊列的時候，也就是調用Loooper的quitSafely（）或quit（）方法，從代碼中咱們能夠看出，會調用其內部的MessageQueue的quit(boolean safe)方法。咱們繼續跟蹤代碼。
void quit(boolean safe) {
if (!mQuitAllowed) {//注意，主線程是不能退出消息循環的
throw new IllegalStateException("Main thread not allowed to quit.");
}
synchronized (this) {
if (mQuitting) {//若是當前循環消息已經退出了，直接返回
return;
}
mQuitting = true;
if (safe) {//若是是安全退出
removeAllFutureMessagesLocked();
} else {//若是不是安全退出
removeAllMessagesLocked();
}
// We can assume mPtr != 0 because mQuitting was previously false.
nativeWake(mPtr);
}
}
複製代碼
在MessageQueue的quit(boolean safe)方法中，會將mQuitting （用於判斷當前消息隊列是否已經退出）置爲true，同時會根據當前是否安全退出的標誌 (safe)來走不一樣的邏輯,若是安全則走removeAllFutureMessagesLocked（）方法，若是不是安全退出則走removeAllMessagesLocked（）方法。下面分別對這兩個方法進行討論。
非安全退出
private void removeAllMessagesLocked() {
Message p = mMessages;
while (p != null) {
Message n = p.next;
p.recycleUnchecked();
p = n;
}
mMessages = null;
}
複製代碼
非安全退出其實很簡單，就是將全部消息隊列中的消息所有回收。具體示意圖以下所示：
安全退出
private void removeAllFutureMessagesLocked() {
final long now = SystemClock.uptimeMillis();
Message p = mMessages;//當前隊列中的頭消息
if (p != null) {
if (p.when > now) {//判斷時間，若是Message的取出時間比當前時間要大直接移除
removeAllMessagesLocked();
} else {
Message n;
for (;;) {//繼續判斷，取隊列中全部大於當前時間的消息
n = p.next;
if (n == null) {
return;
}
if (n.when > now) {
break;
}
p = n;
}
p.next = null;
do {//將全部全部大於當前時間的消息的消息回收
p = n;
n = p.next;
p.recycleUnchecked();
} while (n != null);
}
}
}
複製代碼
觀察上訴代碼，在該方法中，會判斷當前消息隊列中的頭消息的時間是否大於當前時間，若是大於當前時間就會removeAllMessagesLocked（）方法（也就是回收所有消息），反之，則回收部分消息，同時沒有被回收的消息任然能夠被取出執行。具體示意圖以下所示：
當消息隊列退出的，可是仍然發送消息過來的時候
在Looper調用quit()方法時，也就是Looper退出消息循環的時候，咱們已經知道了其內部會調用MessageQueue的quit(boolean safe)方法。當MessageQueue退出的時候，會將mQuitting置爲true。那麼當對應的Handler發送消息時，咱們都知道會調用MessageQueue的enqueueMessage（Message msg, long when）方法。那麼如今咱們觀察下列代碼：
boolean enqueueMessage(Message msg, long when) {
...省略部分代碼
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;
}
...省略部分代碼
}
複製代碼
觀察該代碼咱們得知，當循環消息退出的時候，若是這個時候Handler繼續發送消息來。會將該消息回收。可是如今這裏有個問題。既然咱們的消息隊列已經結束循環了。那麼咱們回收該消息又有什麼用呢？咱們又不能從新的開啓消息循環。不知道Google這裏爲何會這麼設計。
總結
- 在使用Handler發消息時，建議使用Message.obtin()方法，從消息池中獲取消息。
- 在Message中消息池是使用鏈表的形式來存儲消息的。
- 在Message中消息池中最大容許存儲50條的消息。
- 在使用Handler移除某條消息的時候，該消息有可能會被消息池回收。（會判斷消息池是否仍然能存儲消息）
- 1. Android Handler機制之Message及Message回收機制
- 2. Android 通訊機制Message、Handler 的用法
- 3. Android消息處理機制(Handler 與Message)
- 4. Android Handler機制（一）---Message源碼分析
- 5. Android 消息機制（Handler，Looper，MessageQueue，Message）
- 6. Handler機制之Message源碼解析
- 7. 淺談Android的Message機制
- 8. Android——Message消息機制
- 9. Handler機制（Looper、Message、MessageQueue）源碼追蹤
- 10. android 之 Handler 、Message 、Looper
- 更多相關文章...
- • ARP協議的工作機制詳解 - TCP/IP教程
- • TiDB數據庫的管理機制 - NoSQL教程
- • 漫談MySQL的鎖機制
- • Docker容器實戰(六) - 容器的隔離與限制
-
每一个你不满意的现在，都有一个你没有努力的曾经。
- 1. Android Handler機制之Message及Message回收機制
- 2. Android 通訊機制Message、Handler 的用法
- 3. Android消息處理機制(Handler 與Message)
- 4. Android Handler機制（一）---Message源碼分析
- 5. Android 消息機制（Handler，Looper，MessageQueue，Message）
- 6. Handler機制之Message源碼解析
- 7. 淺談Android的Message機制
- 8. Android——Message消息機制
- 9. Handler機制（Looper、Message、MessageQueue）源碼追蹤
- 10. android 之 Handler 、Message 、Looper