Android窗口机制：六、一定要在主线程才可以更新UI吗？为什么？（源码版本SDK31）

116 阅读 0 评论 77 点赞

我是靠谱客的博主阳光大米，最近开发中收集的这篇文章主要介绍Android窗口机制：六、一定要在主线程才可以更新UI吗？为什么？（源码版本SDK31），觉得挺不错的，现在分享给大家，希望可以做个参考。

概述

Android 窗口机制 SDK31源码分析总目录

初识
DecorView与SubDecor的创建加载
Window与Window Manager的创建加载
ViewRootImpl的创建以及视图真正加载
ViewRootImpl的事件分发
一定要在主线程才可以更新UI吗？为什么？
Activity的Token和Dialog的关系
Toast机制 - 封装可以在任何线程调用的toast
总结

通过前几章节的介绍，大家应该大致都了解Android整体的窗口机制了吧。

那么问一个问题，UI一定要在主线程才可以更新吗？回答这个问题之前，先看一个简单的例子

示例演示

代码如下所示：代码很简单，在onCreate中启动子线程（子线程的名字被设置为Myself Thread）更新TextView的text属性，在onResume函数中将当前的text值打印在控制台。

	lateinit var binding: ActivityThreadTestBinding
@SuppressLint("SetTextI18n")
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
binding = ActivityThreadTestBinding.inflate(layoutInflater)
setContentView(binding.root)
//子线程更新text
Thread {
binding.tv1.text = "The name of the current thread is ${Thread.currentThread().name}."
}.apply {
name = "Myself Thread"
}.start()
}
override fun onResume() {
super.onResume()
//打印出当前控件所设置的text
binding.tv1.text.toString().toLogI()
}

大家可以猜测一下，上述代码可以正常运行吗❓

答案是：可以正常运行，并且控制台打印出来了 The name of the current thread is Myself Thread.

啊????？这是为什么呢？子线程竟然更新UI竟然没有抛异常而且成功了????‍♀️？不着急，我们慢慢分析。

为什么子线程可以更新UI呢？下面我们分析一下。

我们知道视图更新会调用View的requestLayout或者invalidate方法，而这两个方法均会调用ViewRootImpl的requestLayout方法，进而调用到ViewRootImpl的scheduleTraversals，好的我们回顾一下ViewRootImpl的requestLayout方法。

ViewRootImpl
public void requestLayout() {
if (!mHandlingLayoutInLayoutRequest) {
//判断当前是否是主线程即mThread,如果不是，则抛异常。就是在子线程更新UI没使用handler的话就会抛出的异常
checkThread();
//设置mLayoutRequested为true。
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的checkThread的方法里面，会进行判断，如果不是主线程的话，就抛出异常（就是我们常见的不能在子线程更新UI的异常）。

那么聪明的同学们可能就要发问了，那为什么上面的代码没有抛异常还运行成功了？

我们再回忆一下前面的章节内容，ViewRootImpl是在什么时候被实例化的呢？

流程大致如下：ActivityThread.handleResumeActivity -> Activity.onResume -> WindowManagerGlobal.addView -> new ViewRootImpl -> ViewRootImpl.setView -> View.assignParent(this)

就是在系统准备显示界面的时候，直观一点的话，就是在Activity的onResume方法被调用之后，会新创建一个ViewRootImpl，之后会调用其setView方法，里面调用到DecorView的assignParent方法，将其分配给View的mParent变量。

所以综上所述：在onCreate方法里面调用设置UI的时候，并没有进行实际的绘制流程，因为ViewRootImpl还没有被设置，那么猜测我们设置的值，应该是被View存在内存了，等到进行真正执行绘制流程的时候，才被渲染出来。

下面进行上述猜测验证，简单分析一下TextView.setText的流程。

TextView
private void setText(CharSequence text, BufferType type, boolean notifyBefore, int oldlen) {
...
//将value设置到内存
setTextInternal(text)
...
//具体绘制调用
if (mLayout != null) {
checkForRelayout();
}
...
}
private void setTextInternal(@Nullable CharSequence text) {
//内存中储存text值
mText = text;
mSpannable = (text instanceof Spannable) ? (Spannable) text : null;
mPrecomputed = (text instanceof PrecomputedText) ? (PrecomputedText) text : null;
}
private void checkForRelayout() {
...
//则机会调用view的这两个方法
requestLayout();
invalidate();
}
//View的requestLayout
public void requestLayout() {
...
//mParent指的是ViewRootImpl，如果是在onCreate的时候异步线程更新UI的话，此时mParent为null，所以不会具体的进行绘制，所以就不会抛异常
if (mParent != null && !mParent.isLayoutRequested()) {
mParent.requestLayout();
}
...
}

显而易见，在onCreate中更新UI时，只是把值保存到了内存中，当视图真正渲染时，才进行正常的绘制流程。

比如如果我们把异步线程setText的操作，放到一个按钮里面，通过点击实现，那么一定会抛出异常（因为此时界面已经显示出来了）。如下所示：

binding.bt1.setOnClickListener {
Thread {
binding.tv1.text = "The name of the current thread is ${Thread.currentThread().name}."
}.apply {
name = "Myself Thread2"
}.start()
}
点击，控制台打印的异常信息如下：
android.view.ViewRootImpl$CalledFromWrongThreadException: Only the original thread that created a view hierarchy can touch its views.
at android.view.ViewRootImpl.checkThread(ViewRootImpl.java:9328)
...
at com.pumpkin.automatic_execution.View.ThreadTestActivity.onCreate$lambda-2$lambda-0(ThreadTestActivity.kt:24)