前言

相信不少讀者都閱讀過(guò)相類似的文章了，但是我還是想完整的把這之間的關(guān)系梳理清楚，細(xì)節(jié)聊好，希望你也能從中學(xué)到一些。

進(jìn)入正題，大家應(yīng)該都聽(tīng)過(guò)這樣一句話——“UI更新要在主線程，子線程更新UI會(huì)崩潰”。久而久之就感覺(jué)這是個(gè)真理，甚至被認(rèn)為是“官方結(jié)論”。

但是如果問(wèn)你，官方什么時(shí)候在哪里說(shuō)過(guò)這句話，你會(huì)不會(huì)有點(diǎn)懵。而且就算是官方說(shuō)的，也就不一定對(duì)的是吧，眾所周知，Google官方文檔一直都有點(diǎn)說(shuō)的不清不楚，需要我們進(jìn)行大量實(shí)踐得出實(shí)際的結(jié)論。

就好比之前的Android11更新文檔，我也是看了好久，通過(guò)一個(gè)個(gè)實(shí)踐才寫(xiě)出了適配指南，然后就發(fā)現(xiàn)其中一個(gè)比較明顯的BUG，Google官方有說(shuō)過(guò)這樣一句：

下面是首先需要關(guān)注的行為變更 (無(wú)論您應(yīng)用的 targetSdkVersion 是多少):? 外部存儲(chǔ)訪問(wèn)權(quán)限 ?- 應(yīng)用無(wú)法再訪問(wèn)外部存儲(chǔ)空間中其他應(yīng)用的文件。

其實(shí)經(jīng)過(guò)實(shí)踐會(huì)發(fā)現(xiàn)，外部存儲(chǔ)訪問(wèn)權(quán)限還是會(huì)和targetSdkVersion有關(guān)，具體可以看這篇Android11適配指南。

廢話有點(diǎn)多了，今天還是通過(guò)實(shí)踐案例，看看這個(gè)關(guān)于線程和UI更新的 “官方結(jié)論” 正確嗎？

案例一，子線程更新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="我是一個(gè)按鈕"
????????/>

????????//或者

????????????android:id="@+id/btn_ui"
????????android:layout_width="wrap_content"
????????android:layout_height="70dp"
????????android:layout_centerInParent="true"
????????android:text="我是一個(gè)按鈕"
????????/>????????


????override?fun?onCreate(savedInstanceState:?Bundle?)?{
????????super.onCreate(savedInstanceState)
????????setContentView(R.layout.activity_ui)

????????thread?{
????????????btn_ui.text="年輕人要講武德"
????????}
????}

2)onCreate方法中更新了按鈕顯示文字，加了延時(shí)。

Button的寬度為固定不崩潰。Button的寬度為wrap_content，崩潰報(bào)錯(cuò)——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="我是一個(gè)按鈕"
????????/>

????????//或者

????????????android:id="@+id/btn_ui"
????????android:layout_width="wrap_content"
????????android:layout_height="70dp"
????????android:layout_centerInParent="true"
????????android:text="我是一個(gè)按鈕"
????????/>???
????????

????override?fun?onCreate(savedInstanceState:?Bundle?)?{
????????super.onCreate(savedInstanceState)
????????setContentView(R.layout.activity_ui)

????????thread?{
?????????Thread.sleep(3000)
????????????btn_ui.text="年輕人要講武德"
????????}
????}

案例一分析

有點(diǎn)懵的感覺(jué)，不慌，來(lái)看看崩潰信息。

崩潰是在按鈕寬度為wrap_content，也就是根據(jù)內(nèi)容設(shè)定寬度，然后3秒之后去更新按鈕文字，發(fā)生了崩潰。相比之下，有兩個(gè)崩潰影響點(diǎn)需要注意下：

• 寬度wrap_content。如果設(shè)置為固定值，是不會(huì)崩潰的，見(jiàn)案例2，所以是不是跟布局改變的邏輯有關(guān)呢？
• 延時(shí)3秒。如果不延時(shí)的話，即使是wrap_content也不會(huì)崩潰，見(jiàn)案例1，所以是不是跟某些類的加載進(jìn)度有關(guān)呢？

