Android中为什么只能在主线程更新UI？

---

前言

众所周知在Android中，子线程不具备更新UI的能力，也不允许在子线程更新UI，本文从源码的角度来探讨此问题，子线程更新UI会引发何种问题？是不是总是禁止在子线程操作UI界面？

一、子线程更新UI

@Override
protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        tv = findViewById(R.id.tv);
        new Thread(new Runnable() {
            @Override
            public void run() {
                tv.setText("测试是否报出异常");
            }
        }).start();
    }

运行结果并无异常，可以正常的在子线程中更新了TextView控件;假如让线程休眠1000ms,就会发生错误：

Only the original thread that created a view hierarchy can touch its views.

这句话的意思是只有创建视图层次结构的原始线程才能更新这个视图，也就是说只有主线程才有权力去更新UI，其他线程会直接抛异常的;

从at android.view.ViewRootImpl.checkThread(ViewRootImpl.java:7905)的异常路径可以看到抛出异常的位置最终在ViewRootIml的checkThread方法里，
ViewRootIml是View的根类，其控制着View的测量、绘制等操作，那么现在我们转到ViewRootImpl.java源码观察：

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

scheduleTraversals()里是对View进行绘制操作，而在绘制之前都会检查当前线程是否为主线程mThread，如果不是主线程，就抛出异常；这样做法就限制了开发者在子线程中更新UI的操作!
但是为什么最开始的在onCreate()里子线程对UI的操作没有报错呢，可以设想一下是因为ViewRootImp此时还没有创建，还未进行当前线程的判断；
现在，我们寻找ViewRootImp在何时创建?

---

二、ViewRootImp创建过程

从Activity启动过程中寻找源码,通过分析可以查看ActivityThread.java源码,并找到handleResumeActivity方法:

final void handleResumeActivity(IBinder token,boolean clearHide, boolean isForward, boolean reallyResume) {
        ···
        // TODO Push resumeArgs into the activity for consideration
        ActivityClientRecord r = performResumeActivity(token, clearHide);
        if (r.window == null && !a.mFinished && willBeVisible) {
                r.window = r.activity.getWindow();
                View decor = r.window.getDecorView();
                decor.setVisibility(View.INVISIBLE);
                ViewManager wm = a.getWindowManager();
                WindowManager.LayoutParams l = r.window.getAttributes();
                a.mDecor = decor;
                l.type = WindowManager.LayoutParams.TYPE_BASE_APPLICATION;
                l.softInputMode |= forwardBit;
                if (a.mVisibleFromClient) {
                    a.mWindowAdded = true;
                    wm.addView(decor, l);
                }

            } else if (!willBeVisible) {
                if (localLOGV) Slog.v(
                    TAG, "Launch " + r + " mStartedActivity set");
                r.hideForNow = true;
            }
        ···
}

内部调用了performResumeActivity方法：

public final ActivityClientRecord performResumeActivity(IBinder token,boolean clearHide) {
       if (r != null && !r.activity.mFinished) {
          r.activity.performResume();
       } catch (Exception e) {
          if (!mInstrumentation.onException(r.activity, e)){ throw new RuntimeException( "Unable to resume activity " + 
             r.intent.getComponent().toShortString() + ": " + e.toString(), e);
           }
         }
      }
 return r; 
} 

在内部调用了Activity的performResume方法，可以肯定应该是要回调生命周期的onResume方法了

final void performResume() {
        ···
        mCalled = false;
        // mResumed is set by the instrumentation
        mInstrumentation.callActivityOnResume(this);
        if (!mCalled) {
            throw new SuperNotCalledException(
                "Activity " + mComponent.toShortString() +
                " did not call through to super.onResume()");
        }
        ···
    }

然后又调用了Instrumentation的callActivityOnResume方法：

public void callActivityOnResume(Activity activity) {
        activity.mResumed = true;
        activity.onResume();
        
        if (mActivityMonitors != null) {
            synchronized (mSync) {
                final int N = mActivityMonitors.size();
                for (int i=0; i<N; i++) {
                    final ActivityMonitor am = mActivityMonitors.get(i);
                    am.match(activity, activity, activity.getIntent());
                }
            }
        }
    }

可以看到执行了 activity.onResume()方法，也就是回调了Activity生命周期的onResume方法;现在让我们回头看看handleResumeActivity方法，会执行这段代码：

···
r.activity.mVisibleFromServer = true;
                mNumVisibleActivities++;
                if (r.activity.mVisibleFromClient) {
                    r.activity.makeVisible();
                }

在内部调用了Activity的makeVisible方法：

void makeVisible() {
        if (!mWindowAdded) {
            ViewManager wm = getWindowManager();
            wm.addView(mDecor, getWindow().getAttributes());
            mWindowAdded = true;
        }
        mDecor.setVisibility(View.VISIBLE);
    }

内部调用了WindowManager的addView方法，而WindowManager方法的实现类是WindowManagerImp类，直接找WindowManagerImp的addView方法：

    @Override
    public void addView(@NonNull View view, @NonNull ViewGroup.LayoutParams params) {
        applyDefaultToken(params);
        mGlobal.addView(view, params, mDisplay, mParentWindow);
    }

然后又调用了WindowManagerGlobal的addView方法：

public void addView(View view, ViewGroup.LayoutParams params,Display display, Window parentWindow) {          
        ···
            root = new ViewRootImpl(view.getContext(), display);
            view.setLayoutParams(wparams);
            mViews.add(view);
            mRoots.add(root);
            mParams.add(wparams);
        }
        ···
    }

在该方法中，终于看到了ViewRootImpl的创建；

结论:从以上的源码分析可得知，ViewRootImpl对象是在onResume方法回调之后才创建，那么就说明了为什么在生命周期的onCreate方法里，甚至是onResume方法里都可以实现子线程更新UI，因为此时还没有创建ViewRootImpl对象，并不会进行是否为主线程的判断；

谷歌提出：“一定要在主线程更新UI”，实际是为了提高界面的效率和安全性，带来更好的流畅性；反推一下，假如允许多线程更新UI，但是访问UI是没有加锁的，一旦多线程抢占了资源，那么界面将会乱套更新了，体验效果就不言而喻了；所以在Android中规定必须在主线程更新UI。

---

三、总结

• 子线程可以在ViewRootImpl还没有被创建之前更新UI；
• 访问UI是没有加对象锁的，在子线程环境下更新UI，会造成不可预期的风险；
• 开发者更新UI一定要在主线程进行操作;