最近又在应用中遇到Can not perform this action after onSaveInstanceState这个bug，对于这个bug是有所了解的，但一下子仍然没看出来是为什么，因此在解bug的过程中重新梳理一下相关的逻辑，并做相应的记录。真正掌握commit的时机，告别这个bug。
bug发生的背景
bug发生的地方是这样的，Activity A(后续简称A)包含几个Fragment，可以点击跳转到Activity B，选择某一项之后返回Activity A显示相应的Fragment。因此在A的onResume方法中调用了commit。结果就是返回A的时候就发生了Crash。问题跟踪
跟进commit的代码里面很容易可以找到问题的原因是因为在checkStateLoss方法中，mStateSaved的值为true。(由于篇幅问题，源码中略去部分无关代码，完整源码请自行查看)
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是什么，什么时候是true，什么时候是false。对mStateSaved变量进行搜索。可以发现，几乎都是和生命周期相关的方法。
Parcelable saveAllState() {
if (HONEYCOMB) {
mStateSaved = true;
}
}
public void noteStateNotSaved() {
mStateSaved = false;
}
public void dispatchCreate() {
mStateSaved = false;
mExecutingActions = true;
moveToState(Fragment.CREATED, false);
mExecutingActions = false;
}
这里不贴所有的源码了，将mStateSaved设置为true的有saveAllState、dispatchStop两个方法，而在noteStateNotSaved、dispatchCreate、dispatchActivityCreated、dispatchStart、dispatchResume等方法中置为false。
对这些方法进行跟踪
@Override
protected void onSaveInstanceState(Bundle outState) {
super.onSaveInstanceState(outState);
Parcelable p = mFragments.saveAllState();
}
@Override
protected void onStop() {
super.onStop();
mStopped = true;
mHandler.sendEmptyMessage(MSG_REALLY_STOPPED);
mFragments.dispatchStop();
}
可以发现在onStop和onSaveInstanceState方法中进行调用，因此在onStop和onSaveInstanceSate之后就不能commit了。再跟踪设置为true的方法：
protected void onActivityResult(int requestCode, int resultCode, Intent data) {
mFragments.noteStateNotSaved();
}
protected void onNewIntent(Intent intent) {
super.onNewIntent(intent);
mFragments.noteStateNotSaved();
}
protected void onStart() {
if (!mCreated) {
mCreated = true;
mFragments.dispatchActivityCreated();
}
mFragments.dispatchStart();
}
在onActivityResult、onNewIntent调用noteStateNotSaved，在onCreate中调用dispatchCreate，在onStart中调用dispatchActivityCreated和dispatchStart。onResume有点特殊，单独提一下。
protected void onResumeFragments() {
mFragments.dispatchResume();
}
onResume在onResumeFragments调用。而onResumeFragments在哪里调用可以继续跟一下。
@Override
protected void onPostResume() {
super.onPostResume();
mHandler.removeMessages(MSG_RESUME_PENDING);
onResumeFragments();
mFragments.execPendingActions();
}
final Handler mHandler = new Handler() {
@Override
public void handleMessage(Message msg) {
switch (msg.what) {
case MSG_REALLY_STOPPED:
if (mStopped) {
doReallyStop(false);
}
break;
case MSG_RESUME_PENDING:
onResumeFragments();
mFragments.execPendingActions();
break;
default:
super.handleMessage(msg);
}
}
};
@Override
protected void onResume() {
super.onResume();
mHandler.sendEmptyMessage(MSG_RESUME_PENDING);
mResumed = true;
mFragments.execPendingActions();
}
onResumeFragments调用的地方有两个，一个是在onPostResume调用，一个在handler中，而发送MSG_RESUME_PENDING消息的地方则在onResume。可以得出结论onResume没有立刻将mStateSaved设置为false(敲黑板)。
到了这里，结合Activity的生命周期我们就基本知道，什么时候可以commit什么时候不行了。
-
案例中的问题
在项目中导致这个bug的原因有两个：- 以前跟过这个问题，但没有跟dispatchResume方法，想当然的以为onResume之后就可以commit了，但从刚刚的结论可以知道，并不行。
- 由于从B回到A，还得经过onStart方法，但由于B的Theme设置成透明的，因此onStart没有执行。
-
解决办法
在这个案例中，有几个解决办法：- 使用commitAllowingStateLoss方法。
- 覆写onPostResume、onResumeFragments，在这两个方法中commit。
总结
这一类问题很多人喜欢直接使用commitAllowingStateLoss方法，这个方法和commit的区别就是不调用checkStateLoss方法，因此不会有这个问题，是个万金油方法，但不建议使用。原因得从这个机制说起，在Activity在异常的情况下被关闭，会调用onSaveInstanceState保存状态，如果在onSaveInstanceState之后commit，则commit的内容状态得不到保存。
因此还是建议最好还是按照生命周期，合理的使用commit。
另一个注意点就是不要在子线程中commit，在线程中commit容易忽视Activity的生命周期而出现bug。
