稀有猿诉

十年磨一剑,历炼出锋芒,说话千百句,不如码二行。

让你不再俱怕Fragment State Loss

使用过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的每一个操作前,都会调用一个方法来检查状态是否保存过了:

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那样健壮好用。作为我们开发者,要么就干脆不用它,要么就把它研究透彻再使用,否则将会陷入无尽痛苦之中。

参考资料

Comments