帶著這些疑問(wèn)去源碼中找找答案。先看看崩潰日志：

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中檢查線程的時(shí)候報(bào)錯(cuò)了，那我們就看看這個(gè)方法：

????@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.");
????????}
????}????

在解開(kāi)謎底之前，我們先了解下ViewRootImpl。

ViewRootImpl

Activity從創(chuàng)建到我們看到界面，其實(shí)是經(jīng)歷了兩個(gè)過(guò)程：加載布局和繪制。

• 加載布局

加載布局其實(shí)就是我們常用的setContentView(int layoutResID)方法，這個(gè)方法主要做的就是新建了一個(gè)DecorView，然后根據(jù)activity設(shè)置的主題(theme)或者特征(Feature)加載不同的根布局文件，最后再加載layoutResID資源文件。為了方便大家理解，畫(huà)了一張圖：

加載布局流程

這里的最后一步是調(diào)用了LayoutInflater的inflate()方法，這個(gè)方法只做了一件事，就是解析xml文件，然后根據(jù)節(jié)點(diǎn)生成了view對(duì)象。最后形成了一個(gè)完整的DOM結(jié)構(gòu)，返回最頂層的根布局View。(DOM是一種文檔對(duì)象模型，他的層次結(jié)構(gòu)是除了頂級(jí)元素，所有元素都被包括到另外的元素節(jié)點(diǎn)中，有點(diǎn)像家譜樹(shù)結(jié)構(gòu)，很典型的就是html代碼解析)

到這里，一個(gè)有完整view結(jié)構(gòu)的DecorView就創(chuàng)建出來(lái)了，但是它還沒(méi)有被繪制，也沒(méi)有被顯示到手機(jī)界面上。

• 繪制

繪制的流程發(fā)生在handleResumeActivity中，熟悉app啟動(dòng)流程的朋友應(yīng)該知道，handleResumeActivity方法是用來(lái)觸發(fā)onResume方法的，這里也完成了DecorView的繪制。再來(lái)一張圖：

繪制流程

• 總結(jié)

由此我們可以得出一些結(jié)論：
1)setContentView用來(lái)新建DecorView并加載布局的資源文件。
2)onResume方法之后，會(huì)新建一個(gè)ViewRootImpl，作為DecorView的parent對(duì)DecorView進(jìn)行測(cè)量，布局和繪制等操作。
3)PhoneWindow作為Window的唯一子類，存儲(chǔ)了DecorView變量，并對(duì)其進(jìn)行管理，屬于Activity和View交互的中間層。

分析崩潰

好了。再回來(lái)看看崩潰的原因：

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

可以看到是因?yàn)楫?dāng)前線程currentThread不是mThread的時(shí)候，就會(huì)崩潰，報(bào)的錯(cuò)誤是 “只有創(chuàng)建視圖層次結(jié)構(gòu)的原始線程才能觸摸它的視圖” ，看到這里是不是猜到一些了，這個(gè)mThread難道就是“創(chuàng)建視圖的原始線程”？

通過(guò)查找，其實(shí)這個(gè)mThread是在ViewRootImpl被創(chuàng)建的時(shí)候賦值的：

public?ViewRootImpl(Context?context,?Display?display)?{
????mThread?=?Thread.currentThread();
}

而通過(guò)上方分析Activity加載布局過(guò)程得知，ViewRootImpl實(shí)例化發(fā)生在onResume之后，用來(lái)繪制DecorView到window上。

所以我們就可以得知崩潰的真正原因，就是當(dāng)前線程不是ViewRootImpl創(chuàng)建時(shí)候的線程就會(huì)崩潰。翻譯的還是比較準(zhǔn)確的，只有創(chuàng)建視圖的原始線程才能修改這個(gè)視圖，聽(tīng)起來(lái)也蠻有道理的，我創(chuàng)造了你才有權(quán)利改變你，有那味了。

