更新fielddata为true_线程与更新UI，细谈原理
前言
相信不少讀者都閱讀過相類似的文章了，但是我還是想完整的把這之間的關系梳理清楚，細節聊好，希望你也能從中學到一些。
進入正題，大家應該都聽過這樣一句話——“UI更新要在主線程，子線程更新UI會崩潰”。久而久之就感覺這是個真理，甚至被認為是“官方結論”。
但是如果問你，官方什么時候在哪里說過這句話，你會不會有點懵。而且就算是官方說的，也就不一定對的是吧，眾所周知，Google官方文檔一直都有點說的不清不楚，需要我們進行大量實踐得出實際的結論。
就好比之前的Android11更新文檔，我也是看了好久，通過一個個實踐才寫出了適配指南，然后就發現其中一個比較明顯的BUG，Google官方有說過這樣一句：
下面是首先需要關注的行為變更 (無論您應用的 targetSdkVersion 是多少):? 外部存儲訪問權限 ?- 應用無法再訪問外部存儲空間中其他應用的文件。
其實經過實踐會發現，外部存儲訪問權限還是會和targetSdkVersion有關，具體可以看這篇Android11適配指南。
廢話有點多了，今天還是通過實踐案例，看看這個關于線程和UI更新的 “官方結論” 正確嗎？
案例一，子線程更新button文字
1)onCreate方法中更新了按鈕顯示文字，修改Button的寬度為固定或者wrap_content，都不崩潰。
????????????android:id="@+id/btn_ui"
????????android:layout_width="100dp"
????????android:layout_height="70dp"
????????android:layout_centerInParent="true"
????????android:text="我是一個按鈕"
????????/>
????????//或者
????????????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。
????????????android:id="@+id/btn_ui"
????????android:layout_width="100dp"
????????android:layout_height="70dp"
????????android:layout_centerInParent="true"
????????android:text="我是一個按鈕"
????????/>
????????//或者
????????????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()簡單又常用的一句代碼，還是通過流程圖的方式看看它是怎么創建并展示的。
Toast流程圖和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--->removeViewLockedprivate?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
拜拜
有一起學習的小伙伴可以關注下我的公眾號——碼上積木???? 每日三問知識點/面試題，積少成多。
總結
以上是生活随笔為你收集整理的更新fielddata为true_线程与更新UI，细谈原理的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 李想：理想 L7 小订最大用户群来自特斯
- 下一篇： vbs打开软件光标停在第一个输入框_三维