一、问题

先来看两个Crash Log：

1.

java.lang.IllegalStateException: Can not perform this action after onSaveInstanceState
    at android.support.v4.app.ab.v(FragmentManager.java:1377)
    at android.support.v4.app.ab.a(FragmentManager.java:1395)
    at android.support.v4.app.h.a(BackStackRecord.java:637)
    at android.support.v4.app.h.b(BackStackRecord.java:616)
    at android.support.v4.app.DialogFragment.show(DialogFragment.java:139)
    at com.sankuai.common.views.ai.a(MaoyanDialogBuilder.java:184)
    at com.sankuai.movie.y.handleMessage(MovieMainActivity.java:750)
    at android.os.Handler.dispatchMessage(Handler.java:99)
    at android.os.Looper.loop(Looper.java:137)
    at android.app.ActivityThread.main(ActivityThread.java:4424)
    at java.lang.reflect.Method.invokeNative(Native Method)
    at java.lang.reflect.Method.invoke(Method.java:511)
    at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:784)
    at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:551)
    at dalvik.system.NativeStart.main(Native Method)

2.

java.lang.IllegalStateException: Can not perform this action inside of onLoadFinished
 at android.support.v4.app.FragmentManagerImpl.checkStateLoss(FragmentManager.java:1381)
 at android.support.v4.app.FragmentManagerImpl.enqueueAction(FragmentManager.java:1395)
 at android.support.v4.app.BackStackRecord.commitInternal(BackStackRecord.java:637)
 at android.support.v4.app.BackStackRecord.commit(BackStackRecord.java:616)
 at android.support.v4.app.DialogFragment.show(DialogFragment.java:139)
 at com.sankuai.common.views.MaoyanDialogBuilder.show(MaoyanDialogBuilder.java:185)
 at com.sankuai.movie.MovieMainActivity$8$1$1.onLoadFinished(MovieMainActivity.java:609)
 at com.sankuai.movie.MovieMainActivity$8$1$1.onLoadFinished(MovieMainActivity.java:590)
 at android.support.v4.app.LoaderManagerImpl$LoaderInfo.callOnLoadFinished(LoaderManager.java:427)
 at android.support.v4.app.LoaderManagerImpl$LoaderInfo.onLoadComplete(LoaderManager.java:395)
 at android.support.v4.content.Loader.deliverResult(Loader.java:104)

二、原因

经过查找，发现这两个Crash处于由同一个方法触发：

FragmentManagerImpl#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);
    }
}

这个方法中的每一个异常分别对应了上述的两段Crash Log。下面逐一分析。

三、分析

第一部分：mStateSaved：

关于这个问题，可以参考这篇文章，Fragment Transactions & Activity State Loss。

从代码中可以看出，若这个字段为true，则会抛出异常。检查代码中与这个字段相关的内容，如下：

Parcelable saveAllState() {
    // Make sure all pending operations have now been executed to get
    // our state update-to-date.
    execPendingActions();
 
    if (HONEYCOMB) {
        // As of Honeycomb, we save state after pausing.  Prior to that
        // it is before pausing.  With fragments this is an issue, since
        // there are many things you may do after pausing but before
        // stopping that change the fragment state.  For those older
        // devices, we will not at this point say that we have saved
        // the state, so we will allow them to continue doing fragment
        // transactions.  This retains the same semantics as Honeycomb,
        // though you do have the risk of losing the very most recent state
        // if the process is killed...  we'll live with that.
        mStateSaved = true;
    }
    ...
}
  
public void noteStateNotSaved() {
    mStateSaved = false;
}
 
public void dispatchCreate() {
    mStateSaved = false;
    moveToState(Fragment.CREATED, false);
}
 
public void dispatchActivityCreated() {
    mStateSaved = false;
    moveToState(Fragment.ACTIVITY_CREATED, false);
}
 
public void dispatchStart() {
    mStateSaved = false;
    moveToState(Fragment.STARTED, false);
}
 
public void dispatchResume() {
    mStateSaved = false;
    moveToState(Fragment.RESUMED, false);
}
 
public void dispatchPause() {
    moveToState(Fragment.STARTED, false);
}
 
public void dispatchStop() {
    // See saveAllState() for the explanation of this.  We do this for
    // all platform versions, to keep our behavior more consistent between
    // them.
    mStateSaved = true;
 
    moveToState(Fragment.STOPPED, false);
}

可以看到，这个字段的使用与生命周期有关，随便找一个生命周期的传递方法去查看使用：

