你可能漏掉的知识点: onResumeFragments

Question

长话短说：如果你在使用 FragmentActivity 的任何子类（比如最新的 AppCompatActivity），并且你正在考虑要在 onResume 方法中做 fragment transaction 操作，那么请在 onResumeFragment 里做这件事情。

如果你想知道详情或者一些注意事项，继续阅读。如果不想，没关系，下篇文章见。

还在看？那么 ok。

onResume 和 onResumeFragments 的区别是什么呢？下面是 官方文档 对 FragmentActivity.onResume 的解释：

将 onResume() 分发给 fragment。注意，为了更好的和旧版本兼容，这个方法调用的时候，依附于这个 activity 的 fragment 并没有到 resumed 状态。着意味着在某些情况下，前面的状态可能被保存了，此时不允许 fragment transaction 再修改状态。从根本上说，你不能确保 activity 中的 fragment 在调用 Activity 的 OnResume 函数后是否是 onresumed 状态，因此你应该避免在执行 fragment transactions 直到调用了 onResumeFragments 函数。

总的来说就是，你无法确定 activity 当前的 fragment 在 activity onResume 的时候也跟着 resumed 了，因此要避免在 onResumeFragments 之前进行 fragment transaction，因为到 onResumeFragments 的时候，状态已经恢复并且它们的确是 resumed 了的。

这样做可以避免发生 IllegalStateException 异常，在一个 fragment 的状态已经保存的情况下（通过 onSaveInstanceState），再试图进行 fragment transaction 操作就会抛出这个异常。
如果 fragment 的 activity 销毁并重建，前面保存的变量将丢失。要想更深的理解这个问题，可以阅读 Alex Lockwood 的 Fragment Transactions 与 Activity 状态的丢失 一文。

其实我是在知道 fragments 和 fragment transaction 了很久之后才知道 onResumeFragments 这个东西的。activity 的绝大部分生命周期中都不涉及到它，因为它只存在于兼容包里面的 FragmentActivity，而 SDK 里面的 Activity 则没有。不过 onResumeFragments 仍然值得去了解。

说了这么多，我这几天只能给一点很粗贱的建议：尽可能的避免在生命周期事件中尤其是 onResume 或者 onResumeFragments 中进行 fragment transaction，如果你正在考虑这样做，很可能你的 UI 和事务逻辑都需要反思一遍了。

不过那时以后要说的事了。