執行緒與更新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()

簡單又常用的一句代碼，還是通過流程圖的方式看看它是怎么創建并展示的，

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--->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

拜拜

有一起學習的小伙伴可以關注下??我的公眾號——碼上積木，每天剖析一個知識點，我們一起積累知識，

轉載請註明出處，本文鏈接：https://www.uj5u.com/yidong/223646.html

標籤：Android

上一篇：Flutter-Android-Embedder啟動流程

下一篇：nginx安裝lua+redis