会有三处使用到，分别研究

1）Fragment#getChildFragmentManager

/**
 * Return a private FragmentManager for placing and managing Fragments
 * inside of this Fragment.
 */
final public FragmentManager getChildFragmentManager() {
    if (mChildFragmentManager == null) {
        instantiateChildFragmentManager();
        if (mState >= RESUMED) {
            mChildFragmentManager.dispatchResume();
        } else if (mState >= STARTED) {
            mChildFragmentManager.dispatchStart();
        } else if (mState >= ACTIVITY_CREATED) {
            mChildFragmentManager.dispatchActivityCreated();
        } else if (mState >= CREATED) {
            mChildFragmentManager.dispatchCreate();
        }
    }
    return mChildFragmentManager;
}

这是在Fragment中获取嵌套使用Fragment，获取childFragmentManager时调用，即告知childFragmentManager父Fragment当前的生命周期。此时也会执行childFragmentManager的初始化。

2）Fragment#performStart

void performStart() {
    if (mChildFragmentManager != null) {
        mChildFragmentManager.noteStateNotSaved();
        mChildFragmentManager.execPendingActions();
    }
    mCalled = false;
    onStart();
    if (!mCalled) {
        throw new SuperNotCalledException("Fragment " + this
                + " did not call through to super.onStart()");
    }
    if (mChildFragmentManager != null) {
        mChildFragmentManager.dispatchStart();
    }
    if (mLoaderManager != null) {
        mLoaderManager.doReportStart();
    }
}

这是在Fragmen在自己的生命周期变化过程中，通知子Fragment。

3）FragmentActivity#onStart

/**
 * Dispatch onStart() to all fragments.  Ensure any created loaders are
 * now started.
 */
@Override
protected void onStart() {
    super.onStart();
 
    mStopped = false;
    mReallyStopped = false;
    mHandler.removeMessages(MSG_REALLY_STOPPED);
 
    if (!mCreated) {
        mCreated = true;
        mFragments.dispatchActivityCreated();
    }
 
    mFragments.noteStateNotSaved();
    mFragments.execPendingActions();
     
    if (!mLoadersStarted) {
        mLoadersStarted = true;
        if (mLoaderManager != null) {
            mLoaderManager.doStart();
        } else if (!mCheckedForLoaderManager) {
            mLoaderManager = getLoaderManager("(root)", mLoadersStarted, false);
            // the returned loader manager may be a new one, so we have to start it
            if ((mLoaderManager != null) && (!mLoaderManager.mStarted)) {
                mLoaderManager.doStart();
            }
        }
        mCheckedForLoaderManager = true;
    }
    // NOTE: HC onStart goes here.
     
    mFragments.dispatchStart();
    if (mAllLoaderManagers != null) {
        final int N = mAllLoaderManagers.size();
        LoaderManagerImpl loaders[] = new LoaderManagerImpl[N];
        for (int i=N-1; i>=0; i--) {
            loaders[i] = mAllLoaderManagers.valueAt(i);
        }
        for (int i=0; i<N; i++) {
            LoaderManagerImpl lm = loaders[i];
            lm.finishRetain();
            lm.doReportStart();
        }
    }
}

这是Activity在生命周期发生变化时，通知Fragment。

现在了解了这个行为是和整个Activity、Fragment的生命周期有关的，回过头再来看mStateSaved，这个字段是在onPause或者onStop之后就被置为true。在Android中，由于对运行时的生命周期应用能做的实在是很少，用户可以随时切换Activity，系统也可以随时回收处于后台的Activity内存，所以Android为了保证在再次返回Activity时让它看起来同离开时相似，会使用onSaveInstanceState()来保存一些状态。若在onSaveInstanceState()被调用之后调用FragmentTransaction#commit()，那么这个Fragment的状态就不会被保存，在之后恢复时也不会恢复这个Fragment，使得恢复时UI发生一些变化。
那为什么是onPause或者onStop之后被置为true？这和Android的版本发展有关，在HoneyComb之前，Activity被设计成在onPause之前不会被杀掉，所以onSaveInstanceState()是紧挨着onPause()之前调用的，但是在HoneyComb之后，Activity被设计成只有在onStop()之后才会被杀死，所以onSaveInstanceState()会在onStop()之前，而不是在onPause之前调用。

pre-Honeycomb
post-Honeycomb
Activities can be killed before onPause()?  NO  NO
Activities can be killed before onStop()?   YES NO
onSaveInstanceState(Bundle) is guaranteed to be called before...    onPause()   onStop()

