FragmentManager执行事务异常求助：StackOverflow方案均无效

我太懂你这种在onResume里执行Fragment替换时踩坑的感受了——这个异常的核心原因是：在onResume这个生命周期阶段，FragmentManager本身已经在处理Activity恢复相关的内部事务了，你此时提交新的Fragment事务，就会和它的内部操作产生冲突。

结合你给出的代码场景，我给你几个针对性的解决方案：

• 方案1：用主线程post延迟执行事务（优先推荐）
  把你的Fragment替换逻辑延迟到主线程的消息队列末尾，等FragmentManager完成当前所有事务后再执行，完美避开冲突：

  @Override
  public void onResume() {
      super.onResume();
      if(condition) {
          // 可以用容器View的post方法，或者全局的DecorView
          findViewById(R.id.container_id).post(() -> replaceFragment());
          // 要是找不到对应View，就用这个兜底：
          // getWindow().getDecorView().post(() -> replaceFragment());
      }
  }
  

• 方案2：先处理完待执行事务再提交新的
  如果你必须立刻执行Fragment替换，可以先让FragmentManager把所有待处理的事务执行完毕，再提交你的新事务：

  public void replaceFragment() {
      if (fragmentName != null && !this.isDestroyed()) {
          // 先执行所有待处理的Fragment事务
          getSupportFragmentManager().executePendingTransactions();
          final FragmentTransaction ft = getSupportFragmentManager().beginTransaction();
          ft.replace(container_id, FragmentInstantiate());
          ft.commitAllowingStateLoss();
      }
  }
  

  提醒一下：这个方法会阻塞主线程直到事务完成，频繁用可能影响界面流畅度，所以非必要不优先选这个。

• 方案3：把逻辑移到onPostResume生命周期
  如果业务逻辑允许，把Fragment替换的判断和调用移到onPostResume方法里——这个方法是在onResume完全执行完毕后才会调用的，此时FragmentManager已经处理完所有恢复事务，不会再有冲突：

  @Override
  protected void onPostResume() {
      super.onPostResume();
      if(condition) {
          replaceFragment();
      }
  }
  

你可以根据自己的业务需求选最合适的方案，比如要界面一恢复就显示新Fragment，方案1或者3都很稳妥；如果有特殊的即时性要求，再考虑方案2。

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