深入瞭解Looper、Handler、Message之間關係
前言及簡介
上個星期我們整個專案組趁著小假期，驅車去了江門市的台山猛虎峽玩了兩個多鐘左右極限勇士全程漂流，感覺真得不錯，夏天就應該多多玩水，多親近一下大自然，不要整天埋頭工作。剛回來時發現手因為抓了那個充氣艇過久，現在都挺疼的。但是應該堅持自己上篇所說的，要保持每週的頻度更新博文，上週沒有時間寫，這週一起補上，讓朋友們一起相互分享學習，共同進步。
好了，言歸正題，今天我們要講的主題是關於Android中的非同步訊息處理機制的內容。有一點Android基礎的朋友們都知道，在Android中，主執行緒（也就是UI執行緒）是不安全的，當在主執行緒處理訊息過長時，非常容易發生ANR（Application Not Responding）現象，這樣對於使用者體驗是非常不好的；其次，如果我們在子執行緒中嘗試進行UI的操作，程式就可能還會直接崩潰。我相信，對於大多剛入門的朋友，在日常工作當中會經常遇到這個問題，而解決的方法大多已經通過google已瞭解清楚，也就是在子執行緒中建立一個訊息Message物件，然後利用在主執行緒中建立的Handler物件進行傳送，之後我們可以在這個Handler物件的handlerMessage()方法中獲取剛剛傳送的Message物件，取出裡面所儲存的值，就可以在這裡進行UI的操作。這種方法就稱為非同步訊息處理執行緒。
總的來說，非同步訊息處理執行緒，說得比較通俗一點就是，當我們啟動此方法後，會進入到一個無限的迴圈當中，每迴圈一次，我們就其對應的內部訊息佇列(Message Queue)中取出一個訊息(Message)，然後回撥好相應的訊息處理函式，當執行完一個訊息後則繼續迴圈，若當訊息佇列中訊息為空，則執行緒會被阻塞等待，直到有訊息進入時再被喚醒。
好吧，說了那麼多，現在，就讓我們來看一下這種處理機制的廬山真面目吧。
分析Handler
首先我們來分析分析一下Handler的用法，我們知道，要建立一個Handler物件非常的簡單明瞭，直接進行new一個物件即可，但是你有沒有想過，這裡會隱藏著什麼注意點呢。現在可以試著寫一下下面的一小段程式碼，然後自己執行看看：
public class MainActivity extends ActionBarActivity {
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物件竟然會導致程式直接崩潰，提示的錯誤竟然是Can't create handler inside thread that has not called Looper.prepare()
於是我們按照logcat中所說，在子執行緒中加入Looper.prepare(),即程式碼如下：
new Thread(new Runnable(){
@override
public void run(){
Looper.prepare();
mHandler1 = new Handler()l
}
}).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() || 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 = mLooper.mQueue;
mCallback = callback;
mAsynchronous = async;
}不難看出，原始碼中呼叫了mLooper = Looper.myLooper()方法獲取一個Looper物件，若此時Looper物件為null，則會直接丟擲一個“Can't create handler inside 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. We
// 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 CA certificates
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物件。
傳送訊息
當我們正確的建立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機制，也是借用了非同步訊息處理機制來實現的。
總結
通過上面對非同步訊息處理執行緒的講解，我們不難真正地理解到了Handler、Looper以及Message之間的關係，概括性來說，Looper負責的是建立一個MessageQueue物件，然後進入到一個無限迴圈體中不斷取出訊息，而這些訊息都是由一個或者多個Handler進行建立處理。
接下來朋友們想要了解哪方面的東西或者有什麼好的想法，可以在下面留言交流，我會盡自己的能力選擇分享給朋友們，當然，如果有什麼分享錯誤或者不懂的地方，可以相互交流，期待每個朋友在我的博文中都能學到東西，如果覺得好的話，麻煩各位兄弟關注一下，謝謝！！