最近遇到了这个异常，记录一下解决办法。

首先看一下这个异常是从哪里抛出来的：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
//FragmentManager
public void enqueueAction(OpGenerator action, boolean allowStateLoss) {
       if (!allowStateLoss) {
           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);
       }
   }

也就是在对fragment进行commit的时候，如果这时候mStateSaved那就会抛出这个异常，而mStateSaved是在saveAllState也就是onSaveInstanceState和dispatchStop也就是Activity::onStop中。也就是说如果在这两个生命周期方法之中或者之后对Fragment进行Commit就会出现这个异常。特别是DialogFragment，一般的Fragment还可以使用commitAllowingStateLoss来进行”丑陋的”避免，而DialogFragment的默认show方法 

1
2
3
4
5
6
7
public void show(FragmentManager manager, String tag) {
        mDismissed = false;
        mShownByMe = true;
        FragmentTransaction ft = manager.beginTransaction();
        ft.add(this, tag);
        ft.commit();
    }

根本不给机会。

上面说到抛出这个异常的原因，引申出什么情况下容易出现这种情况，就是异步回调的时候进行commit。因为这个时候你无法知道当前的状态，碰巧这个时候应用进入后台，执行了onStop或者被杀死onSaveInstanceState,就挂了。使用Fragment有好处，就是比Activity轻，跳转不用进行IPC。但是真的不怎么好用，到处的坑。再说这里，例如使用MVP，在onDestroyView对View进行清空，(这个是在Activity的onDestroy调用)，也就是在这之前对View操作都是安全的，但是Fragment在onStop之后就不能再进行commit了。使用View==null判断根本不行，真的防不胜防🤣🤣🤣。

解决办法：
Fragment全解析系列（一）：那些年踩过的坑。至于为什么前面说commitAllowingStateLoss是个”丑陋”的解决办法，这里有更详细的说明Fragment Transactions & Activity State Loss，早在13年就提及这个问题。