让你不再俱怕 Fragment State Loss

本文详细探讨了Android中Fragment状态丢失问题的原因,包括Activity的状态恢复机制、Fragment的保存与恢复,以及为何会出现Cannot perform this action after onSaveInstanceState异常。文章通过分析源码,列举了在FragmentTransaction提交、Activity的onBackPressed等场景下出现异常的情况,并提供了相应的解决方案,如避免在状态保存后修改Fragment状态、控制异步任务以及合理使用commitAllowStateLoss。最后,作者指出Fragment设计上的缺陷,建议开发者要么避免使用,要么深入理解后再使用,以避免不必要的痛苦。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

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

参考资料

### 关于分层强化学习的代码框架 分层强化学习是一种通过分解复杂任务来提高效率和效果的方法。为了实现这一目标,可以利用现有的开源工具和框架。以下是几个可能帮助到您的具体方向: #### 使用 PyTorch 和 OpenAI Gym 的 Feudal 网络示例 在构建分层深度强化学习模型时,可以选择使用 PyTorch 框架并结合 OpenAI Gym 提供的环境进行开发[^1]。这种组合能够有效地模拟复杂的场景,并允许开发者专注于算法的设计。 下面是一个简单的代码框架模板,展示如何初始化一个基本的训练循环以及加载所需的依赖项: ```python import gym import torch from feudal_networks import FeudalNetworkAgent # 假设这是您定义好的Feudal网络类 def train_agent(env_name='CartPole-v1', episodes=100): env = gym.make(env_name) state_dim = env.observation_space.shape[0] action_dim = env.action_space.n agent = FeudalNetworkAgent(state_dim, action_dim) for episode in range(episodes): state = env.reset() done = False while not done: action = agent.select_action(torch.tensor(state).float()) next_state, reward, done, _ = env.step(action) agent.update(reward, next_state, done) # 更新策略 state = next_state train_agent() ``` 此脚本仅作为起点;完整的 `FeudalNetworkAgent` 类需依据论文中的描述进一步扩展[^3]。 #### 利用 RLlib 实现更灵活的解决方案 除了手动编写整个架构外,还可以考虑采用像 **RLlib** 这样的高级库简化流程[^4]。尽管该库主要针对分布式计算进行了优化,但它同样适用于单机实验阶段。借助其模块化设计,您可以轻松切换不同的后端引擎(如 TensorFlow 或 PyTorch),从而加快迭代速度。 例如,在配置文件中指定参数即可启动一次试验运行: ```yaml algorithm: PPO env: CartPole-v1 framework: pytorch num_workers: 4 rollout_fragment_length: 50 train_batch_size: 200 sgd_minibatch_size: 64 lr: 0.0001 gamma: 0.99 lambda_: 0.95 clip_param: 0.2 vf_loss_coeff: 1e-4 entropy_coeff: 0.01 model: fcnet_hiddens: [64, 64] evaluation_interval: None stop: training_iteration: 100 ``` 随后调用命令行接口提交作业给 Ray 集群处理。 --- ### 推荐的相关 GitHub 仓库链接 对于希望深入研究 SNN-HRL 及其他变体的朋友来说,这里列举了一些有价值的公共资源: 1. [feudal_rl](https://github.com/andrewliao11/pytorch-a3c-feudal): Andrew Liao 开发的一个基于 A3C 的 Feudal Network 复现版本。 2. [hierarchical-reinforcement-learning](https://github.com/google-research/hierarchical-reinforcement-learning): Google Research 发布的一系列 HRL 方法集合。 3. [rllib](https://github.com/ray-project/ray/tree/master/python/ray/rllib): Apache 2.0 许可下的大规模增强学习平台源码公开地址。 这些资料不仅提供了理论上的指导方针,还附带详尽的文档说明便于快速上手实践。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值