0
点赞
收藏
分享

微信扫一扫

全局插入view引发的血案requestFeature() must be called before adding content一步一步分析原因以及采用最佳解决办法解决此问题...


引发条件

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可以解决这个问题?

首先​​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)

举报

相关推荐

0 条评论