让你不再俱怕 Fragment State Loss

让你不再俱怕 Fragment State Loss

原文链接： toughcoder.net

使用过Fragment的人我相信对臭名昭著的状态丢失问题（IllegalStateException: Can not perform this action after onSaveInstanceState）一定不会陌生。曾经被这个问题困扰了很久，相信很多同学也是。花些时间来好好把它研究一下，以弄懂为何会有这样的问题产生，然后就可以解决问题，或者合理的规避问题。

什么是状态恢复

安卓的状态恢复是一个比较令人困惑的特性，它源于拙劣的系统设计。当一个页面正在显示的时候，如果系统发生了一些变化，变化又足以影响页面的展示，比如屏幕旋转了，语言发生了变化等。安卓的处理方式就是把页面（Activity）强制杀掉，再重新创建它，重建时就可以读取到新的配置了。又或者，当离开了一个页面，再回到页面时，如果页面（Activity）因为资源不足被回收了，那么当再回到它时，系统也会重新创建这个页面。

状态恢复，是为了保持更好的用户体验，让用户感觉认为页面，是一直存在的，类似于处理器调用函数的保护现场和恢复现场。

Activity有二个钩子onSaveInstanceState和onRestoreInstanceState就是用来保存状态和恢复状态的。

当从Honeycomb引入了Fragment后，为了想让开发者更多的使用Fragment，或者想让Fragment更容易的使用，状态保存与恢复的时候也必须要把Fragment保存与恢复。Fragment本质上就是一个View tree，强行附加上一些生命周期钩子。所以，为了让页面能恢复成先前的样子，View是必须要重新创建的，因此Fragment是必须要恢复的。

Fragment的作用域是Activity，FragmentManager管理着一个Activity所有的Fragment，这些Fragment被放入一个栈中。每个Fragment有一个FragmentState，它相当于Fragment的snapshot，保存状态时FragmentManager把每个Fragment的FragmentState存储起来，最终存储到Activity的savedInstanceState中。

为什么会有这个异常

既然状态的保存与恢复都必须要把Fragment带上，那么一旦当Fragment的状态已保存过了，那么就不应该再改变Fragment的状态。因此FragmentManager的每一个操作前，都会调用一个方法来检查状态是否保存过了：

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状态保存是在Activity#onSaveInstanceState时做的，会调用FragmentManager#saveAllState方法，来进行Fragment的状态保存，同时设置mStateSaved为true，以标识状态已被保存过。

发生的场景以及如何应对

FragmentTransaction#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)

或者是这样的:

java.lang.IllegalStateException: Activity has been destroyed
at android.app.FragmentManagerImpl.enqueueAction(FragmentManager.java:1456)
at android.app.BackStackRecord.commitInternal(BackStackRecord.java:707)
at android.app.BackStackRecord.commit(BackStackRecord.java:671)
at net.toughcoder.miscellaneous.FragmentTestActivity

原因就是commit操作发生在了状态保存之后。Activity#onSaveInstanceState的调用是不受开发者控制的，并且不同的安卓版本之间存在差异。具体的可以参考大神的文章。

解决之道，如大神提的一样，就是保证Fragment的操作发生在Activity可见周期之内，换句话说，Fragment的操作应该发生在Activity#onResume与Activity#onPause之间，为什么限制这么死呢？一方面为了防止上面问题发生；另外，Fragment本质上是View，View的操作理应该是页面处于活动状态时才应该进行。

关键的点就是小心控制异步任务，在onPause或者最迟在onStop中要终止所有的异步任务。

另外，大招就是使用commitAllowStateLoss。

Activity#onBackPressed

还有一种情况，也会出现此异常，而且是在Activity中完全 没有Fragment的情况下：

java.lang.IllegalStateException: Can not perform this action after onSaveInstanceState at android.app.FragmentManagerImpl.checkStateLoss(FragmentManager.java:1434) at android.app.FragmentManagerImpl.popBackStackImmediate(FragmentManager.java:577) at android.app.Activity.onBackPressed(Activity.java:2751) at net.toughcoder.miscellaneous.FragmentStateLossActivity.onBackPressed(FragmentStateLossActivity.java:90) at net.toughcoder.miscellaneous.FragmentStateLossActivity$1.run(FragmentStateLossActivity.java:59) at android.os.Handler.handleCallback(Handler.java:751) at android.os.Handler.dispatchMessage(Handler.java:95) at android.os.Looper.loop(Looper.java:154) at android.app.ActivityThread.main(ActivityThread.java:6077) at java.lang.reflect.Method.invoke(Native Method) at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:865) at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:755)

或者是这样的：

java.lang.IllegalStateException: Can not perform this action after onSaveInstanceState at android.support.v4.app.FragmentManagerImpl.checkStateLoss(FragmentManager.java:1500) at android.support.v4.app.FragmentManagerImpl.popBackStackImmediate(FragmentManager.java:584) at android.support.v4.app.FragmentActivity.onBackPressed(FragmentActivity.java:169) at net.toughcoder.miscellaneous.FragmentStateLossActivity.onBackPressed(FragmentStateLossActivity.java:90) at net.toughcoder.miscellaneous.FragmentStateLossActivity$1.run(FragmentStateLossActivity.java:59) at android.os.Handler.handleCallback(Handler.java:751) at android.os.Handler.dispatchMessage(Handler.java:95) at android.os.Looper.loop(Looper.java:154) at android.app.ActivityThread.main(ActivityThread.java:6077) at java.lang.reflect.Method.invoke(Native Method) at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:865) at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:755)

这二个异常都是发生在没有使用Fragment的Activity中。相当的诡异，根本没有用Fragment为何还会抛出State loss的异常。只能从栈信息中的方法开始分析：

