前言
相信很多讀者都閱讀過相相似的文章了，可是我仍是想完整的把這之間的關係梳理清楚，細節聊好，但願你也能從中學到一些。html
進入正題，你們應該都聽過這樣一句話——「UI更新要在主線程，子線程更新UI會崩潰」。長此以往就感受這是個真理，甚至被認爲是「官方結論」。java
可是若是問你，官方何時在哪裏說過這句話，你會不會有點懵。並且就算是官方說的，也就不必定對的是吧，衆所周知，Google官方文檔一直都有點說的不清不楚，須要咱們進行大量實踐得出實際的結論。android
就比如以前的Android11更新文檔，我也是看了很久，經過一個個實踐才寫出了適配指南，而後就發現其中一個比較明顯的BUG，Google官方有說過這樣一句：web
下面是首先須要關注的行爲變動 (不管您應用的 targetSdkVersion 是多少): 外部存儲訪問權限 - 應用沒法再訪問外部存儲空間中其餘應用的文件。面試
其實通過實踐會發現，外部存儲訪問權限仍是會和targetSdkVersion有關，具體能夠看這篇Android11適配指南。安全
廢話有點多了，今天仍是經過實踐案例，看看這個關於線程和UI更新的 「官方結論」 正確嗎？微信
案例一，子線程更新button文字
1）onCreate方法中更新了按鈕顯示文字，修改Button的寬度爲固定或者wrap_content，都不崩潰。app
<Button
android:id="@+id/btn_ui"
android:layout_width="100dp"
android:layout_height="70dp"
android:layout_centerInParent="true"
android:text="我是一個按鈕"
/>
//或者
<Button
android:id="@+id/btn_ui"
android:layout_width="wrap_content"
android:layout_height="70dp"
android:layout_centerInParent="true"
android:text="我是一個按鈕"
/>
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
setContentView(R.layout.activity_ui)
thread {
btn_ui.text="年輕人要講武德"
}
}
2）onCreate方法中更新了按鈕顯示文字，加了延時。編輯器
Button的寬度爲固定不崩潰。Button的寬度爲wrap_content，崩潰報錯——Only the original thread that created a view hierarchy can touch its views。ide
<Button
android:id="@+id/btn_ui"
android:layout_width="100dp"
android:layout_height="70dp"
android:layout_centerInParent="true"
android:text="我是一個按鈕"
/>
//或者
<Button
android:id="@+id/btn_ui"
android:layout_width="wrap_content"
android:layout_height="70dp"
android:layout_centerInParent="true"
android:text="我是一個按鈕"
/>
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
setContentView(R.layout.activity_ui)
thread {
Thread.sleep(3000)
btn_ui.text="年輕人要講武德"
}
}
案例一分析
有點懵的感受，不慌，來看看崩潰信息。
崩潰是在按鈕寬度爲wrap_content，也就是根據內容設定寬度，而後3秒以後去更新按鈕文字，發生了崩潰。相比之下，有兩個崩潰影響點須要注意下：
-
寬度wrap_content。若是設置爲固定值，是不會崩潰的，見案例2，因此是否是跟佈局改變的邏輯有關呢？ -
延時3秒。若是不延時的話，即便是wrap_content也不會崩潰，見案例1，因此是否是跟某些類的加載進度有關呢？
帶着這些疑問去源碼中找找答案。先看看崩潰日誌：
android.view.ViewRootImpl$CalledFromWrongThreadException: Only the original thread that created a view hierarchy can touch its views.
at android.view.ViewRootImpl.checkThread(ViewRootImpl.java:9219)
at android.view.ViewRootImpl.requestLayout(ViewRootImpl.java:1600)
at android.view.View.requestLayout(View.java:24884)
能夠看到是ViewRootImpl的requestLayout中檢查線程的時候報錯了，那咱們就看看這個方法：
@Override
public void requestLayout() {
if (!mHandlingLayoutInLayoutRequest) {
checkThread();
mLayoutRequested = true;
scheduleTraversals();
}
}
void checkThread() {
if (mThread != Thread.currentThread()) {
throw new CalledFromWrongThreadException(
"Only the original thread that created a view hierarchy can touch its views.");
}
}
在解開謎底以前，咱們先了解下ViewRootImpl。
ViewRootImpl
Activity從建立到咱們看到界面，實際上是經歷了兩個過程：加載佈局和繪製。
-
加載佈局
加載佈局其實就是咱們經常使用的setContentView(int layoutResID)方法，這個方法主要作的就是新建了一個DecorView，而後根據activity設置的主題（theme）或者特徵（Feature）加載不一樣的根佈局文件，最後再加載layoutResID資源文件。爲了方便你們理解，畫了一張圖：
這裏的最後一步是調用了LayoutInflater的inflate()方法，這個方法只作了一件事，就是解析xml文件，而後根據節點生成了view對象。最後造成了一個完整的DOM結構，返回最頂層的根佈局View。(DOM是一種文檔對象模型，他的層次結構是除了頂級元素，全部元素都被包括到另外的元素節點中，有點像家譜樹結構，很典型的就是html代碼解析)
到這裏，一個有完整view結構的DecorView就建立出來了，可是它尚未被繪製，也沒有被顯示到手機界面上。
-
繪製
繪製的流程發生在handleResumeActivity中，熟悉app啓動流程的朋友應該知道，handleResumeActivity方法是用來觸發onResume方法的，這裏也完成了DecorView的繪製。再來一張圖：
-
總結
由此咱們能夠得出一些結論：
1）setContentView用來新建DecorView並加載佈局的資源文件。
2）onResume方法以後，會新建一個ViewRootImpl，做爲DecorView的parent對DecorView進行測量，佈局和繪製等操做。
3）PhoneWindow做爲Window的惟一子類，存儲了DecorView變量，並對其進行管理，屬於Activity和View交互的中間層。
分析崩潰
好了。再回來看看崩潰的緣由：
void checkThread() {
if (mThread != Thread.currentThread()) {
throw new CalledFromWrongThreadException(
"Only the original thread that created a view hierarchy can touch its views.");
}
}
能夠看到是由於當前線程currentThread不是mThread的時候，就會崩潰，報的錯誤是 「只有建立視圖層次結構的原始線程才能觸摸它的視圖」 ，看到這裏是否是猜到一些了，這個mThread難道就是「建立視圖的原始線程」？
經過查找，其實這個mThread是在ViewRootImpl被建立的時候賦值的：
public ViewRootImpl(Context context, Display display) {
mThread = Thread.currentThread();
}
而經過上方分析Activity加載佈局過程得知，ViewRootImpl實例化發生在onResume以後，用來繪製DecorView到window上。
因此咱們就能夠得知崩潰的真正緣由，就是當前線程不是ViewRootImpl建立時候的線程就會崩潰。翻譯的仍是比較準確的，只有建立視圖的原始線程才能修改這個視圖，聽起來也蠻有道理的，我創造了你纔有權利改變你，有那味了。
而後再看看前面的案例：
-
案例一，在
onCreate中修改Button，這時候只是在修改DecorView，都沒建立ViewRootImpl，也就沒走到因此checkThread方法，固然不會崩潰了。ViewRootImpl的建立是在onResume以後。 -
案例二，延時3秒以後，界面也繪製完成了，建立
ViewRootImpl顯然是在主線程完成的，因此mThread爲主線程，而改變Button的線程爲子線程，因此setText方法會觸發requestLayout方法從新繪製，最終致使崩潰。
可是，Button的寬度設置爲固定值咋又不崩潰了？難道就不會執行checkThread方法了？奇怪。
找找setText的源碼能夠發現，有一個方法是負責檢查是否須要新的佈局——checkForRelayout()
private void checkForRelayout() {
// If we have a fixed width, we can just swap in a new text layout
// if the text height stays the same or if the view height is fixed.
if ((mLayoutParams.width != LayoutParams.WRAP_CONTENT
|| (mMaxWidthMode == mMinWidthMode && mMaxWidth == mMinWidth))
&& (mHint == null || mHintLayout != null)
&& (mRight - mLeft - getCompoundPaddingLeft() - getCompoundPaddingRight() > 0)) {
if (mEllipsize != TextUtils.TruncateAt.MARQUEE) {
// In a fixed-height view, so use our new text layout.
if (mLayoutParams.height != LayoutParams.WRAP_CONTENT
&& mLayoutParams.height != LayoutParams.MATCH_PARENT) {
autoSizeText();
invalidate();
return;
}
//...
}
// We lose: the height has changed and we have a dynamic height.
// Request a new view layout using our new text layout.
requestLayout();
invalidate();
} else {
// Dynamic width, so we have no choice but to request a new
// view layout with a new text layout.
nullLayouts();
requestLayout();
invalidate();
}
}
能夠看到，若是佈局大小沒有改變的話，咱們是不會去執行requestLayout方法從新進行佈局繪製的，只會調用autoSizeText方法計算文字大小，invalidate繪製文字自己，因此當咱們寬高設置爲固定值，setText()方法就不會執行到requestLayout()方法了，天然也就執行不到checkThread()方法了。
反思
解決了問題，還須要反思下，爲何須要checkThread檢查線程呢？
-
檢查線程，其實就是檢查更新UI操做的當前線程是否是當初建立UI的那個線程，這樣就保證了 線程安全，由於UI控件自己不是線程安全的，可是加鎖又顯得過重，會下降View加載效率，畢竟是跟交互相關的。因此就直接經過判斷線程這一邏輯來造成一個單線程模型，保證View操做的線程安全。
案例二，子線程和主線程分別showToast
1）onCreate方法中彈出toast，崩潰——Can't toast on a thread that has not called Looper.prepare()
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
setContentView(R.layout.activity_ui)
thread {
showToast("我去年買了個表")
}
}
2）onCreate方法中彈出toast，增長Looper.prepare()，Looper.loop()方法。不崩潰。
加上延時3秒，不崩潰。
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
setContentView(R.layout.activity_ui)
thread {
//Thread.sleep(3000)
Looper.prepare()
showToast("我去年買了個表")
Looper.loop()
}
}
3）使用同一個Toast實例，在子線程中的Toast沒消失以前點擊按鈕，在主線程中修改Toast文字並顯示，則程序崩潰——Only the original thread that created a view hierarchy can touch its views.。
從新運行，在子線程中顯示並消失後，點擊按鈕，不崩潰。
換個手機——三星s9，從新運行，在子線程中的Toast沒消失以前點擊按鈕，不崩潰。
lateinit var mToast: Toast
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
setContentView(R.layout.activity_ui)
thread {
Looper.prepare()
mToast=Toast.makeText(this@UIMainActivity,"我去年買了個表",Toast.LENGTH_LONG)
mToast.show()
Looper.loop()
}
btn_ui.setOnClickListener {
mToast.setText("我今年買了個表")
mToast.show()
}
}
案例二分析
在解開謎底以前，咱們先了解下Toast。
Toast原理
Toast.makeText(this,msg,Toast.LENGTH_SHORT).show()
簡單又經常使用的一句代碼，仍是經過流程圖的方式看看它是怎麼建立並展現的。
和DecorView加載繪製流程一模一樣，首先加載了佈局文件，建立了View。而後經過addView方法，再次新建一個ViewRootImpl實例，做爲parent，進行測量佈局和繪製。
崩潰分析
1）首先，說下第一次崩潰——Can't toast on a thread that has not called Looper.prepare()，也就是在建立Toast的線程必需要有Looper在運行。
根據源碼咱們也得知Toast的顯示和隱藏都是經過Handler傳遞消息的，因此必需要有Handler使用環境，也就是綁定Looper對象，而且經過loop方法開始循環處理消息。
2）第二次崩潰——Only the original thread that created a view hierarchy can touch its views。
這裏的崩潰和以前更新Button同樣的報錯，因此咱們有理由懷疑也是同樣的緣由，在不一樣的線程調用了ViewRootImpl的requestLayout方法。
咱們看到點擊按鈕的時候，調用了mToast.setText()方法，咦，這不就跟案例一如出一轍了嗎。
setText方法中調用了TextView的setText()方法，而後因爲Toast中的TextView寬高都是wrap_content的，因此會觸發requestLayout方法，最後會調用到最上層View也就是ViewRootImpl的requestLayout方法。
因此崩潰的緣由就是由於Toast在第一次在子線程中show的時候，新建了一個ViewRootImpl實例，綁定了當前線程也就是子線程到mThread變量。而後同一個Toast，在主線程調用setText方法，最終會調用到ViewRootImpl的requestLayout方法，引發線程檢查，當前線程也就是主線程並非當初那個建立ViewRootImpl實例的線程，因此致使崩潰。
3）那爲何等Toast消失以後，點擊按鈕又不崩潰了呢？
緣由就在Toast的hide方法中，最終會調用到View的assignParent方法，將Toast的mParent設置爲null，也就是ViewRootImpl設置爲null了。因此調用setText方法的時候也就執行不到requestLayout方法了，也就不會到checkThread方法檢查線程了。貼下代碼：
public void handleHide() {
if (mView != null) {
if (mView.getParent() != null) {
mWM.removeViewImmediate(mView);
}
mView = null;
}
}
removeViewImmediate--->removeViewLocked
private void removeViewLocked(int index, boolean immediate) {
ViewRootImpl root = mRoots.get(index);
View view = root.getView();
//...
if (view != null) {
view.assignParent(null);
if (deferred) {
mDyingViews.add(view);
}
}
}
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");
}
}
4）可是可是，爲啥換個手機又不崩潰了呢？
這是我偶然發現的，在個人三星S9手機上，運行時不會崩潰的，並且界面給個人反饋並非修改當前頁面上Toast上的文字，而是像新建了一個Toast展現，即時代碼中寫的是setText方法。
因此我猜想在部分手機上，應該是改變了Toast的設置，當調用setText方法的時候，就會立刻結束當前的Toast展現，調用hide方法。而後再進行Toast文字修改並展現，也就是剛纔第三點的作法。
固然這只是個人猜想，有研究過手機源碼的大神也能夠補充下。
總結
任何線程均可以更新UI，也都有更新UI致使崩潰的可能。
其中的關鍵就是view被繪製到界面時候的線程（也就是最頂層ViewRootImpl被建立時候的線程）和進行UI更新時候的線程是否是同一個線程，若是不是就會報錯。
參考
https://www.jianshu.com/p/1cdd5d1b9f3d
https://www.cnblogs.com/fangg/p/12917235.html
拜拜
有一塊兒學習的小夥伴能夠關注下個人公衆號——碼上積木❤️❤️ 每日三問知識點/面試題，聚沙成塔。
本文分享自微信公衆號 - 碼上積木（Lzjimu）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。