/? ?今日科技快訊? ?/

12月16日，華為今日宣布正式推出鴻蒙OS的手機開發者Beta版。相關測試視頻顯示，鴻蒙OS在系統UI方面與現有的EMUI11基本保持一致。此前，華為曾宣布，鴻蒙系統在2021年4月將面向內存128MB-4GB終端設備開源，2021年10月以后將面向4GB以上所有設備開源。

/? ?作者簡介? ?/

本篇文章來自傷心的豬大腸的投稿，整理并分享了Android開發中Handler的相關內容，相信會對大家有所幫助！同時也感謝作者貢獻的精彩文章！

傷心的豬大腸的博客地址：

https://juejin.cn/user/4441682709326958

/? ?正文? ?/

Handler是Android中的消息處理機制，是一種線程間通信的解決方案，同時你也可以理解為它天然的為我們在主線程創建一個隊列，隊列中的消息順序就是我們設置的延遲的時間，如果你想在Android中實現一個隊列的功能，不妨第一時間考慮一下它。本文分為三部分：

Handler的源碼和常見問題的解答

一個線程中最多有多少個Handler，Looper，MessageQueue？

Looper死循環為什么不會導致應用卡死，會耗費大量資源嗎？

子線程的如何更新UI，比如Dialog，Toast等？系統為什么不建議子線程中更新UI?

主線程如何訪問網絡？

如何處理Handler使用不當造成的內存泄漏？

Handler的消息優先級，有什么應用場景？

主線程的Looper何時退出？能否手動退出？

如何判斷當前線程是安卓主線程？

正確創建Message實例的方式？

Handler深層次問題解答

ThreadLocal

epoll機制

Handle同步屏障機制

Handler的鎖相關問題

Handler中的同步方法

Handler在系統以及第三方框架的一些應用

HandlerThread

IntentService

如何打造一個不崩潰的APP

Glide中的運用

Handler的源碼和常見問題的解答

下面來看一下官方對其的定義：

A Handler allows you to send and process Message and Runnable objects associated with a thread's MessageQueue. Each Handler instance is associated with a single thread and that thread's message queue. When you create a new Handler it is bound to a Looper. It will deliver messages and runnables to that Looper's message queue and execute them on that Looper's thread.

大意就是Handler允許你發送Message/Runnable到線程的消息隊列(MessageQueue)中，每個Handler實例和一個線程以及那個線程的消息隊列相關聯。當你創建一個Handler時應該和一個Looper進行綁定（主線程默認已經創建Looper了，子線程需要自己創建Looper），它向Looper的對應的消息隊列傳送Message/Runnable同時在那個Looper所在線程處理對應的Message/Runnable。下面這張圖就是Handler的工作流程。

Handler工作流程圖

可以看到在Thread中，Looper的這個傳送帶其實就一個死循環，它不斷的從消息隊列MessageQueue中不斷的取消息，最后交給Handler.dispatchMessage進行消息的分發，而Handler.sendXXX,Handler.postXXX這些方法把消息發送到消息隊列中MessageQueue，整個模式其實就是一個生產者-消費者模式，源源不斷的生產消息，處理消息，沒有消息時進行休眠。MessageQueue是一個由單鏈表構成的優先級隊列（取的都是頭部，所以說是隊列）。

前面說過，當你創建一個Handler時應該和一個Looper進行綁定（綁定也可以理解為創建，主線程默認已經創建Looper了，子線程需要自己創建Looper），因此我們先來看看主線程中是如何處理的：

//ActivityThread.java public?static?void?main(String[]?args)?{···Looper.prepareMainLooper();···ActivityThread?thread?=?new?ActivityThread();thread.attach(false,?startSeq);if?(sMainThreadHandler?==?null)?{sMainThreadHandler?=?thread.getHandler();}if?(false)?{Looper.myLooper().setMessageLogging(newLogPrinter(Log.DEBUG,?"ActivityThread"));}//?End?of?event?ActivityThreadMain.Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);Looper.loop();throw?new?RuntimeException("Main?thread?loop?unexpectedly?exited"); }

可以看到在ActivityThread中的main方法中，我們先調用了Looper.prepareMainLooper()方法，然后獲取當前線程的Handler，最后調用Looper.loop()。先來看一下Looper.prepareMainLooper()方法。

//Looper.java?? /** *?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();} } //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.prepareMainLooper()方法中創建了當前線程的Looper，同時將Looper實例存放到線程局部變量sThreadLocal(ThreadLocal)中，也就是每個線程有自己的Looper。在創建Looper的時候也創建了該線程的消息隊列，可以看到prepareMainLooper會判斷sMainLooper是否有值，如果調用多次，就會拋出異常，所以也就是說主線程的Looper和MessageQueue只會有一個。同理子線程中調用Looper.prepare()時，會調用prepare(true)方法，如果多次調用，也會拋出每個線程只能由一個Looper的異常，總結起來就是每個線程中只有一個Looper和MessageQueue。

//Looper.java private?Looper(boolean?quitAllowed)?{mQueue?=?new?MessageQueue(quitAllowed);mThread?=?Thread.currentThread(); }

再來看看主線程sMainThreadHandler = thread.getHandler()，getHandler獲取到的實際上就是mH這個Handler。

//ActivityThread.java final?H?mH?=?new?H();? @UnsupportedAppUsagefinal?Handler?getHandler()?{return?mH; }

mH這個Handler是ActivityThread的內部類，通過查看handMessage方法，可以看到這個Handler處理四大組件，Application等的一些消息，比如創建Service，綁定Service的一些消息。