由于这个原因，若是在旧机型的onPause()之后调用FragmentTransaction#commit()，这个状态就可能会丢失。这是由于Android开发者为了避免过多的异常而做出的让步，允许在onPause()和onStop()之间偶尔丢失commit()状态。

pre-Honeycomb
post-Honeycomb
commit() before onPause()   OK  OK
commit() between onPause() and onStop() STATE LOSS  OK
commit() after onStop() EXCEPTION   
EXCEPTION

应当注意的是，不仅仅是Activity的生命周期会影响，若使用的是嵌套在Fragment中的子Fragment，由上述代码可知，也会有类似情况。

第二部分：mNoTransactionsBecause

再看一下FragmentManagerImpl#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);
    }
}

还有一个和StateLoss相关的字段是mNoTransactionsBecause，若这个字段不为空，则抛出异常。先查看这个字段在哪里使用，或者说，在什么情况下这个字段会不为空。

可以看到调用的地方主要是两个类，FragmentManager 和 LoaderManager，在FragmentManager中的使用都是用于抛出异常的，并不在意这个，而是在意何时不为空的，在LoaderManager中主要两个地方为这个字段赋值：

1）destory

void destroy() {
    if (DEBUG) Log.v(TAG, "  Destroying: " + this);
    mDestroyed = true;
    boolean needReset = mDeliveredData;
    mDeliveredData = false;
    if (mCallbacks != null && mLoader != null && mHaveData && needReset) {
        if (DEBUG) Log.v(TAG, "  Reseting: " + this);
        String lastBecause = null;
        if (mActivity != null) {
            lastBecause = mActivity.mFragments.mNoTransactionsBecause;
            mActivity.mFragments.mNoTransactionsBecause = "onLoaderReset";
        }
        try {
            mCallbacks.onLoaderReset(mLoader);
        } finally {
            if (mActivity != null) {
                mActivity.mFragments.mNoTransactionsBecause = lastBecause;
            }
        }
    }
    mCallbacks = null;
    mData = null;
    mHaveData = false;
    if (mLoader != null) {
        if (mListenerRegistered) {
            mListenerRegistered = false;
            mLoader.unregisterListener(this);
        }
        mLoader.reset();
    }
    if (mPendingLoader != null) {
        mPendingLoader.destroy();
    }
}

2）callOnLoadFinished

