[轉]Android Handler 介紹
最近在MediaPlayer中添加handler的時候看了下Handler的一些用法，
static class TimeProvider implements MediaPlayer.OnSeekCompleteListener,
MediaTimeProvider {
private static final String TAG = "MTP";
private static final long MAX_NS_WITHOUT_POSITION_CHECK = 5000000000L;
private static final long MAX_EARLY_CALLBACK_US = 1000;
private static final long TIME_ADJUSTMENT_RATE = 2; /* meaning 1/2 */
private long mLastTimeUs = 0;
private MediaPlayer mPlayer;
private boolean mPaused = true;
private boolean mStopped = true;
private boolean mBuffering;
private long mLastReportedTime;
// since we are expecting only a handful listeners per stream, there is
// no need for log(N) search performance
private MediaTimeProvider.OnMediaTimeListener mListeners[];
private long mTimes[];
private Handler mEventHandler;
private boolean mRefresh = false;
private boolean mPausing = false;
private boolean mSeeking = false;
private static final int NOTIFY = 1;
private static final int NOTIFY_TIME = 0;
private static final int NOTIFY_STOP = 2;
private static final int NOTIFY_SEEK = 3;
private static final int NOTIFY_TRACK_DATA = 4;
private HandlerThread mHandlerThread;
/** @hide */
public boolean DEBUG = false;
public TimeProvider(MediaPlayer mp) {
mPlayer = mp;
try {
getCurrentTimeUs(true, false);
} catch (IllegalStateException e) {
// we assume starting position
mRefresh = true;
}
Looper looper;
if ((looper = Looper.myLooper()) == null &&
(looper = Looper.getMainLooper()) == null) {
// Create our own looper here in case MP was created without one
mHandlerThread = new HandlerThread("MediaPlayerMTPEventThread",
Process.THREAD_PRIORITY_FOREGROUND);
mHandlerThread.start();
looper = mHandlerThread.getLooper();
}
mEventHandler = new EventHandler(looper);
mListeners = new MediaTimeProvider.OnMediaTimeListener[0];
mTimes = new long[0];
mLastTimeUs = 0;
}
有兩篇文章寫得不錯，轉載下
Android Handler的使用詳解
這篇文章主要介紹了Android Handler的使用詳解,本篇文章通過簡要的案例,講解了該項技術的了解與使用,以下就是詳細內容,需要的朋友可以參考下
在Android開發(fā)中，我們經(jīng)常會遇到這樣一種情況：在UI界面上進行某項操作后要執(zhí)行一段很耗時的代碼，比如我們在界面上點擊了一個”下載“按鈕，那么我們需要執(zhí)行網(wǎng)絡請求，這是一個耗時操作，因為不知道什么時候才能完成。為了保證不影響UI線程，所以我們會創(chuàng)建一個新的線程去執(zhí)行我們的耗時的代碼。當我們的耗時操作完成時，我們需要更新UI界面以告知用戶操作完成了。所以我們可能會寫出如下的代碼:
package ispring.com.testhandler;
import android.app.Activity;
import android.os.Bundle;
import android.view.View;
import android.widget.Button;
import android.widget.TextView;
public class MainActivity extends Activity implements Button.OnClickListener {
private TextView statusTextView = null;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
statusTextView = (TextView)findViewById(R.id.statusTextView);
Button btnDownload = (Button)findViewById(R.id.btnDownload);
btnDownload.setOnClickListener(this);
}
@Override
public void onClick(View v) {
DownloadThread downloadThread = new DownloadThread();
downloadThread.start();
}
class DownloadThread extends Thread{
@Override
public void run() {
try{
System.out.println("開始下載文件");
//此處讓線程DownloadThread休眠5秒中，模擬文件的耗時過程
Thread.sleep(5000);
System.out.println("文件下載完成");
//文件下載完成后更新UI
MainActivity.this.statusTextView.setText("文件下載完成");
}catch (InterruptedException e){
e.printStackTrace();
}
}
}
}
上面的代碼演示了單擊”下載“按鈕后會啟動一個新的線程去執(zhí)行實際的下載操作，執(zhí)行完畢后更新UI界面。但是在實際運行到代碼MainActivity.this.statusTextView.setText(“文件下載完成”)時，會報錯如下，系統(tǒng)崩潰退出：
android.view.ViewRootImpl$CalledFromWrongThreadException: Only the original thread that created a view hierarchy can touch its views.
錯誤的意思是只有創(chuàng)建View的原始線程才能更新View。出現(xiàn)這樣錯誤的原因是Android中的View不是線程安全的，在Android應用啟動時，會自動創(chuàng)建一個線程，即程序的主線程，主線程負責UI的展示、UI事件消息的派發(fā)處理等等，因此主線程也叫做UI線程，statusTextView是在UI線程中創(chuàng)建的，當我們在DownloadThread線程中去更新UI線程中創(chuàng)建的statusTextView時自然會報上面的錯誤。Android的UI控件是非線程安全的，其實很多平臺的UI控件都是非線程安全的，比如C#的.Net Framework中的UI控件也是非線程安全的，所以不僅僅在Android平臺中存在從一個新線程中去更新UI線程中創(chuàng)建的UI控件的問題。不同的平臺提供了不同的解決方案以實現(xiàn)跨線程跟新UI控件，Android為了解決這種問題引入了Handler機制。
那么Handler到底是什么呢？Handler是Android中引入的一種讓開發(fā)者參與處理線程中消息循環(huán)的機制。每個Hanlder都關聯(lián)了一個線程，每個線程內部都維護了一個消息隊列MessageQueue，這樣Handler實際上也就關聯(lián)了一個消息隊列?？梢酝ㄟ^Handler將Message和Runnable對象發(fā)送到該Handler所關聯(lián)線程的MessageQueue（消息隊列）中，然后該消息隊列一直在循環(huán)拿出一個Message，對其進行處理，處理完之后拿出下一個Message，繼續(xù)進行處理，周而復始。當創(chuàng)建一個Handler的時候，該Handler就綁定了當前創(chuàng)建Hanlder的線程。從這時起，該Hanlder就可以發(fā)送Message和Runnable對象到該Handler對應的消息隊列中，當從MessageQueue取出某個Message時，會讓Handler對其進行處理。
Handler可以用來在多線程間進行通信，在另一個線程中去更新UI線程中的UI控件只是Handler使用中的一種典型案例，除此之外，Handler可以做很多其他的事情。每個Handler都綁定了一個線程，假設存在兩個線程ThreadA和ThreadB，并且HandlerA綁定了 ThreadA，在ThreadB中的代碼執(zhí)行到某處時，出于某些原因，我們需要讓ThreadA執(zhí)行某些代碼，此時我們就可以使用Handler，我們可以在ThreadB中向HandlerA中加入某些信息以告知ThreadA中該做某些處理了。由此可以看出，Handler是Thread的代言人，是多線程之間通信的橋梁，通過Handler，我們可以在一個線程中控制另一個線程去做某事。
Handler提供了兩種方式解決我們在本文一開始遇到的問題（在一個新線程中更新主線程中的UI控件），一種是通過post方法，一種是調用sendMessage方法。
a. 使用post方法，代碼如下：
package ispring.com.testhandler;
import android.app.Activity;
import android.os.Bundle;
import android.os.Handler;
import android.view.View;
import android.widget.Button;
import android.widget.TextView;
public class MainActivity extends Activity implements Button.OnClickListener {
private TextView statusTextView = null;
//uiHandler在主線程中創(chuàng)建，所以自動綁定主線程
private Handler uiHandler = new Handler();
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
statusTextView = (TextView)findViewById(R.id.statusTextView);
Button btnDownload = (Button)findViewById(R.id.btnDownload);
btnDownload.setOnClickListener(this);
System.out.println("Main thread id " + Thread.currentThread().getId());
}
@Override
public void onClick(View v) {
DownloadThread downloadThread = new DownloadThread();
downloadThread.start();
}
class DownloadThread extends Thread{
@Override
public void run() {
try{
System.out.println("DownloadThread id " + Thread.currentThread().getId());
System.out.println("開始下載文件");
//此處讓線程DownloadThread休眠5秒中，模擬文件的耗時過程
Thread.sleep(5000);
System.out.println("文件下載完成");
//文件下載完成后更新UI
Runnable runnable = new Runnable() {
@Override
public void run() {
System.out.println("Runnable thread id " + Thread.currentThread().getId());
MainActivity.this.statusTextView.setText("文件下載完成");
}
};
uiHandler.post(runnable);
}catch (InterruptedException e){
e.printStackTrace();
}
}
}
}
我們在Activity中創(chuàng)建了一個Handler成員變量uiHandler，Handler有個特點，在執(zhí)行new Handler()的時候，默認情況下Handler會綁定當前代碼執(zhí)行的線程，我們在主線程中實例化了uiHandler，所以uiHandler就自動綁定了主線程，即UI線程。當我們在DownloadThread中執(zhí)行完耗時代碼后，我們將一個Runnable對象通過post方法傳入到了Handler中，Handler會在合適的時候讓主線程執(zhí)行Runnable中的代碼，這樣Runnable就在主線程中執(zhí)行了，從而正確更新了主線程中的UI。以下是輸出結果：
[圖片上傳失敗...(image-d23664-1656932874158)]
通過輸出結果可以看出，Runnable中的代碼所執(zhí)行的線程ID與DownloadThread的線程ID不同，而與主線程的線程ID相同，因此我們也由此看出在執(zhí)行了Handler.post(Runnable)這句代碼之后，運行Runnable代碼的線程與Handler所綁定的線程是一致的，而與執(zhí)行Handler.post(Runnable)這句代碼的線程（DownloadThread）無關。
b. 使用sendMessage方法，代碼如下：
package ispring.com.testhandler;
import android.app.Activity;
import android.os.Bundle;
import android.os.Handler;
import android.os.Message;
import android.view.View;
import android.widget.Button;
import android.widget.TextView;
public class MainActivity extends Activity implements Button.OnClickListener {
private TextView statusTextView = null;
//uiHandler在主線程中創(chuàng)建，所以自動綁定主線程
private Handler uiHandler = new Handler(){
@Override
public void handleMessage(Message msg) {
switch (msg.what){
case 1:
System.out.println("handleMessage thread id " + Thread.currentThread().getId());
System.out.println("msg.arg1:" + msg.arg1);
System.out.println("msg.arg2:" + msg.arg2);
MainActivity.this.statusTextView.setText("文件下載完成");
break;
}
}
};
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
statusTextView = (TextView)findViewById(R.id.statusTextView);
Button btnDownload = (Button)findViewById(R.id.btnDownload);
btnDownload.setOnClickListener(this);
System.out.println("Main thread id " + Thread.currentThread().getId());
}
@Override
public void onClick(View v) {
DownloadThread downloadThread = new DownloadThread();
downloadThread.start();
}
class DownloadThread extends Thread{
@Override
public void run() {
try{
System.out.println("DownloadThread id " + Thread.currentThread().getId());
System.out.println("開始下載文件");
//此處讓線程DownloadThread休眠5秒中，模擬文件的耗時過程
Thread.sleep(5000);
System.out.println("文件下載完成");
//文件下載完成后更新UI
Message msg = new Message();
//雖然Message的構造函數(shù)式public的，我們也可以通過以下兩種方式通過循環(huán)對象獲取Message
//msg = Message.obtain(uiHandler);
//msg = uiHandler.obtainMessage();
//what是我們自定義的一個Message的識別碼，以便于在Handler的handleMessage方法中根據(jù)what識別
//出不同的Message，以便我們做出不同的處理操作
msg.what = 1;
//我們可以通過arg1和arg2給Message傳入簡單的數(shù)據(jù)
msg.arg1 = 123;
msg.arg2 = 321;
//我們也可以通過給obj賦值Object類型傳遞向Message傳入任意數(shù)據(jù)
//msg.obj = null;
//我們還可以通過setData方法和getData方法向Message中寫入和讀取Bundle類型的數(shù)據(jù)
//msg.setData(null);
//Bundle data = msg.getData();
//將該Message發(fā)送給對應的Handler
uiHandler.sendMessage(msg);
}catch (InterruptedException e){
e.printStackTrace();
}
}
}
}
通過Message與Handler進行通信的步驟是：
- 重寫Handler的handleMessage方法，根據(jù)Message的what值進行不同的處理操作
- 創(chuàng)建Message對象
雖然Message的構造函數(shù)式public的,我們還可以通過Message.obtain()或Handler.obtainMessage()來獲得一個Message對象（Handler.obtainMessage()內部其實調用了Message.obtain()）。 - 設置Message的what值
Message.what是我們自定義的一個Message的識別碼，以便于在Handler的handleMessage方法中根據(jù)what識別出不同的Message，以便我們做出不同的處理操作。 - 設置Message的所攜帶的數(shù)據(jù)，簡單數(shù)據(jù)可以通過兩個int類型的field arg1和arg2來賦值，并可以在handleMessage中讀取。
- 如果Message需要攜帶復雜的數(shù)據(jù)，那么可以設置Message的obj字段，obj是Object類型，可以賦予任意類型的數(shù)據(jù)?；蛘呖梢酝ㄟ^調用Message的setData方法賦值Bundle類型的數(shù)據(jù)，可以通過getData方法獲取該Bundle數(shù)據(jù)。
- 我們通過Handler.sendMessage(Message)方法將Message傳入Handler中讓其在handleMessage中對其進行處理。
需要說明的是，如果在handleMessage中 不需要判斷Message類型，那么就無須設置Message的what值；而且讓Message攜帶數(shù)據(jù)也不是必須的，只有在需要的時候才需要讓其攜帶數(shù)據(jù)；如果確實需要讓Message攜帶數(shù)據(jù)，應該盡量使用arg1或arg2或兩者，能用arg1和arg2解決的話就不要用obj，因為用arg1和arg2更高效。
[圖片上傳失敗...(image-dfa0b3-1656933290261)]
由上我們可以看出，執(zhí)行handleMessage的線程與創(chuàng)建Handler的線程是同一線程，在本示例中都是主線程。執(zhí)行handleMessage的線程與執(zhí)行uiHandler.sendMessage(msg)的線程沒有關系。
本文主要是對Android中Handler的作用于如何使用進行了初步介紹，如果大家想了解Handler的內部實現(xiàn)原理，可以參見下一篇博文
Android Handler,Message,MessageQueue,Loper源碼解析詳解
這篇文章主要介紹了Android Handler,Message,MessageQueue,Loper源碼解析詳解,本篇文章通過簡要的案例,講解了該項技術的了解與使用,以下就是詳細內容,需要的朋友可以參考下
本文主要是對Handler和消息循環(huán)的實現(xiàn)原理進行源碼分析，如果不熟悉Handler可以參見博文《 Android中Handler的使用》，里面對Android為何以引入Handler機制以及如何使用Handler做了講解。
概括來說，Handler是Android中引入的一種讓開發(fā)者參與處理線程中消息循環(huán)的機制。我們在使用Handler的時候與Message打交道最多，Message是Hanlder機制向開發(fā)人員暴露出來的相關類，可以通過Message類完成大部分操作Handler的功能。但作為程序員，我不能只知道怎么用Handler，還要知道其內部如何實現(xiàn)的。Handler的內部實現(xiàn)主要涉及到如下幾個類: Thread、MessageQueue和Looper。這幾類之間的關系可以用如下的圖來簡單說明：
[圖片上傳失敗...(image-855319-1656933290261)]
Thread是最基礎的，Looper和MessageQueue都構建在Thread之上，Handler又構建在Looper和MessageQueue之上，我們通過Handler間接地與下面這幾個相對底層一點的類打交道。
MessageQueue
最基礎最底層的是Thread，每個線程內部都維護了一個消息隊列——MessageQueue。消息隊列MessageQueue，顧名思義，就是存放消息的隊列（好像是廢話…）。那隊列中存儲的消息是什么呢？假設我們在UI界面上單擊了某個按鈕，而此時程序又恰好收到了某個廣播事件，那我們如何處理這兩件事呢？ 因為一個線程在某一時刻只能處理一件事情，不能同時處理多件事情，所以我們不能同時處理按鈕的單擊事件和廣播事件，我們只能挨個對其進行處理，只要挨個處理就要有處理的先后順序。 為此Android把UI界面上單擊按鈕的事件封裝成了一個Message，將其放入到MessageQueue里面去，即將單擊按鈕事件的Message入棧到消息隊列中，然后再將廣播事件的封裝成以Message，也將其入棧到消息隊列中。也就是說一個Message對象表示的是線程需要處理的一件事情，消息隊列就是一堆需要處理的Message的池。線程Thread會依次取出消息隊列中的消息，依次對其進行處理。MessageQueue中有兩個比較重要的方法，一個是enqueueMessage方法，一個是next方法。enqueueMessage方法用于將一個Message放入到消息隊列MessageQueue中，next方法是從消息隊列MessageQueue中阻塞式地取出一個Message。在Android中，消息隊列負責管理著頂級程序對象（Activity、BroadcastReceiver等）以及由其創(chuàng)建的所有窗口。需要注意的是，消息隊列不是Android平臺特有的，其他的平臺框架也會用到消息隊列，比如微軟的MFC框架等。
Looper
消息隊列MessageQueue只是存儲Message的地方，真正讓消息隊列循環(huán)起來的是Looper，這就好比消息隊列MessageQueue是個水車，那么Looper就是讓水車轉動起來的河水，如果沒有河水，那么水車就是個靜止的擺設，沒有任何用處，Looper讓MessageQueue動了起來，有了活力。
Looper是用來使線程中的消息循環(huán)起來的。默認情況下當我們創(chuàng)建一個新的線程的時候，這個線程里面是沒有消息隊列MessageQueue的。為了能夠讓線程能夠綁定一個消息隊列，我們需要借助于Looper：首先我們要調用Looper的prepare方法，然后調用Looper的Loop方法。典型的代碼如下所示：
class LooperThread extends Thread {
public Handler mHandler;
public void run() {
Looper.prepare();
mHandler = new Handler() {
public void handleMessage(Message msg) {
// process incoming messages here
}
};
Looper.loop();
}
}
需要注意的是Looper.prepare()和Looper.loop()都是在新線程的run方法內調用的，這兩個方法都是靜態(tài)方法。我們通過查看Looper的源碼可以發(fā)現(xiàn)，Looper的構造函數(shù)是private的，也就是在該類的外部不能用new Looper()的形式得到一個Looper對象。根據(jù)我們上面的描述，我們知道線程Thread和Looper是一對一綁定的，也就是一個線程中最多只有一個Looper對象，這也就能解釋Looper的構造函數(shù)為什么是private的了，我們只能通過工廠方法Looper.myLooper()這個靜態(tài)方法獲取當前線程所綁定的Looper。
Looper通過如下代碼保存了對當前線程的引用：
static final ThreadLocal<Looper> sThreadLocal = new ThreadLocal<Looper>();
所以在Looper對象中通過sThreadLocal就可以找到其綁定的線程。ThreadLocal中有個set方法和get方法，可以通過set方法向ThreadLocal中存入一個對象，然后可以通過get方法取出存入的對象。ThreadLocal在new的時候使用了泛型，從上面的代碼中我們可以看到此處的泛型類型是Looper，也就是我們通過ThreadLocal的set和get方法只能寫入和讀取Looper對象類型，如果我們調用其ThreadLocal的set方法傳入一個Looper，將該Looper綁定給了該線程，相應的get就能獲得該線程所綁定的Looper對象。
我們再來看一下Looper.prepare()，該方法是讓Looper做好準備，只有Looper準備好了之后才能調用Looper.loop()方法，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));
}
上面的代碼首先通過sThreadLocal.get()拿到線程sThreadLocal所綁定的Looper對象，由于初始情況下sThreadLocal并沒有綁定Looper，所以第一次調用prepare方法時，sThreadLocal.get()返回null，不會拋出異常。重點是下面的代碼sThreadLocal.set(new Looper(quitAllowed))，首先通過私有的構造函數(shù)創(chuàng)建了一個Looper對象的實例，然后通過sThreadLocal的set方法將該Looper綁定到sThreadLocal中。
這樣就完成了線程sThreadLocal與Looper的雙向綁定：
a. 在Looper內通過sThreadLocal可以獲取Looper所綁定的線程；
b.線程sThreadLocal通過sThreadLocal.get()方法可以獲取該線程所綁定的Looper對象。
上面的代碼執(zhí)行了Looper的構造函數(shù)，我們看一下其代碼：
private Looper(boolean quitAllowed) {
mQueue = new MessageQueue(quitAllowed);
mThread = Thread.currentThread();
}
我們可以看到在其構造函數(shù)中實例化一個消息隊列MessageQueue，并將其賦值給其成員字段mQueue,這樣Looper也就與MessageQueue通過成員字段mQueue進行了關聯(lián)。
在執(zhí)行完了Looper.prepare()之后，我們就可以在外部通過調用Looper.myLooper()獲取當前線程綁定的Looper對象。
myLooper的代碼如下所示：
public static Looper myLooper() {
return sThreadLocal.get();
}
需要注意的是，在一個線程中，只能調用一次Looper.prepare()，因為在第一次調用了Looper.prepare()之后，當前線程就已經(jīng)綁定了Looper，在該線程內第二次調用Looper.prepare()方法的時候，sThreadLocal.get()會返回第一次調用prepare的時候綁定的Looper，不是null，這樣就會走的下面的代碼throw new RuntimeException(“Only one Looper may be created per thread”)，從而拋出異常，告訴開發(fā)者一個線程只能綁定一個Looper對象。
在調用了Looper.prepare()方法之后，當前線程和Looper就進行了雙向的綁定，這時候我們就可以調用Looper.loop()方法讓消息隊列循環(huán)起來了。
需要注意的是Looper.loop()應該在該Looper所綁定的線程中執(zhí)行。
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();
}
}
上面有幾行代碼是關鍵代碼:
-
final MessageQueue queue = me.mQueue;
變量me是通過靜態(tài)方法myLooper()獲得的當前線程所綁定的Looper，me.mQueue是當前線程所關聯(lián)的消息隊列。 -
for (;;)
我們發(fā)現(xiàn)for循環(huán)沒有設置循環(huán)終止的條件，所以這個for循環(huán)是個死循環(huán)。 -
Message msg = queue.next(); // might block
我們通過消息隊列MessageQueue的next方法從消息隊列中取出一條消息，如果此時消息隊列中有Message，那么next方法會立即返回該Message，如果此時消息隊列中沒有Message，那么next方法就會阻塞式地等待獲取Message。 -
msg.target.dispatchMessage(msg);
msg的target屬性是Handler，該代碼的意思是讓Message所關聯(lián)的Handler通過dispatchMessage方法讓Handler處理該Message，關于Handler的dispatchMessage方法將會在下面詳細介紹。
Handler
Handler是暴露給開發(fā)者最頂層的一個類，其構建在Thread、Looper與MessageQueue之上。
Handler具有多個構造函數(shù)，簽名分別如下所示：
- publicHandler()
- publicHandler(Callbackcallback)
- publicHandler(Looperlooper)
- publicHandler(Looperlooper, Callbackcallback)
第1個和第2個構造函數(shù)都沒有傳遞Looper，這兩個構造函數(shù)都將通過調用Looper.myLooper()獲取當前線程綁定的Looper對象，然后將該Looper對象保存到名為mLooper的成員字段中。
第3個和第4個構造函數(shù)傳遞了Looper對象，這兩個構造函數(shù)會將該Looper保存到名為mLooper的成員字段中。
第2個和第4個構造函數(shù)還傳遞了Callback對象，Callback是Handler中的內部接口，需要實現(xiàn)其內部的handleMessage方法，Callback代碼如下:
public interface Callback {
public boolean handleMessage(Message msg);
}
Handler.Callback是用來處理Message的一種手段，如果沒有傳遞該參數(shù)，那么就應該重寫Handler的handleMessage方法，也就是說為了使得Handler能夠處理Message，我們有兩種辦法：
- 向Hanlder的構造函數(shù)傳入一個Handler.Callback對象，并實現(xiàn)Handler.Callback的handleMessage方法
- 無需向Hanlder的構造函數(shù)傳入Handler.Callback對象，但是需要重寫Handler本身的handleMessage方法
也就是說無論哪種方式，我們都得通過某種方式實現(xiàn)handleMessage方法，這點與Java中對Thread的設計有異曲同工之處。
在Java中，如果我們想使用多線程，有兩種辦法： - 向Thread的構造函數(shù)傳入一個Runnable對象，并實現(xiàn)Runnable的run方法
- 無需向Thread的構造函數(shù)傳入Runnable對象，但是要重寫Thread本身的run方法
所以只要用過多線程Thread，應該就對Hanlder這種需要實現(xiàn)handleMessage的兩種方式了然于心了。
我們知道通過sendMessageXXX系列方法可以向消息隊列中添加消息，我們通過源碼可以看出這些方法的調用順序，
sendMessage調用了sendMessageDelayed，sendMessageDelayed又調用了sendMessageAtTime。
Handler中還有一系列的sendEmptyMessageXXX方法，而這些sendEmptyMessageXXX方法在其內部又分別調用了其對應的sendMessageXXX方法。
通過以下調用關系圖我們可以看的更清楚些:
[圖片上傳失敗...(image-646bd4-1656933290261)]
由此可見所有的sendMessageXXX方法和sendEmptyMessageXXX最終都調用了sendMessageAtTime方法。
我們再來看看postXXX方法，會發(fā)現(xiàn)postXXX方法在其內部又調用了對應的sendMessageXXX方法，我們可以查看下sendMessage的源碼:
public final boolean post(Runnable r)
{
return sendMessageDelayed(getPostMessage(r), 0);
}
可以看到內部調用了getPostMessage方法，該方法傳入一個Runnable對象，得到一個Message對象，getPostMessage的源碼如下:
private static Message getPostMessage(Runnable r) {
Message m = Message.obtain();
m.callback = r;
return m;
}
通過上面的代碼我們可以看到在getPostMessage方法中，我們創(chuàng)建了一個Message對象，并將傳入的Runnable對象賦值給Message的callback成員字段，然后返回該Message，然后在post方法中該攜帶有Runnable信息的Message傳入到sendMessageDelayed方法中。由此我們可以看到所有的postXXX方法內部都需要借助sendMessageXXX方法來實現(xiàn)，所以postXXX與sendMessageXXX并不是對立關系，而是postXXX依賴sendMessageXXX，所以postXXX方法可以通過sendMessageXXX方法向消息隊列中傳入消息，只不過通過postXXX方法向消息隊列中傳入的消息都攜帶有Runnable對象（Message.callback）。
我們可以通過如下關系圖看清楚postXXX系列方法與sendMessageXXX方法之間的調用關系：
[圖片上傳失敗...(image-90883e-1656933290261)]
通過分別分析sendEmptyMessageXXX、postXXX方法與sendMessageXXX方法之間的關系，我們可以看到在Handler中所有可以直接或間接向消息隊列發(fā)送Message的方法最終都調用了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);
}
該方法內部調用了enqueueMessage方法，該方法的源碼如下：
private boolean enqueueMessage(MessageQueue queue, Message msg, long uptimeMillis) {
//注意下面這行代碼
msg.target = this;
if (mAsynchronous) {
msg.setAsynchronous(true);
}
//注意下面這行代碼
return queue.enqueueMessage(msg, uptimeMillis);
}
在該方法中有兩件事需要注意：
-
msg.target = this
該代碼將Message的target綁定為當前的Handler -
queue.enqueueMessage
變量queue表示的是Handler所綁定的消息隊列MessageQueue，通過調用queue.enqueueMessage(msg, uptimeMillis)我們將Message放入到消息隊列中。
所以我們通過下圖可以看到完整的方法調用順序：
[圖片上傳失敗...(image-ae565e-1656933290261)]
我們在分析Looper.loop()的源碼時發(fā)現(xiàn)，Looper一直在不斷的從消息隊列中通過MessageQueue的next方法獲取Message，然后通過代碼msg.target.dispatchMessage(msg)讓該msg所綁定的Handler（Message.target）執(zhí)行dispatchMessage方法以實現(xiàn)對Message的處理。
Handler的dispatchMessage的源碼如下：
public void dispatchMessage(Message msg) {
//注意下面這行代碼
if (msg.callback != null) {
handleCallback(msg);
} else {
//注意下面這行代碼
if (mCallback != null) {
if (mCallback.handleMessage(msg)) {
return;
}
}
//注意下面這行代碼
handleMessage(msg);
}
}
我們來分析下這段代碼：
1.首先會判斷msg.callback存不存在，msg.callback是Runnable類型，如果msg.callback存在，那么說明該Message是通過執(zhí)行Handler的postXXX系列方法將Message放入到消息隊列中的，這種情況下會執(zhí)行handleCallback(msg), handleCallback源碼如下：
private static void handleCallback(Message message) {
message.callback.run();
}
這樣我們我們就清楚地看到我們執(zhí)行了msg.callback的run方法，也就是執(zhí)行了postXXX所傳遞的Runnable對象的run方法。
2.如果我們不是通過postXXX系列方法將Message放入到消息隊列中的，那么msg.callback就是null，代碼繼續(xù)往下執(zhí)行，接著我們會判斷Handler的成員字段mCallback存不存在。mCallback是Hanlder.Callback類型的，我們在上面提到過，在Handler的構造函數(shù)中我們可以傳遞Hanlder.Callback類型的對象，該對象需要實現(xiàn)handleMessage方法，如果我們在構造函數(shù)中傳遞了該Callback對象，那么我們就會讓Callback的handleMessage方法來處理Message。
3.如果我們在構造函數(shù)中沒有傳入Callback類型的對象，那么mCallback就為null,那么我們會調用Handler自身的hanldeMessage方法，該方法默認是個空方法，我們需要自己是重寫實現(xiàn)該方法。
綜上，我們可以看到Handler提供了三種途徑處理Message，而且處理有前后優(yōu)先級之分：首先嘗試讓postXXX中傳遞的Runnable執(zhí)行，其次嘗試讓Handler構造函數(shù)中傳入的Callback的handleMessage方法處理，最后才是讓Handler自身的handleMessage方法處理Message。
一圖勝千言
我們在本文討論了Thread、MessageQueue、Looper以及Hanlder的之間的關系，我們可以通過如下一張傳送帶的圖來更形象的理解他們之間的關系。
[圖片上傳失敗...(image-ccc87d-1656933290261)]
在現(xiàn)實生活的生產(chǎn)生活中，存在著各種各樣的傳送帶，傳送帶上面灑滿了各種貨物，傳送帶在發(fā)動機滾輪的帶動下一直在向前滾動，不斷有新的貨物放置在傳送帶的一端，貨物在傳送帶的帶動下送到另一端進行收集處理。
我們可以把傳送帶上的貨物看做是一個個的Message，而承載這些貨物的傳送帶就是裝載Message的消息隊列MessageQueue。傳送帶是靠發(fā)送機滾輪帶動起來轉動的，我們可以把發(fā)送機滾輪看做是Looper，而發(fā)動機的轉動是需要電源的，我們可以把電源看做是線程Thread，所有的消息循環(huán)的一切操作都是基于某個線程的。一切準備就緒，我們只需要按下電源開關發(fā)動機就會轉動起來，這個開關就是Looper的loop方法，當我們按下開關的時候，我們就相當于執(zhí)行了Looper的loop方法，此時Looper就會驅動著消息隊列循環(huán)起來。
那Hanlder在傳送帶模型中相當于什么呢？我們可以將Handler看做是放入貨物以及取走貨物的管道：貨物從一端順著管道劃入傳送帶，貨物又從另一端順著管道劃出傳送帶。我們在傳送帶的一端放入貨物的操作就相當于我們調用了Handler的sendMessageXXX、sendEmptyMessageXXX或postXXX方法，這就把Message對象放入到了消息隊列MessageQueue中了。當貨物從傳送帶的另一端順著管道劃出時，我們就相當于調用了Hanlder的dispatchMessage方法，在該方法中我們完成對Message的處理。
