欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识！
您现在的位置是： 首页

让你不再俱怕Fragment State Loss

程序员文章站 2022-05-14 08:13:40
...

转自：http://toughcoder.net/blog/2016/11/28/fear-android-fragment-state-loss-no-more/

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

让你不再俱怕Fragment State Loss

什么是状态恢复

安卓的状态恢复是一个比较令人困惑的特性，它源于拙劣的系统设计。当一个页面正在显示的时候，如果系统发生了一些变化，变化又足以影响页面的展示，比如屏幕旋转了，语言发生了变化等。安卓的处理方式就是把页面（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的每一个操作前，都会调用一个方法来检查状态是否保存过了：

1
2
3
4
5
6
7
8
9
10

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:

1
2
3
4
5
6
7
8
9

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

    if (!mFragments.popBackStackImmediate()) {
        finishAfterTransition();
    }
}

以及FragmentActivity的onBackPressed:

1
2
3
4
5

public void onBackPressed() {
    if (!mFragments.popBackStackImmediate()) {
        supportFinishAfterTransition();
    }
}

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

1
2
3
4
5
6

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

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

1
2
3
4
5
6
7
8

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：

1
2
3
4
5
6
7
8

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：

1
2
3
4

@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：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

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的实现：

1
2
3
4
5
6

@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 Fragment Transaction

上一篇： Activity和Fragment生命周期

下一篇： 现科第一届CTF-Web/Misc/Crypto/Mobile部分Write Up

推荐阅读