void callOnLoadFinished(Loader<Object> loader, Object data) {
    if (mCallbacks != null) {
        String lastBecause = null;
        if (mActivity != null) {
            lastBecause = mActivity.mFragments.mNoTransactionsBecause;
            mActivity.mFragments.mNoTransactionsBecause = "onLoadFinished";
        }
        try {
            if (DEBUG) Log.v(TAG, "  onLoadFinished in " + loader + ": "
                    + loader.dataToString(data));
            mCallbacks.onLoadFinished(loader, data);
        } finally {
            if (mActivity != null) {
                mActivity.mFragments.mNoTransactionsBecause = lastBecause;
            }
        }
        mDeliveredData = true;
    }

在这两个地方的考量，也是由于loader的异步可能导致fragment在onSaveInstanceState()之后调用导致状态丢失。

四、解决方案

那么如何解决这个问题？

1）在LoaderManager.LoaderCallbacks#onLoadFinished 或者 LoaderManager.LoaderCallbacks#onLoaderReset中使用

这里直接使用commit()方法会直接抛出异常，需要加Handler避免在这两个回调函数中直接使用commit()方法

2）在使用FragmentTransaction#commit()方法时注意当前的生命周期。

一般而言，会在onCreate()或者响应用户的操作事件时才会使用commit()方法，这不会有问题，但假若在别的生命周期中使用就要小心了。例如onActivityResult(), onStart(), 和 onResume()，就需要注意。例如，在onResume()中使用，但onResume()并不会保证在Activity状态恢复之后调用，此时需要使用FragmentActivity#onResumeFragments()或者Activity#onPostResume()中调用，这两个会保证在状态恢复之后调用。

3）避免异步回调中使用commit()方法

异步回调，如AsyncTask#onPostExecute() 和 LoaderManager.LoaderCallbacks#onLoadFinished()，之后无法保证当前的生命状态，而且异步通常会执行一些比较耗时的操作，更容易使得这样的丢失发生，如用户发出一个请求之后点了HOME键。

4）使用 commitAllowingStateLoss()方法

这个方法会跳过mStateSaved的检查，也不会在意会发生怎样的影响，就算无法执行或Activity状态恢复之后发生了UI变动也不会有警报。

5）针对DialogFragment的解决方案

由于DialogFragment和其它Fragment相比比较特殊，创建、回收更频繁也更不容易控制。

方法一：

对于DialogFragment而言，只有show()方法而没有showAllowingStateLoss()方法。。。而且很多时候都需要在网络请求返回之后根据返回的字段来显示，所以最好在base中添加对Activity和Fragment的生命周期追踪方法。但自己添加的方法和原生的毕竟在执行时间上还是有一点时间差的，不能够100%避免crash。

方法二：

或许有想法说可以重写DialogFragment#show()方法，让它支持commitAllowingStateLoss()，好吧，来看下源码。。。这是show方法：

/**
 * Display the dialog, adding the fragment to the given FragmentManager.  This
 * is a convenience for explicitly creating a transaction, adding the
 * fragment to it with the given tag, and committing it.  This does
 * <em>not</em> add the transaction to the back stack.  When the fragment
 * is dismissed, a new transaction will be executed to remove it from
 * the activity.
 * @param manager The FragmentManager this fragment will be added to.
 * @param tag The tag for this fragment, as per
 * {@link FragmentTransaction#add(Fragment, String) FragmentTransaction.add}.
 */
public void show(FragmentManager manager, String tag) {
    mDismissed = false;
    mShownByMe = true;
    FragmentTransaction ft = manager.beginTransaction();
    ft.add(this, tag);
    ft.commit();
}
 
/**
 * Display the dialog, adding the fragment using an existing transaction
 * and then committing the transaction.
 * @param transaction An existing transaction in which to add the fragment.
 * @param tag The tag for this fragment, as per
 * {@link FragmentTransaction#add(Fragment, String) FragmentTransaction.add}.
 * @return Returns the identifier of the committed transaction, as per
 * {@link FragmentTransaction#commit() FragmentTransaction.commit()}.
 */
public int show(FragmentTransaction transaction, String tag) {
    mDismissed = false;
    mShownByMe = true;
    transaction.add(this, tag);
    mViewDestroyed = false;
    mBackStackId = transaction.commit();
    return mBackStackId;
}

可以看到，和普通的Fragment显示方法区别并不大，其实DialogFragment只是一个Fragment里面套了个Dialog而已。但，有个很神奇的字段，mShownByMe，这个字段是做什么的？定义处和这里并没有注释，通过查找这个字段的使用，发现了这两个方法：

@Override
public void onAttach(Activity activity) {
    super.onAttach(activity);
    if (!mShownByMe) {
        // If not explicitly shown through our API, take this as an
        // indication that the dialog is no longer dismissed.
        mDismissed = false;
    }
}
 
@Override
public void onDetach() {
    super.onDetach();
    if (!mShownByMe && !mDismissed) {
        // The fragment was not shown by a direct call here, it is not
        // dismissed, and now it is being detached...  well, okay, thou
        // art now dismissed.  Have fun.
        mDismissed = true;
    }
}

通过这里可以发现，这个字段是判断DialogFragment是不是通过原生API的show()方法来显示的。。否则就不在onAttach()和onDetach()里设置mDismissed字段的，再看onDetach里的注释，为什么有种深深恶意。。（我辛辛苦苦写好了API，你为什么不用？你为什么不用？你为什么不用？(╯‵□′)╯︵┻━┻）
重写show()也是可以的，但需要紧接着重写onAttach()、onDetach()等方法。
若有需要重写show(FragmentTransaction transaction, String tag)方法，除了mShownByMe字段还需要注意mViewDestroyed字段的值设置。

其实对于重写show()方法的弊端主要在于无法保证show()的执行，从而导致isShowing()等方法的判断不准确，引起一些其他的问题。

方法三：

弃用DialogFragment。这种方法可以避免如此繁复的生命周期，代码和使用简洁不少，但也少了 DialogFragment 的优势，例如不能在切换屏幕时保留 Dialog 等。

方法一的优势在于并不需要对DialogFragment的内部实现做详尽的了解，也避免了开发者的恶意，但在onPause()之后，onSaveInstanceState()之前的dialog都不会展示出来。

方法二的优势在于API使用者并不需要在调用API的同时还为它的上下文环境担惊受怕，但重写难度较大，而且会有状态丢失的情况。

方法三也不是不可，只是有些问题只适用 DialogFragment 解决，手动实现会有很多变数。

自行斟酌使用。