应用切后台返回后如何恢复原有Fragment：EditProfileFragment状态丢失问题

应用切后台重新打开时直接回到初始ProfileFragment、丢失之前停留的EditProfileFragment页面状态，本质是系统回收应用进程后，没有正确还原原有任务栈与Fragment托管状态，可按以下步骤逐一排查修复：

1. 修正Activity重建时的Fragment加载逻辑 #

• 绝大多数状态丢失问题源于在Activity的onCreate方法中，无判断条件直接执行初始Fragment加载逻辑：当Activity被系统回收后重建，系统会先自动还原之前托管的全部Fragment状态，如果此时又手动重新加载初始的ProfileFragment，会直接覆盖恢复的页面栈，强制回到初始页面。
• 正确的加载判断逻辑：仅当onCreate传入的savedInstanceState为空（即首次启动Activity）时，才执行初始ProfileFragment的加载。存在保存状态时完全跳过手动Fragment加载，交给系统自动完成栈恢复：

  @Override
  protected void onCreate(Bundle savedInstanceState) {
      super.onCreate(savedInstanceState);
      setContentView(R.layout.activity_profile_host);
      // 首次启动才加载初始Fragment
      if (savedInstanceState == null) {
          getSupportFragmentManager().beginTransaction()
              .replace(R.id.fragment_container, new ProfileFragment())
              .commit();
      }
      // 有保存状态时，系统自动恢复之前的Fragment栈，包含EditProfileFragment
  }
  

2. 校验onSaveInstanceState的重写逻辑 #

• 部分开发者重写onSaveInstanceState时，会直接跳过super.onSaveInstanceState()的调用，导致系统无法自动保存Activity托管的Fragment栈状态、可见性、用户交互进度，重建Activity时只能加载初始页面。
• 必须在自定义状态保存逻辑前调用父类方法，确保系统层的状态保存流程完整执行。

3. 排查任务栈跳转Flag与启动模式的影响 #

• 检查从ProfileFragment跳转到EditProfileActivity时设置的Intent Flag：如果误用了FLAG_ACTIVITY_CLEAR_TOP、FLAG_ACTIVITY_NEW_TASK、FLAG_ACTIVITY_CLEAR_TASK这类会直接清除任务栈上层页面的Flag，会导致切后台返回时，系统自动清理后直接拉取栈底的Profile所在Activity到前台。
• 不要给页面设置不匹配的启动模式：避免给承载ProfileFragment的主Activity设置singleInstance、带独立taskAffinity的singleTask模式，这类模式会打破原有任务栈结构，导致系统重新启动应用时无法正确关联到之前的任务栈，直接新建任务栈加载默认启动页。

4. 规避生命周期变更触发的状态错乱 #

• 在AndroidManifest.xml中为所有相关Activity配置android:configChanges覆盖屏幕旋转、字体大小调整、系统语言变更等场景，避免配置变更触发Activity重建时的状态丢失。
• 不要在onSaveInstanceState方法调用之后执行Fragment提交操作：此时系统已经完成当前页面的状态快照，后续的Fragment变更不会被纳入恢复流程，容易导致重建后页面栈和实际操作顺序不匹配。

内容的提问来源于stack exchange，提问作者Polina