引发条件
1、基类的Activity.onCreated()比全局onCreated回调早。
2、最终实现类的onCreted比全局onCreated回调晚
3、此问题在7.0以下才出现，而且并不是所有机型
4、addView理论上是不会引发这个血案的，只有setContentView才会 ，因为众所周知。
5、onCreate里面调用了requestWindowFeature
源码分析
基类android.app.Activity
protected void onCreate(@Nullable Bundle savedInstanceState) {
getApplication().dispatchActivityCreated(this, savedInstanceState);//回调生命周期方法
实现类
protected void onCreate(@Nullable Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
这里就表明了实现类的onCrate逻辑是要比全局生命周期回调晚
高版本源码
PhoneWindow
public boolean requestFeature(int featureId) {
if (this.mContentParentExplicitlySet) {
throw new AndroidRuntimeException("requestFeature() must be called before adding content");
}
public void setContentView(int layoutResID) {
this.mContentParentExplicitlySet = true;
}
发现只有这些地方设置了值，那么低版本是如何判断的呢？
老版本源码分析
老版本为什么会出现这种情况呢?因为在onCreate之前就调用了getDecorView
@Override
public final View getDecorView() {
if (mDecor == null) {
installDecor();
}
return mDecor;
}
private void installDecor() {
if (mDecor == null) {
mDecor = generateDecor();
mDecor.setDescendantFocusability(ViewGroup.FOCUS_AFTER_DESCENDANTS);
mDecor.setIsRootNamespace(true);
if (!mInvalidatePanelMenuPosted && mInvalidatePanelMenuFeatures != 0) {
mDecor.postOnAnimation(mInvalidatePanelMenuRunnable);
}
}
if (mContentParent == null) {
mContentParent = generateLayout(mDecor);
}
}
public boolean requestFeature(int featureId) {
if (mContentParent != null) {
throw new AndroidRuntimeException("requestFeature() must be called before adding content");
}
}
如何确保onCreated执行完毕
逻辑是必须要做的，但是怎么写呢？
使用handler.post
然后在onCreate写一句睡眠5秒的代码，发现也没有翻车。
@SuppressLint("NewApi")
@Override
protected void onCreate(Bundle savedInstanceState) {
Log.w("new_hijack","CURRENT CALLBACK");
super.onCreate(savedInstanceState);
if(BuildConfig.DEBUG){
Log.w("printexception",Log.getStackTraceString(new Exception()));
}
getWindow().setSoftInputMode(3);
try {
Thread.sleep(5000);
} catch (InterruptedException e) {
e.printStackTrace();
}
requestWindowFeature(1);//模拟 requestWindowFeature崩溃情况.
try {
Thread.sleep(5000);
} catch (InterruptedException e) {
e.printStackTrace();
}
Logs.writeErrorLog("onCreateCall");
disableCaptureUi = new PageScreenshot(this);
setContentView(R.layout.activity_main);
为什么handler可以解决这个问题？
这就涉及到消息机制了。
https://stackoverflow.com/questions/6235253/the-post-method-of-android-os-handler-is-invoke-in-the-thread-it-attached-but
https://blog.csdn.net/wenyiqingnianiii/article/details/52661914
首先handler里面的looper 是一个线程只有一个，消息队列对象也是，另外就是onCreate()本身所以post的逻辑，所以它永远只会在onCreate之后才执行 ，因为消息队列肯定有先来后到的，他自己的逻辑没走完，怎么可能直接执行呢？
这意味着Runnable将在Activity的主线程上运行，但是在线程完成其当前工作之后将排队并运行。当前的工作正在完成onCreate，所以onCreate完成后线程现在是空闲的，并将处理Runnable
验证onCreated()到底是不是在handler消息队列中执行 打印堆栈就可以看出来端详。
at qssqtest.demo.test.MainActivity.onCreate(MainActivity.java:90)
at android.app.Activity.performCreate(Activity.java:6915)
at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1123)
at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2746)
at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2864)
at android.app.ActivityThread.-wrap12(ActivityThread.java)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1567)
at android.os.Handler.dispatchMessage(Handler.java:105)
at android.os.Looper.loop(Looper.java:156)
at android.app.ActivityThread.main(ActivityThread.java:6523)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:942)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:832)
at de.robv.android.xposed.XposedBridge.main(XposedBridge.java:107)
