Framework 源碼解析知識梳理(4) 從源碼角度談談 Handler 的應用
1、前言
其實，這篇文章原本應該叫作"Handler源碼解析"的，可是想一想寫Handler源碼的文章太多了，仍是緩一緩，先寫些不同的，今天，咱們從源碼的角度來總結一下應用Handler的一些場景的原理。面試
2、Handler 的應用
2.1 線程間的通訊
在平時的開發當中，Handler最多見的用法就是用於線程之間的通訊，特別是當咱們在子線程中去處理耗時的任務，當任務完成以後，咱們但願將結果發送到主線程中進行處理，那麼就會使用到Handler，基本的思想以下圖所示： 數據庫
Handler放入在主線程中的循環隊列時，那麼主線程就會收到消息，以後，咱們就能夠在主線程中進行後續的處理，例以下面這樣：
public class MainActivity extends AppCompatActivity {
private Handler mHandler = new Handler() {
@Override
public void handleMessage(Message msg) {
Log.d("Handler", "HandleMessageThreadId=" + Thread.currentThread().getId());
}
};
private void startThread() {
new Thread() {
@Override
public void run() {
super.run();
Log.d("Handler", "ThreadId=" + Thread.currentThread().getId());
mHandler.sendEmptyMessage(0);
}
}.start();
}
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
Log.d("Handler", "MainThreadId=" + Thread.currentThread().getId());
startThread();
}
}
複製代碼
打印出上面的線程Id，能夠看到最後handleMessage收到消息的時候是在主線程當中： bash
2.2 實現延時操做
除了線程間的通訊以外，咱們還能夠經過Handler提供的sendXXXDelay方法，實現延時操做，延時操做有兩種目的：app
- 一種是但願讓不那麼緊急的任務延後執行，例如在應用啓動過程當中，咱們在
onCreate方法中的任務不是那個緊急，那麼能夠經過Handler發送一個延時消息出去，讓它不佔用主線程去渲染布局的資源，從而提升應用的啓動速度。 - 另外一種就是防抖動操做，咱們收到一個命令，並非立刻執行它，而是經過
Handler的sendxxxDelay方法延時，若是在這段事件內又有一個相同的命令來到了，那麼就把以前的消息移除，再放入一個新的延時消息。 例以下面的例子，當咱們點擊一個按鈕以後，咱們不馬上執行任務，而是一段時間以後仍然沒有收到第二次點擊事件採起執行任務：
private Handler mDelayHandler = new Handler() {
@Override
public void handleMessage(Message msg) {
super.handleMessage(msg);
Log.d("Handler", "handleMessage");
}
};
private void performClickDelay() {
Log.d("Handler", "performClickDelay");
mDelayHandler.removeMessages(1);
mDelayHandler.sendEmptyMessageDelayed(1, 500);
}
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
mTv = (TextView) findViewById(R.id.tv);
mTv.setOnClickListener(new View.OnClickListener() {
@Override
public void onClick(View v) {
performClickDelay();
}
});
}
複製代碼
咱們連續屢次點擊按鈕以後，只收到了一次消息： 框架
2.3 使用HandlerThread在異步線程執行耗時操做
因爲Looper實際上是線程的一個私有變量（ThreadLocal），主線程能夠有Looper，子線程一樣也能夠有Looper，只不過從子線程中的Looper中的MessageQueue中取出消息以後，是在子線程當中處理的，那麼咱們就能夠經過它來執行異步操做，其基本思想以下圖所示： 異步
HandlerThread就是基於這一思想來實現的，關於
HandlerThread的內部實現，能夠參考以前的這篇文章
Android 異步任務知識梳理(2) - HandlerThread 源碼解析，它的本質就是當異步線程啓動以後，會初始化這個線程私有的
Looper，所以，當咱們經過
HandlerThread中的
getLooper()方法得到這個
Looper以後，在經過這個
Looper來建立一個
Handler，那麼這個
Handler的
handleMessage回調時所在的線程就是這個異步線程。
下面是一個簡單的事例：async
private void useHandlerThread() {
final HandlerThread handlerThread = new HandlerThread("handlerThread");
System.out.println("MainThreadId=" + Thread.currentThread().getId() + ",handlerThreadId=" + handlerThread.getId());
handlerThread.start();
MyHandler handler = new MyHandler(handlerThread.getLooper());
handler.sendEmptyMessage(0);
}
private class MyHandler extends Handler {
MyHandler(Looper looper) {
super(looper);
}
@Override
public void handleMessage(Message msg) {
super.handleMessage(msg);
System.out.println("handleMessageThreadId=" + Thread.currentThread().getId());
}
}
複製代碼
咱們打印出handleMessage的執行時的線程ID，能夠看到它就是HandlerThread的線程ID，所以咱們就能夠經過發送消息的方式，在異步線程執行一些耗時的操做： ide
2.4 使用AsyncQueryHandler對ContentProvider進行操做
若是你的本地數據使用ContentProvider封裝的，那麼對這些數據的增刪改查操做，爲了避免影響主線程，應該在子線程中進行操做，而AsyncQueryHandler就是系統爲咱們提供的很方便的工具類，它經過Handler + HandlerThread的方式，實現了異步的增刪改查。函數
它是在HandlerThread的基礎之上擴展出來的，其基本思想以下圖所示，這一框架就保證了發起命令和接收回調是在同一個線程，而任務的執行則是在另外一個線程： 工具
固然AsyncQueryHandler限制了只能操做經過ContentProvider封裝的數據，咱們能夠參考它的思想，進行擴展，實現對於數據庫的增刪改查。
2.5 使用Handler機制檢測應用中的卡頓問題
對於每一個應用程序來講，它的入口函數爲ActivityThread中的main()方法：
public static void main(String[] args) {
//...
Looper.prepareMainLooper();
//...
Looper.loop();
throw new RuntimeException("Main thread loop unexpectedly exited");
}
複製代碼
而在main()函數的最後，則構建一個在主線程中的循環隊列，以後應用程序收到的事件以後，還主線程就會被喚醒，進行事件的處理，假如這一處理的事件過長，那麼就會發生ANR，所以，咱們就能夠經過計算主線程中對於單次消息的處理時間，從而間隔地判斷是否存在卡頓問題。 那麼要怎麼知道主線程中單次消息的處理時間呢，咱們查看Looper的源碼：
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
final Printer logging = me.mLogging;
if (logging != null) {
logging.println(">>>>> Dispatching to " + msg.target + " " +
msg.callback + ": " + msg.what);
}
final long traceTag = me.mTraceTag;
if (traceTag != 0 && Trace.isTagEnabled(traceTag)) {
Trace.traceBegin(traceTag, msg.target.getTraceName(msg));
}
try {
msg.target.dispatchMessage(msg);
} finally {
if (traceTag != 0) {
Trace.traceEnd(traceTag);
}
}
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(); } } 複製代碼
對於消息的處理對應這句：
msg.target.dispatchMessage(msg);
複製代碼
而在這句話的先後，則調用了Printer類打印，那麼咱們就能夠經過這兩次打印的之間的時長來得到單次消息的處理時間。
public class MainLoopMonitor {
private static final String MSG_START = ">>>>> Dispatching";
private static final String MSG_END = "<<<<< Finished";
private static final int TIME = 1000;
private Handler mExecuteHandler;
private Runnable mExecuteRunnable;
private static class Holder {
private static final MainLoopMonitor INSTANCE = new MainLoopMonitor();
}
public static MainLoopMonitor getInstance() {
return Holder.INSTANCE;
}
private MainLoopMonitor() {
HandlerThread monitorThread = new HandlerThread("LooperMonitor");
monitorThread.start();
mExecuteHandler = new Handler(monitorThread.getLooper());
mExecuteRunnable = new ExecutorRunnable();
}
public void startMonitor() {
Looper.getMainLooper().setMessageLogging(new Printer() {
@Override
public void println(String x) {
if (x.startsWith(MSG_START)) {
mExecuteHandler.postDelayed(mExecuteRunnable, TIME);
} else if (x.startsWith(MSG_END)) {
mExecuteHandler.removeCallbacks(mExecuteRunnable);
}
}
});
}
private class ExecutorRunnable implements Runnable {
@Override
public void run() {
StringBuilder sb = new StringBuilder();
StackTraceElement[] stackTrace = Looper.getMainLooper().getThread().getStackTrace();
for (StackTraceElement s : stackTrace) {
sb.append(s).append("\n");
}
System.out.println("MainLooperMonitor:" + sb.toString());
}
}
}
複製代碼
假如咱們像下面這樣，在主線程中進行了耗時的操做：
public void anrButton(View view) {
for (int i = 0; i < (1 << 30); i++) {
int b = 6;
}
}
複製代碼
那麼就會打印出下面的堆棧信息：
3、Handler 使用注意事項
在介紹完Handler的這些用法，咱們再來總結一下使用Handler是比較容易犯的一些錯誤。
3.1 內存泄漏
一個比較常見的錯誤就是將定義Handler的子類時將它做爲Activity的內部類，而因爲內部類會默認持有外部類的引用，所以，若是這個內部類的實例在Activity試圖被回收的時候，沒有被銷燬掉，那麼就會致使Activity沒法被回收，從而引發內存泄漏。
而Handler實例沒法被銷燬掉最多見的狀況就是，咱們經過它發送了一個延時消息出去，此時這個消息會被放入到該線程所對應的Looper中的MessageQueue當中，而該消息爲了能在獲得執行以後，回調到對應的Handler，所以它會持有這個Handler的實例。
從引用鏈的角度來看就是下面的狀況：
這個你們見得不少，就很少舉例子了。
3.2 在子線程中實例化 new Handler()
在子線程中new Handler()有下面兩個須要注意的點：
(1) 在 new Handler() 以前調用 Looper.prepare() 方法
另一個錯誤就是咱們在子線程當中，直接調用new Handler()，那麼這時候會拋出異常，例以下面這樣：
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_handler);
new Thread() {
@Override
public void run() {
mHandler = new MyHandler();
}
}.start();
}
複製代碼
拋出的異常爲：
Handler的構造函數中，會去檢查當前線程的
Looper是否已經被初始化：
public Handler(Callback callback, boolean async) {
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;
}
複製代碼
若是沒有，那麼就會拋出上面代碼當中的異常，正確的作法，是須要保證咱們在new Handler以前，要保證當前線程的Looper對象已經被初始化，也就是Looper當中的下面這個方法被調用：
/** 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));
}
複製代碼
(2) 若是但願經過該 Looper 接收消息那麼要調用 Looper.loop() 方法，而且須要放在最後一句調用
假如咱們只調用了prepare()方法，僅僅只是初始化了一個線程的私有的變量，此時是沒法經過這個Looper構建的Handler來接收消息的，例以下面這樣：
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_handler);
new Thread() {
@Override
public void run() {
Looper.prepare();
mHandler = new MyHandler();
}
}.start();
}
public void anrButton(View view) {
mHandler.sendEmptyMessage(0);
}
private static class MyHandler extends Handler {
@Override
public void handleMessage(Message msg) {
Log.e("TAG", "handleMessageId=" + Thread.currentThread().getId());
}
}
複製代碼
此時咱們應當調用loop方法讓這個循環隊列開始工做，而且該調用必定要位於最後一句，由於一旦調用了loop方法，那麼它就會進入等待 -> 收到消息 -> 喚醒 -> 處理消息 -> 等待的循環過程，而這一過程只有等到loop方法返回的時候纔會結束，所以，咱們初始化Handler的語句要放在loop方法以前，相似於下面這樣：
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_handler);
new Thread() {
@Override
public void run() {
Looper.prepare();
mHandler = new MyHandler();
//最後一句再調用
Looper.loop();
}
}.start();
}
複製代碼
4、小結
Handler的機制彷佛已經成爲面試必問的題目，若是你們能在回答完內部的實現原理，再根據這些實現原理引伸出上面的幾個應用和注意事項，能夠加分很多哦~
更多文章，歡迎訪問個人 Android 知識梳理系列：
- Android 知識梳理目錄：www.jianshu.com/p/fd82d1899…
- 我的主頁：lizejun.cn
- 我的知識總結目錄：lizejun.cn/categories/
相關文章
- 1. Framework 源碼解析知識梳理(6) ContentProvider 源碼解析
- 2. Framework 源碼解析知識梳理(5) startService 源碼分析
- 3. 從源碼的角度談談面試常客Handler的內部原理
- 4. 從Android6.0源碼的角度剖析Handler消息機制原理
- 5. 從源碼角度深刻理解Handler處理機制
- 6. 從源碼角度理解postInvalidate和Invalidate
- 7. 從源碼的角度認識AsyncTask
- 8. 從源碼角度深刻理解Retrofit2
- 9. 從源碼的角度來談一談HashMap的內部實現原理
- 10. 從源碼角度解析HashMap特性
- 更多相關文章...
- • Docker 資源彙總 - Docker教程
- • Java操作Neo4j數據庫（附帶源碼） - NoSQL教程
- • 漫談MySQL的鎖機制
- • Java Agent入門實戰（二）-Instrumentation源碼概述
相關標籤/搜索
每日一句
-
每一个你不满意的现在，都有一个你没有努力的曾经。
歡迎關注本站公眾號,獲取更多信息
相關文章
- 1. Framework 源碼解析知識梳理(6) ContentProvider 源碼解析
- 2. Framework 源碼解析知識梳理(5) startService 源碼分析
- 3. 從源碼的角度談談面試常客Handler的內部原理
- 4. 從Android6.0源碼的角度剖析Handler消息機制原理
- 5. 從源碼角度深刻理解Handler處理機制
- 6. 從源碼角度理解postInvalidate和Invalidate
- 7. 從源碼的角度認識AsyncTask
- 8. 從源碼角度深刻理解Retrofit2
- 9. 從源碼的角度來談一談HashMap的內部實現原理
- 10. 從源碼角度解析HashMap特性