[TOC]

前面我们学习了Fragment的基础知识学习

关于FragmentTransaction的各种提交方法: commit(),commitAllowingStateLoss(),commitNow()和commitNowAllowingStateLoss()。我们来整体学一下。

FragmentTransaction的提交方法

Fragment中FragmentTransaction提供了四种不同的方法来commit一个transaction:

  • commit()
  • commitAllowingStateLoss()
  • commitNow()
  • commitNowAllowingStateLoss()

下面，我们分别分析一下这几种用法：

commit() VS commitAllowingStateLoss()

用commit()提交有时候会遇到IllegalStateException, 说你在onSaveInstanceState()之后提交。

常用Fragment的哥们，可能会经常遇到这样Activity状态不一致：State loss这样的错误。主要是因为：commit方法一定要在Activity.onSaveInstance()之前调用。

1
2
3
4
5
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)

关于这个问题，在另一篇文章里面有过很好的介绍：
https://www.androiddesignpatterns.com/2013/08/fragment-transaction-commit-state-loss.html

commit()调用

commit()和commitAllowingStateLoss()在实现上唯一的不同就是当你调用commit()的时候, FragmentManger会检查是否已经存储了它自己的状态, 如果已经存了, 就抛出IllegalStateException.

commitAllowingStateLoss()调用

那么如果你调用的是commitAllowingStateLoss(), 并且是在onSaveInstanceState()之后, 你可能会丢失掉什么状态呢?

答案是：你可能会丢掉FragmentManager的状态, 即save之后任何被添加或被移除的Fragments.

概述

举例说明:

  1. 在Activity里显示一个FragmentA;
  2. 然后Activity被后台, onStop()和onSaveInstanceState()被调用;
  3. 在某个事件触发下, 你用FragmentB replace FragmentA , 使用的是 commitAllowingStateLoss();

这时候, 用户再返回应用, 可能会有两种情况发生:

  1. 如果系统杀死了你的activity, 你的activity将会重建, 使用了上述步骤2保存的状态, 所以A会显示, B不会显示;
  2. 如果系统没有杀死你的activity, 它会被提到前台, FragmentB就会显示出来, 到下次Activity stop的时候, 这个包含了B的状态就会被存下来.

(上述测试可以利用开发者选项中的”Don’t Keep Activities”选项).

那么你要选择哪一种呢? 这就取决于你提交的是什么, 还有你是否能接受丢失.

如果不是特殊情况下，不能接受丢失，一般情况下，我们调用commitAllowingStateLoss()即可。

commit(), commitNow() 和 executePendingTransactions()

使用commit()的时候, 一旦调用, 这个commit并不是立即执行的, 它会被发送到主线程的任务队列当中去, 当主线程准备好执行它的时候执行.

popBackStack()的工作也是这样, 发送到主线程任务队列中去. 也即说它们都是异步的.

但是有时候你希望你的操作是立即执行的, 之前的开发者会在commit()调用之后加上executePendingTransactions()来保证立即执行, 即变异步为同步.

support library从v24.0.0开始提供了commitNow()方法,之前用executePendingTransactions()会将所有pending在队列中还有你新提交的transactions都执行了。

而commitNow()将只会执行你当前要提交的transaction.所以commitNow()避免你会不小心执行了那些你可能并不想执行的transactions.

但是你不能对要加在back stack中的transaction使用commitNow(), 即addToBackStack()和commitNow()不能同时使用。

为什么呢?

想想一下, 如果你有一个提交使用了commit(), 紧接着又有另一个提交使用了commitNow(), 两个都想加入back stack,

那back stack会变成什么样呢? 到底是哪个transaction在上, 哪个在下? 答案将是一种不确定的状态,

因为系统并没有提供任何保证来确保顺序, 所以系统决定干脆不支持这个操作.

前面提过popBackStack()是异步的, 所以它同样也有一个同步的兄弟popBackStackImmediate().

所以实际应用的时候怎么选择呢?

  1. 如果你需要同步的操作, 并且你不需要加到back stack里, 使用commitNow().support library在FragmentPagerAdapter里就使用了commitNow()来保证在更新结束的时候, 正确的页面被加上或移除.
  2. 果你操作很多transactions, 并且不需要同步, 或者你需要把transactions加在back stack里, 那就使用commit().
  3. 如果你希望在某一个指定的点, 确保所有的transactions都被执行, 那么使用executePendingTransactions().