然后再看看前面的案例：

• 案例一，在onCreate中修改Button，這時(shí)候只是在修改DecorView，都沒(méi)創(chuàng)建ViewRootImpl，也就沒(méi)走到所以checkThread方法，當(dāng)然不會(huì)崩潰了。ViewRootImpl的創(chuàng)建是在onResume之后。

• 案例二，延時(shí)3秒之后，界面也繪制完成了，創(chuàng)建ViewRootImpl顯然是在主線程完成的，所以mThread為主線程，而改變Button的線程為子線程，所以setText方法會(huì)觸發(fā)requestLayout方法重新繪制，最終導(dǎo)致崩潰。

但是，Button的寬度設(shè)置為固定值咋又不崩潰了？難道就不會(huì)執(zhí)行checkThread方法了？奇怪。

找找setText的源碼可以發(fā)現(xiàn)，有一個(gè)方法是負(fù)責(zé)檢查是否需要新的布局——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();
????????}
????}

可以看到，如果布局大小沒(méi)有改變的話，我們是不會(huì)去執(zhí)行requestLayout方法重新進(jìn)行布局繪制的，只會(huì)調(diào)用autoSizeText方法計(jì)算文字大小，invalidate繪制文字本身，所以當(dāng)我們寬高設(shè)置為固定值，setText()方法就不會(huì)執(zhí)行到requestLayout()方法了，自然也就執(zhí)行不到checkThread()方法了。

反思

解決了問(wèn)題，還需要反思下，為什么需要checkThread檢查線程呢？

• 檢查線程，其實(shí)就是檢查更新UI操作的當(dāng)前線程是不是當(dāng)初創(chuàng)建UI的那個(gè)線程，這樣就保證了線程安全，因?yàn)閁I控件本身不是線程安全的，但是加鎖又顯得太重，會(huì)降低View加載效率，畢竟是跟交互相關(guān)的。所以就直接通過(guò)判斷線程這一邏輯來(lái)形成一個(gè)單線程模型，保證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("我去年買了個(gè)表")
????????}
????}

2)onCreate方法中彈出toast，增加Looper.prepare()，Looper.loop()方法。不崩潰。

加上延時(shí)3秒，不崩潰。

????override?fun?onCreate(savedInstanceState:?Bundle?)?{
????????super.onCreate(savedInstanceState)
????????setContentView(R.layout.activity_ui)

????????thread?{
????????????//Thread.sleep(3000)

????????????Looper.prepare()
????????????showToast("我去年買了個(gè)表")
????????????Looper.loop()
????????}
????}

3)使用同一個(gè)Toast實(shí)例，在子線程中的Toast沒(méi)消失之前點(diǎn)擊按鈕，在主線程中修改Toast文字并顯示，則程序崩潰——Only the original thread that created a view hierarchy can touch its views.。

重新運(yùn)行，在子線程中顯示并消失后，點(diǎn)擊按鈕，不崩潰。

換個(gè)手機(jī)——三星s9，重新運(yùn)行，在子線程中的Toast沒(méi)消失之前點(diǎn)擊按鈕，不崩潰。

????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,"我去年買了個(gè)表",Toast.LENGTH_LONG)
????????????mToast.show()
????????????Looper.loop()
????????}

????????btn_ui.setOnClickListener?{
????????????mToast.setText("我今年買了個(gè)表")
????????????mToast.show()
????????}
????}

案例二分析

在解開(kāi)謎底之前，我們先了解下Toast。

Toast原理

Toast.makeText(this,msg,Toast.LENGTH_SHORT).show()

簡(jiǎn)單又常用的一句代碼，還是通過(guò)流程圖的方式看看它是怎么創(chuàng)建并展示的。

Toast流程圖

和DecorView加載繪制流程如出一轍，首先加載了布局文件，創(chuàng)建了View。然后通過(guò)addView方法，再次新建一個(gè)ViewRootImpl實(shí)例，作為parent，進(jìn)行測(cè)量布局和繪制。

崩潰分析