Activity的onBackPressed:

public void onBackPressed() {
    if (mActionBar != null && mActionBar.collapseActionView()) {
        return;
    }

    if (!mFragments.popBackStackImmediate()) {
        finishAfterTransition();
    }
}
复制代码

以及FragmentActivity的onBackPressed:

public void onBackPressed() {
    if (!mFragments.popBackStackImmediate()) {
        supportFinishAfterTransition();
    }
}
复制代码

从其源码中不难看出，响应BACK键时，一定会去pop fragment。前面提到过，FragmentManager在改变Fragment的状态前（增加，移除，改变生命周期状态都是改变状态）都会检查state loss：

@Override
public boolean popBackStackImmediate() {
    checkStateLoss();
    executePendingTransactions();
    return popBackStackState(mActivity.mHandler, null, -1, 0);
}
复制代码

前面说了，checkStateLoss其实就是检查mStateSaved这个变量是否为true。那么都哪里给它设置为true了呢？对于正统的Activity和Fragment（android.app.*），是在onSaveInstanceState时，且只有这时才设置：

Parcelable saveAllState() {
    // Make sure all pending operations have now been executed to get
    // our state update-to-date.
    execPendingActions();

    mStateSaved = true;
    // other codes.
}
复制代码

但是对于support包中的Fragment（android.support.v4.app.*）除了在onSaveInstanceState中设置以外，在onStop中也把mStateSaved置为true：

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);
}
复制代码

所以，无论你用的是哪个Fragment，如果onBackPressed发生在onSavedInstanceState之后，那么就会上面的crash。 Stack Overflow上面有类似的讨论，比较全面和票数较高就是这个和 这个。

二个讨论中，针对此场景的获得最多赞同的解法是，覆写Activity的onSaveInstanceState，然后不要调用super：

@Override
public void onSaveInstanceState() {
    // DO NOT call super
}
复制代码

从上面的分析来看，这个对于android.app.*中的Fragment是能解决问题的，因为是在Activity的onSaveInstanceState（super.onSaveInstanceState）中才把mStateSaved置为true，所以不调super，它就仍是false，当再pop时，也就不会抛出异常的。

但是这明显是一个拙劣的workaround，首先，你在防止系统保存fragment的状态，可能会引发一引起其他的问题；再有就是，对于support包，这还是不管用，你仍然能够遇到state loss exception，因为在其onStop时也会把mStateSaved置为true。

上面分析得出，问题产生的原因是onBackPressed发生在了onSavedInstance之后，那么的解法是，同样设置一个标志，如果状态已保存过，就不要再处理onBackPressed：

public class FragmentStateLossActivity extends Activity {
    private static final String TAG = "Fragment state loss";
    private boolean mStateSaved;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_fragment_state_loss);
        mStateSaved = false;
    }

    @Override
    protected void onSaveInstanceState(Bundle outState) {
        // Not call super won't help us, still get crash
        super.onSaveInstanceState(outState);
        if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.HONEYCOMB) {
            mStateSaved = true;
        }
    }

    @Override
    protected void onResume() {
        super.onResume();
        mStateSaved = false;
    }

    @Override
    protected void onPause() {
        super.onPause();
    }

    @Override
    protected void onStop() {
        super.onStop();
        mStateSaved = true;
    }

    @Override
    protected void onStart() {
        super.onStart();
        mStateSaved = false;
    }

    @Override
    protected void onDestroy() {
        super.onDestroy();
    }

    @Override
    public boolean onKeyDown(int keyCode, KeyEvent event) {
        if (!mStateSaved) {
            return super.onKeyDown(keyCode, event);
        } else {
            // State already saved, so ignore the event
            return true;
        }
    }

    @Override
    public void onBackPressed() {
        if (!mStateSaved) {
            super.onBackPressed();
        }
    }
}
复制代码

为了更彻底的杜绝问题，应该是状态保存过后，都不应该处理KEY事件。

其实，这也是合理的，onBackPressed一般是由BACK触发的，与KEY事件一样，都属于用户交互事件，用户交互事件都应该在Activity处于活动期间来响应，特别是过了onStop以后，再处理这样的事件也是没有意义的。

通常情况下，是不会发生这样的问题的，因为一般情况下是由BACK键触发onBackPressed，onBackPressed中调用finish()，finish才会触发销毁生命周期（save instance，pause，stop，destroy），自然不会产生onBackPressed发生在它们之后，也就没有此异常。但假如，有人为处理BACK事件，或者涉及Webview的BACK处理时，就有可能异步处理BACK，从而产生这个异常。

其实，从根儿上来讲，这是Android的设计不完善导致的，再看下pop back的实现：

@Override
public boolean popBackStackImmediate() {
    checkStateLoss();
    executePendingTransactions();
    return popBackStackState(mActivity.mHandler, null, -1, 0);
}
复制代码

难道第一句不应该是先判断此栈是否为空吗？如果为空（压根儿就没有用Fragment），为什么要check state loss，为什么还要去executePendingTransactions()? 但是，它又不得不这样做，因为Fragment的很多操作是异步的，到这个时候，有可能某些Fragment已被用户commit，但是还没有真正的添加到stack中去，因为只有把所有的pending transactions执行完了，才能知道到底有没有Fragment，但是执行pending transactions就会改变fragment的状态，就必须要check state loss。

看来万恶之源就是Fragment的transactions都是异步的。Anyway，Fragment的设计是有很多缺陷的，因为这并不是系统设计之初就考虑到的东西，所以，不可能像水果里的ViewController那样健壮好用。作为我们开发者，要么就干脆不用它，要么就把它研究透彻再使用，否则将会陷入无尽痛苦之中。

参考资料

• Fragment Transactions & Activity State Loss