## 前言 相信不少讀者都閱讀過相類似的文章了，但是我還是想完整的把這之間的關係梳理清楚，細節聊好，希望你也能從中學到一些。 進入正題，大家應該都聽過這樣一句話——**“UI更新要在主執行緒，子執行緒更新UI會崩潰”**。久而久之就感覺這是個真理，甚至被認為是“官方結論”。 但是如果問你，官方什麼時候在哪裡說過這句話，你會不會有點懵。而且就算是官方說的，也就不一定對的是吧，眾所周知，`Google`官方文件一直都有點說的不清不楚，需要我們進行大量實踐得出實際的結論。 就好比之前的`Android11`更新文件，我也是看了好久，通過一個個實踐才寫出了適配指南，然後就發現其中一個比較明顯的`BUG`，`Google`官方有說過這樣一句： >下面是首先需要關注的行為變更 (無論您應用的 targetSdkVersion 是多少):  >外部儲存訪問許可權  - 應用無法再訪問外部儲存空間中其他應用的檔案。 其實經過實踐會發現，外部儲存訪問許可權還是會和`targetSdkVersion`有關，具體可以看這篇[Android11適配指南](https://juejin.im/post/6860370635664261128)。 廢話有點多了，今天還是通過實踐案例，看看這個關於執行緒和UI更新的 **“官方結論”** 正確嗎？ ## 案例一，子執行緒更新button文字 1）`onCreate`方法中更新了按鈕顯示文字，修改`Button`的寬度為固定或者`wrap_content`，都不崩潰。 ```kotlin //或者 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`。 ```kotlin //或者 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，所以是不是跟某些類的載入進度有關呢？ 帶著這些疑問去原始碼中找找答案。先看看崩潰日誌： ```java 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`中檢查執行緒的時候報錯了，那我們就看看這個方法： ```java @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`互動的中間層。 ### 分析崩潰 好了。再回來看看崩潰的原因： ```java 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`被建立的時候賦值的： ```java 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()` ```java 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()` ```kotlin override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) setContentView(R.layout.activity_ui) thread { showToast("我去年買了個表") } } ``` 2）`onCreate`方法中彈出toast，增加`Looper.prepare()，Looper.loop()`方法。不崩潰。 加上延時3秒，不崩潰。 ```kotlin 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**.。 （主執行緒更新UI也會崩潰！你沒有看錯！） 重新執行，在子執行緒中顯示並消失後，點選按鈕，不崩潰。 換個手機——`三星s9`，重新執行，在子執行緒中的`Toast`沒消失之前點選按鈕，不崩潰。 ```kotlin 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原理 ```java 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`方法檢查執行緒了。貼下程式碼： ```java 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 ## 拜拜 > 有一起學習的小夥伴可以關注下❤️我的公眾號——碼上積木，每天剖析一個知識點，我們一起積累知識。  <