我对这个问题的解决方案是

在片段中添加方法:

@Override
public View onCreateView(LayoutInflater inflater, ViewGroup container, Bundle savedInstanceState) {
    ...
    guideMapFragment = (SupportMapFragment)a.getSupportFragmentManager().findFragmentById(R.id.guideMap);
    guideMap = guideMapFragment.getMap();
    ...
}

@Override
public void onDestroyView() {
    SherlockFragmentActivity a = getSherlockActivity();
    if (a != null && guideMapFragment != null) {
        try {
            Log.i(LOGTAG, "Removing map fragment");
            a.getSupportFragmentManager().beginTransaction().remove(guideMapFragment).commit();
            guideMapFragment = null;
        } catch(IllegalStateException e) {
            Log.i(LOGTAG, "IllegalStateException on exit");
        }
    }
    super.onDestroyView();
}

可能很糟糕，但找不到更好的了。

当我在一个片段中使用startactivity时，我会得到这个异常;

当我改变使用startactivityforresult时，异常消失了:)

所以修复它的简单方法是使用startActivityForResult api:)

你可以使用FragmentActivity。onStart在popBackStackImmediate之前

是这样的:

public void backStackFragment() {
    this.start();
    getFragmentManager().popBackStackImmediate();
}

public void start(){
    FragmentActivity a = getActivity();
    if(a instanceof DepositPlanPadActivity){
      ((DepositPlanPadActivity)a).onStart();
    }
    if(a instanceof SmallChangePlanPad){
            ((SmallChangePlanPad)a).onStart();
        }
        if(a instanceof UserCenterActivity){
            ((UserCenterActivity)a).onStart();
        }
    }

http://jorryliu.blogspot.com/2014/09/illegalstateexception-can-not-perform.html

我有这个问题。但是我认为这个问题与commit和commitAllowStateLoss无关。

下面的堆栈跟踪和异常消息是关于commit()的。

java.lang.IllegalStateException: Can not perform this action after onSaveInstanceState
at android.support.v4.app.FragmentManagerImpl.checkStateLoss(FragmentManager.java:1341)
at android.support.v4.app.FragmentManagerImpl.enqueueAction(FragmentManager.java:1352)
at android.support.v4.app.BackStackRecord.commitInternal(BackStackRecord.java:595)
at android.support.v4.app.BackStackRecord.commit(BackStackRecord.java:574)

但是这个异常是由onBackPressed()引起的

java.lang.IllegalStateException: Can not perform this action after onSaveInstanceState
at android.support.v4.app.FragmentManagerImpl.checkStateLoss(Unknown Source)
at android.support.v4.app.FragmentManagerImpl.popBackStackImmediate(Unknown Source)
at android.support.v4.app.FragmentActivity.onBackPressed(Unknown Source)

它们都是由checkStateLoss()引起的

private void checkStateLoss() {
    if (mStateSaved) {
        throw new IllegalStateException(
                "Can not perform this action after onSaveInstanceState");
    }
    if (mNoTransactionsBecause != null) {
        throw new IllegalStateException(
                "Can not perform this action inside of " + mNoTransactionsBecause);
    }

mStateSaved在onSaveInstanceState之后为真。

这个问题很少发生。我从来没有遇到过这个问题。我不能再出现这个问题。

我找到了25517号

它可能在下列情况下发生

Back键在onSaveInstanceState之后，但在新活动开始之前被调用。 在代码中使用onStop()

我不确定问题的根源是什么。 所以我用了一个丑陋的方法。

@Override
public void onBackPressed() {

    try{
        super.onBackPressed();
    }catch (IllegalStateException e){
        // can output some information here
        finish();
    }
}

在Android源代码中查找导致此问题的原因，给出FragmentManagerImpl类(Activity中可用的实例)中的标记mStateSaved的值为true。当Activity#onSaveInstanceState调用后堆栈被保存(saveAllState)时，它被设置为true。 之后，来自ActivityThread的调用不会使用FragmentManagerImpl#noteStateNotSaved()和dispatch()中的可用重置方法重置该标志。

在我看来，有一些可用的修复，这取决于你的应用程序正在做什么和使用:

的好方法

首先，我要为Alex Lockwood的文章做广告。然后，根据我目前所做的:

For fragments and activities that don't need to keep any state information, call commitAllowStateLoss. Taken from documentation: Allows the commit to be executed after an activity's state is saved. This is dangerous because the commit can be lost if the activity needs to later be restored from its state, so this should only be used for cases where it is okay for the UI state to change unexpectedly on the user`. I guess this is alright to use if the fragment is showing read-only information. Or even if they do show editable info, use the callbacks methods to retain the edited info. Just after the transaction is commit (you just called commit()), make a call to FragmentManager.executePendingTransactions().

不推荐的方法:

As Ovidiu Latcu mentioned above, don't call super.onSaveInstanceState(). But this means you will lose the whole state of your activity along with fragments state. Override onBackPressed and in there call only finish(). This should be OK if you application doesn't use Fragments API; as in super.onBackPressed there is a call to FragmentManager#popBackStackImmediate(). If you are using both Fragments API and the state of your activity is important/vital, then you could try to call using reflection API FragmentManagerImpl#noteStateNotSaved(). But this is a hack, or one could say it's a workaround. I don't like it, but in my case it's quite acceptable since I have a code from a legacy app that uses deprecated code (TabActivity and implicitly LocalActivityManager).

下面是使用反射的代码:

@Override
protected void onSaveInstanceState(Bundle outState) {
    super.onSaveInstanceState(outState);
    invokeFragmentManagerNoteStateNotSaved();
}

@SuppressWarnings({ "rawtypes", "unchecked" })
private void invokeFragmentManagerNoteStateNotSaved() {
    /**
     * For post-Honeycomb devices
     */
    if (Build.VERSION.SDK_INT < 11) {
        return;
    }
    try {
        Class cls = getClass();
        do {
            cls = cls.getSuperclass();
        } while (!"Activity".equals(cls.getSimpleName()));
        Field fragmentMgrField = cls.getDeclaredField("mFragments");
        fragmentMgrField.setAccessible(true);

        Object fragmentMgr = fragmentMgrField.get(this);
        cls = fragmentMgr.getClass();

        Method noteStateNotSavedMethod = cls.getDeclaredMethod("noteStateNotSaved", new Class[] {});
        noteStateNotSavedMethod.invoke(fragmentMgr, new Object[] {});
        Log.d("DLOutState", "Successful call for noteStateNotSaved!!!");
    } catch (Exception ex) {
        Log.e("DLOutState", "Exception on worka FM.noteStateNotSaved", ex);
    }
}

干杯!

当一个Fragment或AppCompatActivity的状态通过onSaveInstanceState()保存时，它的UI被认为是不可变的，直到ON_START被调用。在保存状态后尝试修改UI可能会导致应用程序导航状态的不一致，这就是为什么FragmentManager会抛出异常，如果应用程序在保存状态后运行FragmentTransaction。参见commit()了解详细信息。

LiveData通过避免在观察者的关联生命周期至少不是STARTED时调用它的观察者来避免这种边缘情况。在幕后，它在决定调用其观察者之前调用isAtLeast()。