//ActivityThread.java class?H?extends?Handler?{···public?void?handleMessage(Message?msg)?{if?(DEBUG_MESSAGES)?Slog.v(TAG,?">>>?handling:?"?+?codeToString(msg.what));switch?(msg.what)?{case?BIND_APPLICATION:Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER,?"bindApplication");AppBindData?data?=?(AppBindData)msg.obj;handleBindApplication(data);Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);break;case?EXIT_APPLICATION:if?(mInitialApplication?!=?null)?{mInitialApplication.onTerminate();}Looper.myLooper().quit();break;case?RECEIVER:Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER,?"broadcastReceiveComp");handleReceiver((ReceiverData)msg.obj);Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);break;case?CREATE_SERVICE:Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER,?("serviceCreate:?"?+?String.valueOf(msg.obj)));handleCreateService((CreateServiceData)msg.obj);Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);break;case?BIND_SERVICE:Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER,?"serviceBind");handleBindService((BindServiceData)msg.obj);Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);break;case?UNBIND_SERVICE:Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER,?"serviceUnbind");handleUnbindService((BindServiceData)msg.obj);schedulePurgeIdler();Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);break;case?SERVICE_ARGS:Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER,?("serviceStart:?"?+?String.valueOf(msg.obj)));handleServiceArgs((ServiceArgsData)msg.obj);Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);break;case?STOP_SERVICE:Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER,?"serviceStop");handleStopService((IBinder)msg.obj);schedulePurgeIdler();Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);break;···case?APPLICATION_INFO_CHANGED:mUpdatingSystemConfig?=?true;try?{handleApplicationInfoChanged((ApplicationInfo)?msg.obj);}?finally?{mUpdatingSystemConfig?=?false;}break;case?RUN_ISOLATED_ENTRY_POINT:handleRunIsolatedEntryPoint((String)?((SomeArgs)?msg.obj).arg1,(String[])?((SomeArgs)?msg.obj).arg2);break;case?EXECUTE_TRANSACTION:final?ClientTransaction?transaction?=?(ClientTransaction)?msg.obj;mTransactionExecutor.execute(transaction);if?(isSystem())?{//?Client?transactions?inside?system?process?are?recycled?on?the?client?side//?instead?of?ClientLifecycleManager?to?avoid?being?cleared?before?this//?message?is?handled.transaction.recycle();}//?TODO(lifecycler):?Recycle?locally?scheduled?transactions.break;case?RELAUNCH_ACTIVITY:handleRelaunchActivityLocally((IBinder)?msg.obj);break;case?PURGE_RESOURCES:schedulePurgeIdler();break;}Object?obj?=?msg.obj;if?(obj?instanceof?SomeArgs)?{((SomeArgs)?obj).recycle();}if?(DEBUG_MESSAGES)?Slog.v(TAG,?"<<<?done:?"?+?codeToString(msg.what));} }

最后我們查看Looper.loop()方法：

//Looper.java public?static?void?loop()?{//獲取ThreadLocal中的Looperfinal?Looper?me?=?myLooper();···final?MessageQueue?queue?=?me.mQueue;···for?(;;)?{?//死循環//獲取消息Message?msg?=?queue.next();?//?might?blockif?(msg?==?null)?{//?No?message?indicates?that?the?message?queue?is?quitting.return;}···msg.target.dispatchMessage(msg);···//回收復用??msg.recycleUnchecked();} }

在loop方法中是一個死循環，在這里從消息隊列中不斷的獲取消息queue.next()，然后通過Handler(msg.target)進行消息的分發，其實并沒有什么具體的綁定，因為Handler在每個線程中對應只有一個Looper和消息隊列MessageQueue，自然要靠它來處理，也就是是調用Looper.loop()方法。在Looper.loop()的死循環中不斷的取消息，最后回收復用。

這里要強調一下Message中的參數target(Handler)，正是這個變量，每個Message才能找到對應的Handler進行消息分發，讓多個Handler同時工作。

再來看看子線程中是如何處理的，首先在子線程中創建一個Handler并發送Runnable。

@Overrideprotected?void?onCreate(@Nullable?Bundle?savedInstanceState)?{super.onCreate(savedInstanceState);setContentView(R.layout.activity_three);new?Thread(new?Runnable()?{@Overridepublic?void?run()?{new?Handler().post(new?Runnable()?{@Overridepublic?void?run()?{Toast.makeText(HandlerActivity.this,"toast",Toast.LENGTH_LONG).show();}});}}).start();}

運行后可以看到錯誤日志，可以看到提示我們需要在子線程中調用Looper.prepare()方法，實際上就是要創建一個Looper和你的Handler進行“關聯”。

???---------?beginning?of?crash 2020-11-09?15:51:03.938?21122-21181/com.jackie.testdialog?E/AndroidRuntime:?FATAL?EXCEPTION:?Thread-2Process:?com.jackie.testdialog,?PID:?21122java.lang.RuntimeException:?Can't?create?handler?inside?thread?Thread[Thread-2,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.jackie.testdialog.HandlerActivity$1.run(HandlerActivity.java:31)at?java.lang.Thread.run(Thread.java:919)

添加Looper.prepare()創建Looper，同時調用Looper.loop()方法開始處理消息。

