大家好我是kconn，我是一个不爱看源码，不喜欢分析源码，更不喜欢写文章的程序员。自从面试被人虐后，我做了一个艰难的决定，我决定把我的天赋带到迈...，不好意思跑错片场，我决定好好研究下源码，欢迎大家来看我作死。
前段时间无聊到死，想看源码但是也不晓得从哪里入手，于是想到了最经典的handler。
在看handler的时候我突然七窍开了一窍，佛祖突然从我的脑海中浮现，他问我为什么子线程不能更新UI？于是花了些时间看了源码，看不懂的地方又查了些资料。虽然说研究的不是很深，但是还算是有所研究吧，于是我打算研究源码的计划到此为止了。
在我刚有这想法的时候，佛祖又出现了。他说：“不如你写个文章，既能让你加深印象，也能让你有所收获，何乐而不为呢？”
emmm，佛祖说得对，于是我就写了这篇文章。佛祖保佑我早日功成名就！！！
怀着不畏牺牲的精神，我在onCreate中新建一个子线程更新UI。
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
initView();
new Thread(new Runnable() {
@Override
public void run() {
tv_show_msg.setText("skrskrskr，哟哟哟，giao~");
}
}).start();
}
textView原来的文本是 “你有freestyle吗？” ，代码运行之后，照“不能在子线程更新UI”的常识来讲，结果肯定抛异常。但是结果如何，却是成功更新了UI！
说好的子线程不能更新UI呢！！！
接着我在button中新建了一个线程来更新UI。
@Override
public void onClick(View v) {
switch (v.getId()) {
case R.id.btn_send_msg:
new Thread(new Runnable() {
@Override
public void run() {
tv_show_msg.setText("Giao来也");
}
}).start();
break;
default:
break;
}
}
结果却抛出我熟悉的异常
这就对了嘛，skrskrskr
然后我在onCreate中让线程睡个200毫秒，结果发现也是崩溃。
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
initView();
new Thread(new Runnable() {
@Override
public void run() {
try {
Thread.sleep(200);
} catch (InterruptedException e) {
e.printStackTrace();
}
tv_show_msg.setText("有种别蹦！");
}
}).start();;
}
当时的第一个想法就是这个家伙会不会和onResume有什么不可描述的关系。
后来我还是找到在异常日志里面ViewRootImpl的checkThread方法点进去看。
void checkThread() {
// 如果当前线程不是主线程就抛出异常
if (mThread != Thread.currentThread()) {
throw new CalledFromWrongThreadException(
"Only the original thread that created a view hierarchy can touch its views.");
}
}
接着往下看异常日志，发现了ViewRootImpl中调用的地方是requestLayout方法，于是我继续往下肛！
@Override
public void requestLayout() {
if (!mHandlingLayoutInLayoutRequest) {
// 检测当前线程
checkThread();
mLayoutRequested = true;
// view树遍历
scheduleTraversals();
}
}
这里插个嘴：scheduleTraversals中会起一个异步消息进行view树的遍历，感兴趣的同学可以去看《Android内核解析》。
回到正题，我往下看的时候发现requestLayout方法是实现了ViewParent接口
public interface ViewParent {
...
public void requestLayout();
...
}
异常日志中也看到view的requestLayout方法，本着两小伙同名同姓，又出现在同一个案发现场，一定有某些关系的想法点进去看了。
@CallSuper
public void requestLayout() {
...
if (mParent != null && !mParent.isLayoutRequested()) {
mParent.requestLayout();
}
...
}
由此可见，每次view刷新的时候都会去检测一次线程，这就能说明为什么在子线程中更新UI会抛出异常。本警长呕心沥血，费劲千辛万苦终于查明了事情的真相，可喜可贺。
额，差点忘了还有个坑没填，为啥在onCreate中子线程更新UI不会报错？对啊，为啥？
其实原因很简单，既然是用ViewRootImpl的checkThread方法来检查线程，那么就说明在onCreate的时候ViewRootImpl还没被创建，所以不会走checkThread方法，自然就不会报错了。
那么坑来了，ViewRootImpl是在什么时候创建的？
首先先看下activity里面的流程，具体的大家可以自己去看看，我这里就写个简单的。
@Override
public Activity handleLaunchActivity(ActivityClientRecord r,
PendingTransactionActions pendingActions, Intent customIntent) {
...
final Activity a = performLaunchActivity(r, customIntent);
...
return a;
}
private Activity performLaunchActivity(ActivityClientRecord r, Intent customIntent) {
...
Activity activity = null;
try {
...
// 创建activity
activity = mInstrumentation.newActivity(
cl, component.getClassName(), r.intent);
...
} catch (Exception e) {
...
}
try {
...
if (activity != null) {
...
activity.attach(appContext, this, getInstrumentation(), r.token,
r.ident, app, r.intent, r.activityInfo, title, r.parent,
r.embeddedID, r.lastNonConfigurationInstances, config,
r.referrer, r.voiceInteractor, window, r.configCallback);
...
// 初始化activity的onCreate方法
if (r.isPersistable()) {
mInstrumentation.callActivityOnCreate(activity, r.state, r.persistentState);
} else {
mInstrumentation.callActivityOnCreate(activity, r.state);
}
...
}
...
} catch (SuperNotCalledException e) {
throw e;
} catch (Exception e) {
...
}
return activity;
}
既然onCreate里面并没有创建ViewRootImpl，那么看下onResume。
@Override
public void handleResumeActivity(IBinder token, boolean finalStateRequest, boolean isForward,
String reason) {
...
// 初始化onResume方法
final ActivityClientRecord r = performResumeActivity(token, finalStateRequest, reason);
...
if (!r.activity.mFinished && willBeVisible && r.activity.mDecor != null && !r.hideForNow) {
...
if (r.activity.mVisibleFromClient) {
r.activity.makeVisible();
}
}
...
}
各位观众，请看！在初始化onResume方法之后接着调用了activity的makeVisible方法。为何会这样，原因是在onResume的时候界面无法看见，所以要调用makeVisible方法把他肛出来。
void makeVisible() {
if (!mWindowAdded) {
ViewManager wm = getWindowManager();
wm.addView(mDecor, getWindow().getAttributes());
mWindowAdded = true;
}
mDecor.setVisibility(View.VISIBLE);
}
ViewManager 是个接口，WindowManager继承ViewManager也是个接口，便找WindowManager的实现类WindowManagerImpl，打开之后看到了addView方法。
再次插嘴：在handleResumeActivity方法中也有wm.addView，我嫌它麻烦所以在这个方法里面讲了，其实都差不多。
好了，接下来继续肛源码。
@Override
public void addView(@NonNull View view, @NonNull ViewGroup.LayoutParams params) {
applyDefaultToken(params);
mGlobal.addView(view, params, mContext.getDisplay(), mParentWindow);
}
再点进去看WindowManagerGlobal的addView方法
public void addView(View view, ViewGroup.LayoutParams params,
Display display, Window parentWindow) {
...
ViewRootImpl root;
View panelParentView = null;
synchronized (mLock) {
...
root = new ViewRootImpl(view.getContext(), display);
view.setLayoutParams(wparams);
mViews.add(view);
mRoots.add(root);
mParams.add(wparams);
// do this last because it fires off messages to start doing things
try {
root.setView(view, wparams, panelParentView);
} catch (RuntimeException e) {
// BadTokenException or InvalidDisplayException, clean up.
if (index >= 0) {
removeViewLocked(index, true);
}
throw e;
}
}
}
综上所述，最后的结果是ViewRootImpl是在onResume之后创建的，真相大白！
这就是为什么在onCreate中用子线程更新UI不蹦，而延迟之后就发生车祸。
最后再说一句，肛源码不容易，我也不是大牛，文章也写的不是很好。大家看着有什么想法都可以说，我不一定会看，看了也不一定会回，因为我要加班！
差点忘了说，我这里肛的是android-28
bye~