1)首先，說(shuō)下第一次崩潰——Can't toast on a thread that has not called Looper.prepare()，也就是在創(chuàng)建Toast的線程必須要有Looper在運(yùn)行。

根據(jù)源碼我們也得知Toast的顯示和隱藏都是通過(guò)Handler傳遞消息的，所以必須要有Handler使用環(huán)境，也就是綁定Looper對(duì)象，并且通過(guò)loop方法開(kāi)始循環(huán)處理消息。

2)第二次崩潰——Only the original thread that created a view hierarchy can touch its views。

這里的崩潰和之前更新Button一樣的報(bào)錯(cuò)，所以我們有理由懷疑也是一樣的原因，在不同的線程調(diào)用了ViewRootImpl的requestLayout方法。

我們看到點(diǎn)擊按鈕的時(shí)候，調(diào)用了mToast.setText()方法，咦，這不就跟案例一一模一樣了嗎。

setText方法中調(diào)用了TextView的setText()方法，然后由于Toast中的TextView寬高都是wrap_content的，所以會(huì)觸發(fā)requestLayout方法，最后會(huì)調(diào)用到最上層View也就是ViewRootImpl的requestLayout方法。

所以崩潰的原因就是因?yàn)門(mén)oast在第一次在子線程中show的時(shí)候，新建了一個(gè)ViewRootImpl實(shí)例，綁定了當(dāng)前線程也就是子線程到mThread變量。然后同一個(gè)Toast，在主線程調(diào)用setText方法，最終會(huì)調(diào)用到ViewRootImpl的requestLayout方法，引起線程檢查，當(dāng)前線程也就是主線程并不是當(dāng)初那個(gè)創(chuàng)建ViewRootImpl實(shí)例的線程，所以導(dǎo)致崩潰。

3)那為什么等Toast消失之后，點(diǎn)擊按鈕又不崩潰了呢？

原因就在Toast的hide方法中，最終會(huì)調(diào)用到View的assignParent方法，將Toast的mParent設(shè)置為null，也就是ViewRootImpl設(shè)置為null了。所以調(diào)用setText方法的時(shí)候也就執(zhí)行不到requestLayout方法了，也就不會(huì)到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)但是但是，為啥換個(gè)手機(jī)又不崩潰了呢？

這是我偶然發(fā)現(xiàn)的，在我的三星S9手機(jī)上，運(yùn)行時(shí)不會(huì)崩潰的，而且界面給我的反饋并不是修改當(dāng)前頁(yè)面上Toast上的文字，而是像新建了一個(gè)Toast展示，即時(shí)代碼中寫(xiě)的是setText方法。

所以我猜測(cè)在部分手機(jī)上，應(yīng)該是改變了Toast的設(shè)置，當(dāng)調(diào)用setText方法的時(shí)候，就會(huì)馬上結(jié)束當(dāng)前的Toast展示，調(diào)用hide方法。然后再進(jìn)行Toast文字修改并展示，也就是剛才第三點(diǎn)的做法。

當(dāng)然這只是我的猜測(cè)，有研究過(guò)手機(jī)源碼的大神也可以補(bǔ)充下。

總結(jié)

任何線程都可以更新UI，也都有更新UI導(dǎo)致崩潰的可能。

其中的關(guān)鍵就是view被繪制到界面時(shí)候的線程(也就是最頂層ViewRootImpl被創(chuàng)建時(shí)候的線程)和進(jìn)行UI更新時(shí)候的線程是不是同一個(gè)線程，如果不是就會(huì)報(bào)錯(cuò)。

參考

https://www.jianshu.com/p/1cdd5d1b9f3d

https://www.cnblogs.com/fangg/p/12917235.html

拜拜

有一起學(xué)習(xí)的小伙伴可以關(guān)注下我的公眾號(hào)——碼上積木???? 每日三問(wèn)知識(shí)點(diǎn)/面試題，積少成多。

總結(jié)

以上是生活随笔為你收集整理的更新fielddata为true_线程与更新UI，细谈原理的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。