?@Overrideprotected?void?onCreate(@Nullable?Bundle?savedInstanceState)?{super.onCreate(savedInstanceState);setContentView(R.layout.activity_three);new?Thread(new?Runnable()?{@Overridepublic?void?run()?{//創建Looper，MessageQueueLooper.prepare();new?Handler().post(new?Runnable()?{@Overridepublic?void?run()?{Toast.makeText(HandlerActivity.this,"toast",Toast.LENGTH_LONG).show();}});//開始處理消息Looper.loop();}}).start();}

這里需要注意在所有事情處理完成后應該調用quit方法來終止消息循環，否則這個子線程就會一直處于循環等待的狀態，因此不需要的時候終止Looper，調用Looper.myLooper().quit()。

看完上面的代碼可能你會有一個疑問，在子線程中更新UI（進行Toast）不會有問題嗎，我們Android不是不允許在子線程更新UI嗎，實際上并不是這樣的，在ViewRootImpl中的checkThread方法會校驗mThread != Thread.currentThread(),mThread的初始化是在ViewRootImpl的的構造器中，也就是說一個創建ViewRootImpl線程必須和調用checkThread所在的線程一致，UI的更新并非只能在主線程才能進行。

void?checkThread()?{if?(mThread?!=?Thread.currentThread())?{throw?new?CalledFromWrongThreadException("Only?the?original?thread?that?created?a?view?hierarchy?can?touch?its?views.");} }

這里需要引入一些概念，Window是Android中的窗口，每個Activity和Dialog，Toast分別對應一個具體的Window，Window是一個抽象的概念，每一個Window都對應著一個View和一個ViewRootImpl，Window和View通過ViewRootImpl來建立聯系，因此，它是以View的形式存在的。我們來看一下Toast中的ViewRootImpl的創建過程，調用toast的show方法最終會調用到其handleShow方法。

//Toast.java public?void?handleShow(IBinder?windowToken)?{···if?(mView?!=?mNextView)?{//?Since?the?notification?manager?service?cancels?the?token?right//?after?it?notifies?us?to?cancel?the?toast?there?is?an?inherent//?race?and?we?may?attempt?to?add?a?window?after?the?token?has?been//?invalidated.?Let?us?hedge?against?that.try?{mWM.addView(mView,?mParams);?//進行ViewRootImpl的創建trySendAccessibilityEvent();}?catch?(WindowManager.BadTokenException?e)?{/*?ignore?*/}} }

這個mWM（WindowManager）的最終實現者是WindowManagerGlobal，其的addView方法中會創建ViewRootImpl，然后進行root.setView(view, wparams, panelParentView)，通過ViewRootImpl來更新界面并完成Window的添加過程。

//WindowManagerGlobal.java root?=?new?ViewRootImpl(view.getContext(),?display);?//創建ViewRootImplview.setLayoutParams(wparams);mViews.add(view);mRoots.add(root);mParams.add(wparams);//?do?this?last?because?it?fires?off?messages?to?start?doing?thingstry?{//ViewRootImplroot.setView(view,?wparams,?panelParentView);}?catch?(RuntimeException?e)?{//?BadTokenException?or?InvalidDisplayException,?clean?up.if?(index?>=?0)?{removeViewLocked(index,?true);}throw?e;} }

setView內部會通過requestLayout來完成異步刷新請求，同時也會調用checkThread方法來檢驗線程的合法性。

@Override public?void?requestLayout()?{if?(!mHandlingLayoutInLayoutRequest)?{checkThread();mLayoutRequested?=?true;scheduleTraversals();} }

因此，我們的ViewRootImpl的創建是在子線程，所以mThread的值也是子線程，同時我們的更新也是在子線程，所以不會產生異常，同時也可以參考這篇文章分析，寫的非常詳細。同理下面的代碼也可以驗證這個情況。

//子線程中調用???? public?void?showDialog(){new?Thread(new?Runnable()?{@Overridepublic?void?run()?{//創建Looper，MessageQueueLooper.prepare();new?Handler().post(new?Runnable()?{@Overridepublic?void?run()?{builder?=?new?AlertDialog.Builder(HandlerActivity.this);builder.setTitle("jackie");alertDialog?=?builder.create();alertDialog.show();alertDialog.hide();}});//開始處理消息Looper.loop();}}).start();}

在子線程中調用showDialog方法，先調用alertDialog.show()方法，再調用alertDialog.hide()方法，hide方法只是將Dialog隱藏，并沒有做其他任何操作(沒有移除Window)，然后再在主線程調用alertDialog.show()；便會拋出Only the original thread that created a view hierarchy can touch its views異常了。

2020-11-09?18:35:39.874?24819-24819/com.jackie.testdialog?E/AndroidRuntime:?FATAL?EXCEPTION:?mainProcess:?com.jackie.testdialog,?PID:?24819android.view.ViewRootImpl$CalledFromWrongThreadException:?Only?the?original?thread?that?created?a?view?hierarchy?can?touch?its?views.at?android.view.ViewRootImpl.checkThread(ViewRootImpl.java:8191)at?android.view.ViewRootImpl.requestLayout(ViewRootImpl.java:1420)at?android.view.View.requestLayout(View.java:24454)at?android.view.View.setFlags(View.java:15187)at?android.view.View.setVisibility(View.java:10836)at?android.app.Dialog.show(Dialog.java:307)at?com.jackie.testdialog.HandlerActivity$2.onClick(HandlerActivity.java:41)at?android.view.View.performClick(View.java:7125)at?android.view.View.performClickInternal(View.java:7102)

所以在線程中更新UI的重點是創建它的ViewRootImpl和checkThread所在的線程是否一致。

如何在主線程中訪問網絡

在網絡請求之前添加如下代碼：

StrictMode.ThreadPolicy?policy?=?new?StrictMode.ThreadPolicy.Builder().permitNetwork().build(); StrictMode.setThreadPolicy(policy);

StrictMode（嚴苛模式）Android2.3引入，用于檢測兩大問題：ThreadPolicy（線程策略）和VmPolicy(VM策略)，這里把嚴苛模式的網絡檢測關了，就可以在主線程中執行網絡操作了，一般是不建議這么做的。

系統為什么不建議在子線程中訪問UI？

這是因為 Android 的UI控件不是線程安全的，如果在多線程中并發訪問可能會導致UI控件處于不可預期的狀態，那么為什么系統不對UI控件的訪問加上鎖機制呢？缺點有兩個：

首先加上鎖機制會讓UI訪問的邏輯變得復雜

鎖機制會降低UI訪問的效率，因為鎖機制會阻塞某些線程的執行。

所以最簡單且高效的方法就是采用單線程模型來處理UI操作。（安卓開發藝術探索）

子線程如何通知主線程更新UI（都是通過Handle發送消息到主線程操作UI的）

主線程中定義 Handler，子線程通過 mHandler 發送消息，主線程 Handler 的 handleMessage 更新UI。

用 Activity 對象的 runOnUiThread 方法。

創建 Handler，傳入 getMainLooper。

View.post(Runnable r) 。

Looper死循環為什么不會導致應用卡死，會耗費大量資源嗎？

從前面的主線程、子線程的分析可以看出，Looper會在線程中不斷的檢索消息，如果是子線程的Looper死循環，一旦任務完成，用戶應該手動退出，而不是讓其一直休眠等待。（引用自Gityuan）線程其實就是一段可執行的代碼，當可執行的代碼執行完成后，線程的生命周期便該終止了，線程退出。而對于主線程，我們是絕不希望會被運行一段時間，自己就退出，那么如何保證能一直存活呢？簡單做法就是可執行代碼是能一直執行下去的，死循環便能保證不會被退出，例如，binder 線程也是采用死循環的方法，通過循環方式不同與 Binder 驅動進行讀寫操作，當然并非簡單地死循環，無消息時會休眠。Android是基于消息處理機制的，用戶的行為都在這個Looper循環中，我們在休眠時點擊屏幕，便喚醒主線程繼續進行工作。

主線程的死循環一直運行是不是特別消耗 CPU 資源呢？其實不然，這里就涉及到 Linux ?pipe/epoll機制，簡單說就是在主線程的 MessageQueue 沒有消息時，便阻塞在 loop 的 queue.next() 中的 nativePollOnce() 方法里，此時主線程會釋放 CPU 資源進入休眠狀態，直到下個消息到達或者有事務發生，通過往 pipe 管道寫端寫入數據來喚醒主線程工作。這里采用的 epoll 機制，是一種IO多路復用機制，可以同時監控多個描述符，當某個描述符就緒(讀或寫就緒)，則立刻通知相應程序進行讀或寫操作，本質同步I/O，即讀寫是阻塞的。所以說，主線程大多數時候都是處于休眠狀態，并不會消耗大量CPU資源。

主線程的Looper何時退出

在App退出時，ActivityThread中的mH（Handler）收到消息后，執行退出。

//ActivityThread.java case?EXIT_APPLICATION:if?(mInitialApplication?!=?null)?{mInitialApplication.onTerminate();}Looper.myLooper().quit();break;

如果你嘗試手動退出主線程Looper，便會拋出如下異常。

Caused?by:?java.lang.IllegalStateException:?Main?thread?not?allowed?to?quit.at?android.os.MessageQueue.quit(MessageQueue.java:428)at?android.os.Looper.quit(Looper.java:354)at?com.jackie.testdialog.Test2Activity.onCreate(Test2Activity.java:29)at?android.app.Activity.performCreate(Activity.java:7802)at?android.app.Activity.performCreate(Activity.java:7791)at?android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1299)at?android.app.ActivityThread.performLaunchActivity(ActivityThread.java:3245)at?android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:3409)?at?android.app.servertransaction.LaunchActivityItem.execute(LaunchActivityItem.java:83)?at?android.app.servertransaction.TransactionExecutor.executeCallbacks(TransactionExecutor.java:135)?at?android.app.servertransaction.TransactionExecutor.execute(TransactionExecutor.java:95)?at?android.app.ActivityThread$H.handleMessage(ActivityThread.java:2016)?at?android.os.Handler.dispatchMessage(Handler.java:107)?at?android.os.Looper.loop(Looper.java:214)?at?android.app.ActivityThread.main(ActivityThread.java:7356)?at?java.lang.reflect.Method.invoke(Native?Method)?at?com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:492)?at?com.android.internal.os.ZygoteInit.main(ZygoteInit.java:930)

為什么不允許退出呢，因為主線程不允許退出，一旦退出就意味著程序掛了，退出也不應該用這種方式退出。

Handler的消息處理順序

在Looper執行消息循環loop()時會執行下面這行代碼，msg.targe就是這個Handler對象。

msg.target.dispatchMessage(msg);

我們來看看dispatchMessage的源碼：

??public?void?dispatchMessage(@NonNull?Message?msg)?{if?(msg.callback?!=?null)?{handleCallback(msg);}?else?{//如果?callback?處理了該?msg?并且返回?true，?就不會再回調?handleMessageif?(mCallback?!=?null)?{if?(mCallback.handleMessage(msg))?{return;}}handleMessage(msg);}}

1.如果Message這個對象有CallBack回調的話，這個CallBack實際上是個Runnable，就只執行這個回調，然后就結束了，創建該Message的CallBack代碼如下：

Message?msgCallBack?=?Message.obtain(handler,?new?Runnable()?{@Overridepublic?void?run()?{} });

而handleCallback方法中調用的是Runnable的run方法。

private?static?void?handleCallback(Message?message)?{message.callback.run(); }

2.如果Message對象沒有CallBack回調，進入else分支判斷Handler的CallBack是否為空，不為空執行CallBack的handleMessage方法，然后return，構建Handler的CallBack代碼如下：

Handler.Callback?callback?=?new?Handler.Callback()?{@Overridepublic?boolean?handleMessage(@NonNull?Message?msg)?{//retrun?true，就不執行下面的邏輯了，可以用于做優先級的處理return?false;} };

3.最后才調用到Handler的handleMessage()函數，也就是我們經常去重寫的函數，在該方法中做消息的處理。

使用場景

可以看到Handler.Callback 有優先處理消息的權利 ，當一條消息被 Callback 處理并攔截（返回 true），那么 Handler 的 handleMessage(msg) 方法就不會被調用了；如果 Callback 處理了消息，但是并沒有攔截，那么就意味著一個消息可以同時被 Callback 以及 Handler 處理。我們可以利用CallBack這個攔截來攔截Handler的消息。

場景：Hook ActivityThread.mH ， 在 ActivityThread 中有個成員變量 mH ，它是個 Handler，又是個極其重要的類，幾乎所有的插件化框架都使用了這個方法。

Handler.post(Runnable r)方法的執行邏輯

我們需要分析平時常用的Handler.post(Runnable r)方法是如何執行的，是否新創建了一個線程了呢，實際上并沒有，這個Runnable對象只是被調用了它的run方法，根本并沒有啟動一個線程，源碼如下：

//Handler.java public?final?boolean?post(@NonNull?Runnable?r)?{return??sendMessageDelayed(getPostMessage(r),?0); }private?static?Message?getPostMessage(Runnable?r)?{Message?m?=?Message.obtain();m.callback?=?r;return?m;}

最終該Runnable對象被包裝成一個Message對象，也就是這個Runnable對象就是該Message的CallBack對象了，有優先執行的權利了。

Handler是如何進行線程切換的

原理很簡單，線程間是共享資源的，子線程通過handler.sendXXX，handler.postXXX等方法發送消息，然后通過Looper.loop()在消息隊列中不斷的循環檢索消息，最后交給handle.dispatchMessage方法進行消息的分發處理。

如何處理Handler使用不當造成的內存泄漏？

有延時消息，在界面關閉后及時移除Message/Runnable，調用handler.removeCallbacksAndMessages(null)

內部類導致的內存泄漏改為靜態內部類，并對上下文或者Activity/Fragment使用弱引用。

同時還有一個很關鍵的點，如果有個延時消息，當界面關閉時，該Handler中的消息還沒有處理完畢，那么最終這個消息是怎么處理的？經過測試，比如我打開界面后延遲10s發送消息，關閉界面，最終在Handler（匿名內部類創建的）的handMessage方法中還是會收到消息（打印日志）。因為會有一條MessageQueue -> Message -> Handler -> Activity的引用鏈，所以Handler不會被銷毀，Activity也不會被銷毀。

正確創建Message實例

通過 Message 的靜態方法 Message.obtain() 獲取；

通過 Handler 的公有方法 handler.obtainMessage()

所有的消息會被回收，放入sPool中，使用享元設計模式。

Handler深層次問題解答

ThreadLocal

ThreadLocal為每個線程都提供了變量的副本，使得每個線程在某一時間訪問到的并非同一個對象，這樣就隔離了多個線程對數據的數據共享。如果讓你設計一個ThreadLocal，ThreadLocal 的目標是讓不同的線程有不同的變量 V，那最直接的方法就是創建一個 Map，它的 Key 是線程，Value 是每個線程擁有的變量 V，ThreadLocal 內部持有這樣的一個 Map 就可以了。你可能會設計成這樣。

實際上Java的實現是下面這樣，Java 的實現里面也有一個 Map，叫做 ThreadLocalMap，不過持有 ThreadLocalMap 的不是 ThreadLocal，而是 Thread。Thread 這個類內部有一個私有屬性 threadLocals，其類型就是 ThreadLocalMap，ThreadLocalMap 的 Key 是 ThreadLocal。

精簡之后的代碼如下：

class?Thread?{//內部持有ThreadLocalMapThreadLocal.ThreadLocalMap?threadLocals; } class?ThreadLocal<T>{public?T?get()?{//首先獲取線程持有的//ThreadLocalMapThreadLocalMap?map?=Thread.currentThread().threadLocals;//在ThreadLocalMap中//查找變量Entry?e?=?map.getEntry(this);return?e.value;??}static?class?ThreadLocalMap{//內部是數組而不是MapEntry[]?table;//根據ThreadLocal查找EntryEntry?getEntry(ThreadLocal?key){//省略查找邏輯}//Entry定義static?class?Entry?extendsWeakReference<ThreadLocal>{Object?value;}} }

在Java的實現方案中，ThreadLocal僅僅只是一個代理工具類，內部并不持有任何線程相關的數據，所有和線程相關的數據都存儲在Thread里面，這樣的設計從數據的親緣性上來講，ThreadLocalMap屬于Thread也更加合理。所以ThreadLocal的get方法，其實就是拿到每個線程獨有的ThreadLocalMap。

還有一個原因，就是不容易產生內存泄漏，如果用我們的設計方案，ThreadLocal持有的Map會持有Thread對象的引用，這就意味著只要ThreadLocal對象存在，那么Map中的Thread對象就永遠不會被回收。ThreadLocal的生命周期往往都比線程要長，所以這種設計方案很容易導致內存泄漏。

而Java的實現中Thread持有ThreadLocalMap，而且ThreadLocalMap里對ThreadLocal的引用還是弱引用，所以只要Thread對象可以被回收，那么ThreadLocalMap就能被回收。Java的實現方案雖然看上去復雜一些，但是更安全。

ThreadLocal與內存泄漏

但是一切并不總是那么完美，如果在線程池中使用ThreadLocal可能會導致內存泄漏，原因是線程池中線程的存活時間太長，往往和程序都是同生共死的，這就意味著Thread持有的ThreadLocalMap一直都不會被回收，再加上ThreadLocalMap中的Entry對ThreadLocal是弱引用，所以只要ThreadLocal結束了自己的生命周期是可以被回收掉的。但是Entry中的Value卻是被Entry強引用的，所以即便Value的生命周期結束了，Value也是無法被回收的，從而導致內存泄漏。

所以我們可以通過try{}finally{}方案來手動釋放資源

ExecutorService?es; ThreadLocal?tl; es.execute(()->{//ThreadLocal增加變量tl.set(obj);try?{//?省略業務邏輯代碼}finally?{//手動清理ThreadLocal?tl.remove();} });

epoll機制

epoll機制在Handler中的應用，在主線程的 MessageQueue 沒有消息時，便阻塞在 loop 的 queue.next() 中的 nativePollOnce() 方法里，最終調用到epoll_wait()進行阻塞等待。此時主線程會釋放 CPU 資源進入休眠狀態，直到下個消息到達或者有事務發生，通過往 pipe 管道寫端寫入數據來喚醒主線程工作。這里采用的 epoll 機制，是一種IO多路復用機制，可以同時監控多個描述符，當某個描述符就緒(讀或寫就緒)，則立刻通知相應程序進行讀或寫操作，本質同步I/O，即讀寫是阻塞的。所以說，主線程大多數時候都是處于休眠狀態，并不會消耗大量CPU資源。

表面上看epoll的性能最好，但是在連接數少并且連接都十分活躍的情況下，select和poll的性能可能比epoll好，畢竟epoll的通知機制需要很多函數回調。

select低效是因為每次它都需要輪詢。但低效也是相對的，視情況而定，也可通過良好的設計改善。

之所以選擇Handler底層選擇epoll機制，我感覺是epoll在效率上更高。在select/poll中，進程只有在調用一定的方法后，內核才對所有監視的文件描述符進行掃描，而epoll事先通過epoll_ctl()來注冊一個文件描述符，一旦基于某個文件描述符就緒時，內核會采用類似callback的回調機制，迅速激活這個文件描述符，當進程調用epoll_wait()時便得到通知。(此處去掉了遍歷文件描述符，而是通過監聽回調的的機制。這正是epoll的魅力所在。)

Handler的同步屏障機制

如果有一個緊急的Message需要優先處理，該怎么做？這其實涉及到架構方面的設計了，通用場景和特殊場景的設計。你可能會想到sendMessageAtFrontOfQueue()這個方法，實際也遠遠不只是如此，Handler中加入了同步屏障這種機制，來實現[異步消息優先]執行的功能。

postSyncBarrier()發送同步屏障，removeSyncBarrier()移除同步屏障。

同步屏障的作用可以理解成攔截同步消息的執行，主線程的 Looper 會一直循環調用 MessageQueue 的 next() 來取出隊頭的 Message 執行，當 Message 執行完后再去取下一個。當 next() 方法在取 Message 時發現隊頭是一個同步屏障的消息時，就會去遍歷整個隊列，只尋找設置了異步標志的消息，如果有找到異步消息，那么就取出這個異步消息來執行，否則就讓 next() 方法陷入阻塞狀態。如果 next() 方法陷入阻塞狀態，那么主線程此時就是處于空閑狀態的，也就是沒在干任何事。所以，如果隊頭是一個同步屏障的消息的話，那么在它后面的所有同步消息就都被攔截住了，直到這個同步屏障消息被移除出隊列，否則主線程就一直不會去處理同步屏幕后面的同步消息。

而所有消息默認都是同步消息，只有手動設置了異步標志，這個消息才會是異步消息。另外，同步屏障消息只能由內部來發送，這個接口并沒有公開給我們使用。

Choreographer 里所有跟 message 有關的代碼，你會發現，都手動設置了異步消息的標志，所以這些操作是不受到同步屏障影響的。這樣做的原因可能就是為了盡可能保證上層 app 在接收到屏幕刷新信號時，可以在第一時間執行遍歷繪制 View 樹的工作。

Choreographer 過程中的動作也都是異步消息，這樣可以確保 Choreographer 的順利運轉，也確保了第一時間執行 doTraversal（doTraversal → performTraversals 就是執行 view 的 layout、measure、draw），這個過程中如果有其他同步消息，也無法得到處理，都要等到 doTraversal 之后。

因為主線程中如果有太多消息要執行，而這些消息又是根據時間戳進行排序，如果不加一個同步屏障的話，那么遍歷繪制 View 樹的工作就可能被迫延遲執行，因為它也需要排隊，那么就有可能出現當一幀都快結束的時候才開始計算屏幕數據，那即使這次的計算少于 16.6ms，也同樣會造成丟幀現象。

那么，有了同步屏障消息的控制就能保證每次一接收到屏幕刷新信號就第一時間處理遍歷繪制 View 樹的工作么？

只能說，同步屏障是盡可能去做到，但并不能保證一定可以第一時間處理。因為，同步屏障是在 scheduleTraversals() 被調用時才發送到消息隊列里的，也就是說，只有當某個 View 發起了刷新請求時，在這個時刻后面的同步消息才會被攔截掉。如果在 scheduleTraversals() 之前就發送到消息隊列里的工作仍然會按順序依次被取出來執行。

下面是部分詳細的分析：

WindowManager維護著所有的Activity的DecorView和ViewRootImpl。在前面我們講過，WindowManagerGlobal的addView方法中中初始化了ViewRootImpl，然后調用它的setView方法，將DecorView作為參數傳遞了進去。所以我們看看ViewRootImpl做了什么。

//ViewRootImpl.java //view是DecorView public?void?setView(View?view,?WindowManager.LayoutParams?attrs,?View?panelParentView)?{synchronized?(this)?{if?(mView?==?null)?{mView?=?view;···//?Schedule?the?first?layout?-before-?adding?to?the?window//?manager,?to?make?sure?we?do?the?relayout?before?receiving//?any?other?events?from?the?system.requestLayout();?//發起布局請求···view.assignParent(this);?//將當前ViewRootImpl對象this作為參數調用了DecorView的????????????????????assignParent···}} }

在setView()方法里調用了DecorView的assignParent。

//View.java /**?Caller?is?responsible?for?calling?requestLayout?if?necessary.*?(This?allows?addViewInLayout?to?not?request?a?new?layout.)*/ @UnsupportedAppUsage void?assignParent(ViewParent?parent)?{if?(mParent?==?null)?{mParent?=?parent;}?else?if?(parent?==?null)?{mParent?=?null;}?else?{throw?new?RuntimeException("view?"?+?this?+?"?being?added,?but"+?"?it?already?has?a?parent");} }

參數是ViewParent，而ViewRootImpl是實現了ViewParent接口的，所以在這里就將DecorView和ViewRootImpl綁定起來了。每個Activity的根布局都是DecorView，而DecorView的parent又是ViewRootImpl，所以在子View里執行invalidate()之類的工作，循環找parent，最后都會找到ViewRootImpl里來。所以實際上View的刷新都是由ViewRootImpl來控制的。

即使是界面上一個小小的 View 發起了重繪請求時，都要層層走到 ViewRootImpl，由它來發起重繪請求，然后再由它來開始遍歷 View 樹，一直遍歷到這個需要重繪的 View 再調用它的 onDraw() 方法進行繪制。

View.invalidate()請求重繪的操作最后調用到的是ViewRootImpl.scheduleTraversals()，而ViewRootImpl.setView()方法中調用了requestLayout方法。

@Override public?void?requestLayout()?{if?(!mHandlingLayoutInLayoutRequest)?{checkThread();mLayoutRequested?=?true;scheduleTraversals();} }

最終也調用到了scheduleTraversals()方法，其實這個方法是屏幕刷新的關鍵。

其實打開一個 Activity，當它的 onCreate---onResume 生命周期都走完后，才將它的 DecoView 與新建的一個 ViewRootImpl 對象綁定起來，同時開始安排一次遍歷 View 任務也就是繪制 View 樹的操作等待執行，然后將 DecoView 的 parent 設置成 ViewRootImpl 對象。所以我們在onCreate~onResume中獲取不到View寬高，界面的繪制也是在onResume之后才開始執行的。

ViewRootImpl.scheduleTraversals()的一系列分析以及屏幕刷新機制可以參考這篇文章，這里的內容也是大部分參考它的，同步屏障相關的分析內容也在里面。Choreographer主要作用是協調動畫，輸入和繪制的時間，它從顯示子系統接收定時脈沖（例如垂直同步），然后安排渲染下一個frame的一部分工作。可通過Choreographer.getInstance().postFrameCallback()來監聽幀率情況。

public?class?FPSFrameCallback?implements?Choreographer.FrameCallback?{private?static?final?String?TAG?=?"FPS_TEST";private?long?mLastFrameTimeNanos;private?long?mFrameIntervalNanos;public?FPSFrameCallback(long?lastFrameTimeNanos)?{mLastFrameTimeNanos?=?lastFrameTimeNanos;//每一幀渲染時間?多少納秒mFrameIntervalNanos?=?(long)?(1000000000?/?60.0);}@Overridepublic?void?doFrame(long?frameTimeNanos)?{?//Vsync信號到來的時間frameTimeNanos//初始化時間if?(mLastFrameTimeNanos?==?0)?{//上一幀的渲染時間mLastFrameTimeNanos?=?frameTimeNanos;}final?long?jitterNanos?=?frameTimeNanos?-?mLastFrameTimeNanos;if?(jitterNanos?>=?mFrameIntervalNanos)?{final?long?skippedFrames?=?jitterNanos?/?mFrameIntervalNanos;if?(skippedFrames?>?5)?{Log.d(TAG,?"Skipped?"?+?skippedFrames?+?"?frames!??"+?"The?application?may?be?doing?too?much?work?on?its?main?thread.");}}mLastFrameTimeNanos?=?frameTimeNanos;//注冊下一幀回調Choreographer.getInstance().postFrameCallback(this);} }

調用方式在Application中注冊。

Choreographer.getInstance().postFrameCallback(FPSFrameCallback(System.nanoTime()))

丟幀的原因：造成丟幀大體上有兩類原因，一是遍歷繪制 View 樹計算屏幕數據的時間超過了 16.6ms；二是，主線程一直在處理其他耗時的消息，導致遍歷繪制 View 樹的工作遲遲不能開始，從而超過了 16.6 ms 底層切換下一幀畫面的時機。

Handler鎖相關問題

既然可以存在多個Handler往MessageQueue中添加數據（發送消息時各個Handler可能處于不同線程），那它內部是如何確保線程安全的？

Handler.sendXXX，Handler.postXXX最終會會調到MessageQueue的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)?{···}???? }

其內部通過synchronized關鍵字保證線程安全。同時messagequeue.next()內部也會通過synchronized加鎖，確保取的時候線程安全，同時插入也會加鎖。這個問題其實不難，只是看你有沒有了解源碼。

Handler中的同步方法

如何讓handler.post消息執行之后然后再繼續往下執行，同步方法runWithScissors。

public?final?boolean?runWithScissors(@NonNull?Runnable?r,?long?timeout)?{if?(r?==?null)?{throw?new?IllegalArgumentException("runnable?must?not?be?null");}if?(timeout?<?0)?{throw?new?IllegalArgumentException("timeout?must?be?non-negative");}if?(Looper.myLooper()?==?mLooper)?{r.run();return?true;}BlockingRunnable?br?=?new?BlockingRunnable(r);return?br.postAndWait(this,?timeout); }

Handler在系統以及第三方框架的一些應用

HandlerThread

HandlerThread繼承于Thread，顧名思義，實際上是Handler和Thread的一個封裝，已經為我們封裝的很好很安全了，內部也通過synchronized來保證線程安全，比如getLooper方法

public?Looper?getLooper()?{if?(!isAlive())?{return?null;}//?If?the?thread?has?been?started,?wait?until?the?looper?has?been?created.synchronized?(this)?{while?(isAlive()?&&?mLooper?==?null)?{try?{wait();}?catch?(InterruptedException?e)?{}}}return?mLooper;}

在線程的run方法里，所以當線程啟動之后才能創建Looper并賦值給mLooper，這里的阻塞就是為了等待Looper的創建成功。同時該方法是用Public修飾的，說明該方法是提供外部調用的，Looper創建成功提供給外部使用。

IntentService

簡單看一下源碼就能看到Handler的應用，Handler的handMessage最終會回調到onHandleIntent方法。

public?abstract?class?IntentService?extends?Service?{private?volatile?Looper?mServiceLooper;@UnsupportedAppUsageprivate?volatile?ServiceHandler?mServiceHandler;

如何打造一個不崩潰的程序

打造一個不崩潰的程序，可以參考我的這篇文章：

https://juejin.cn/post/6856654877142188046#heading-2

Glide中的應用

Glide 相信大應該非常熟悉了，我們都知道Glide生命周期的控制（如果不了解，可以看下Glide相關文章的分析，跟LiveData 是同一個原理）是通過添加一個空的Fragment到Activity 或者Fragment中，然后通過FragmentMannager管理Fragment的生命周期，從而達到生命周期的控制。下面是節選了Glide一段添加Fragment的代碼：

private?RequestManagerFragment?getRequestManagerFragment(@NonNull?final?android.app.FragmentManager?fm,@Nullable?android.app.Fragment?parentHint,boolean?isParentVisible)?{//1.通過FragmentManager獲取?RequestManagerFragment，如果已添加到FragmentManager則返回實例，否則為空RequestManagerFragment?current?=?(RequestManagerFragment)?fm.findFragmentByTag(FRAGMENT_TAG);if?(current?==?null)?{//2.如果fm里面沒有則從map緩存里取current?=?pendingRequestManagerFragments.get(fm);if?(current?==?null)?{//3.第1和2步都沒有，說明確實沒創建，則走創建的流程current?=?new?RequestManagerFragment();current.setParentFragmentHint(parentHint);if?(isParentVisible)?{current.getGlideLifecycle().onStart();}//4.將新創建的fragment?保存到map容器pendingRequestManagerFragments.put(fm,?current);//5.發送添加fragment事務事件fm.beginTransaction().add(current,?FRAGMENT_TAG).commitAllowingStateLoss();//6.發送remove?本地緩存事件handler.obtainMessage(ID_REMOVE_FRAGMENT_MANAGER,?fm).sendToTarget();}}return?current; }//跟上面那個方法唯一的區別是?這個是Fragment?的FragmentManager，上面的是Acitivity?的FragmentManager private?SupportRequestManagerFragment?getSupportRequestManagerFragment(@NonNull?final?FragmentManager?fm,?@Nullable?Fragment?parentHint,?boolean?isParentVisible)?{SupportRequestManagerFragment?current?=(SupportRequestManagerFragment)?fm.findFragmentByTag(FRAGMENT_TAG);if?(current?==?null)?{current?=?pendingSupportRequestManagerFragments.get(fm);if?(current?==?null)?{current?=?new?SupportRequestManagerFragment();current.setParentFragmentHint(parentHint);if?(isParentVisible)?{current.getGlideLifecycle().onStart();}pendingSupportRequestManagerFragments.put(fm,?current);fm.beginTransaction().add(current,?FRAGMENT_TAG).commitAllowingStateLoss();handler.obtainMessage(ID_REMOVE_SUPPORT_FRAGMENT_MANAGER,?fm).sendToTarget();}}return?current; }@Override public?boolean?handleMessage(Message?message)?{boolean?handled?=?true;Object?removed?=?null;Object?key?=?null;switch?(message.what)?{case?ID_REMOVE_FRAGMENT_MANAGER://7.移除緩存android.app.FragmentManager?fm?=?(android.app.FragmentManager)?message.obj;key?=?fm;removed?=?pendingRequestManagerFragments.remove(fm);break;//省略代碼...}//省略代碼...return?handled; }

看了上面的代碼，大家可能會有疑惑。

• Fragment添加到FragmentManager為什么還要保存到map容器里（第4步）？

• 判斷Fragment是否已添加為啥還要從map容器判斷（第2步），FragmentManager 去find 不就可以做到了嗎？

其實答案很簡單，學了Handler原理之后我們知道：就是在第5步執行完之后并沒有將Fragment添加到FragmentManager（事件排隊中），而是發送添加Fragment的事件。接下來我們看代碼：

//FragmentManagerImpl.java void?scheduleCommit()?{synchronized?(this)?{boolean?postponeReady?=mPostponedTransactions?!=?null?&&?!mPostponedTransactions.isEmpty();boolean?pendingReady?=?mPendingActions?!=?null?&&?mPendingActions.size()?==?1;if?(postponeReady?||?pendingReady)?{mHost.getHandler().removeCallbacks(mExecCommit);mHost.getHandler().post(mExecCommit);updateOnBackPressedCallbackEnabled();}} }

添加Fragment 最終會走到FragmentManagerImpl的 scheduleCommit方法，我們可以看到他是通過Handler 發送事件。

這也就解釋了為什么第5步執行完之后Fragment為什么沒有立即添加到FragmentManager，所以需要Map緩存Fragment來標記是否有Fragment添加。再接著有了第6步發送移除Map緩存的消息，因為Handler處理消息是有序的。

/? ?總結? ?/

本文其實對源碼的分析并沒有非常仔細，卻從整個系統各個方面的運用進行的不同的擴展，以及一些第三方框架中的使用，希望本文對你有幫助，喜歡的點個贊吧~

推薦閱讀：

我又開發了一個非常好用的開源庫

我的新書，《第一行代碼?第3版》已出版！

Android上的網絡抓包原來是這樣工作的

歡迎關注我的公眾號

學習技術或投稿

長按上圖，識別圖中二維碼即可關注

總結

以上是生活随笔為你收集整理的Handler的内功心法，值得拥有！的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。