線程與更新UI,消除偏見,細談原理
- 2020 年 11 月 18 日
- 筆記
前言
相信不少讀者都閱讀過相類似的文章了,但是我還是想完整的把這之間的關係梳理清楚,細節聊好,希望你也能從中學到一些。
進入正題,大家應該都聽過這樣一句話——「UI更新要在主線程,子線程更新UI會崩潰」。久而久之就感覺這是個真理,甚至被認為是「官方結論」。
但是如果問你,官方什麼時候在哪裡說過這句話,你會不會有點懵。而且就算是官方說的,也就不一定對的是吧,眾所周知,Google
官方文檔一直都有點說的不清不楚,需要我們進行大量實踐得出實際的結論。
就好比之前的Android11
更新文檔,我也是看了好久,通過一個個實踐才寫出了適配指南,然後就發現其中一個比較明顯的BUG
,Google
官方有說過這樣一句:
下面是首先需要關注的行為變更 (無論您應用的 targetSdkVersion 是多少):
外部存儲訪問權限 – 應用無法再訪問外部存儲空間中其他應用的文件。
其實經過實踐會發現,外部存儲訪問權限還是會和targetSdkVersion
有關,具體可以看這篇Android11適配指南。
廢話有點多了,今天還是通過實踐案例,看看這個關於線程和UI更新的 「官方結論」 正確嗎?
案例一,子線程更新button文字
1)onCreate
方法中更新了按鈕顯示文字,修改Button
的寬度為固定或者wrap_content
,都不崩潰。
<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
。
<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.。
(主線程更新UI也會崩潰!你沒有看錯!)
重新運行,在子線程中顯示並消失後,點擊按鈕,不崩潰。
換個手機——三星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更新時候的線程是不是同一個線程,如果不是就會報錯。
參考
//www.jianshu.com/p/1cdd5d1b9f3d
//www.cnblogs.com/fangg/p/12917235.html
拜拜
有一起學習的小夥伴可以關注下❤️我的公眾號——碼上積木,每天剖析一個知識點,我們一起積累知識。