執行緒與更新UI,消除偏見,細談原理
前言
相信不少讀者都閱讀過相類似的文章了,但是我還是想完整的把這之間的關係梳理清楚,細節聊好,希望你也能從中學到一些。
進入正題,大家應該都聽過這樣一句話——“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更新時候的執行緒是不是同一個執行緒,如果不是就會報錯。
參考
https://www.jianshu.com/p/1cdd5d1b9f3d
https://www.cnblogs.com/fangg/p/12917235.html
拜拜
有一起學習的小夥伴可以關注下❤️我的公眾號——碼上積木,每天剖析一個知識點,我們一起積累知識。