Android开发笔记：理解Fragment

导言

本篇文章产生的原因很简单，就是我在了解Android Jetpack中的Lifecycle框架时发现Lifecycle具体时间和状态的更新都是由一个名为ReportFragment的Fragment来跟踪的，为了更好的了解Fragment是如何追踪Activity生命周期状态的变化我们有必要对Fragment组件进行更深入的探讨。

Fragment管理器

首先我们要探讨的就是Fragment管理器(FragmentManager)，我们在进行动态地加载和移除Fragment的操作时都需要借助这个Fragment管理器来开启事务，提交请求。Fragment的管理与ViewGroup与View的关系类似，一个Fragment既是上一个父Fragment的子Fragment，又是下一个子Fragment的父Fragment。而每一个父Fragment都有一个FragmentManager来管理其子Fragment。

我们以Google官网上的一张图为例子：

其中绿色的部分代表的是顶级Activity的布局界面，蓝色部分就是Activity中的Fragment容器了，白色的部分是示例中的最底层的Fragment。在Example 1中Fragment容器中装有两个子Fragment，而每一个父Fragment都有一个FragmentManager，所以例子一种的包含关系和管理关系如下所示：

对于中间第二级的Fragment，我们即可以通过getParentFragmentManager来获取管理其自身的FragmentManager，还可以通过getChildFragmentManager来获取其管理的Manager。

Fragment事务

所谓的事务，我会把它理解为是一组关于Fragment的操作，我们可以通过beginTransaction方法来开启一个事务，通过这个事务我们可以实现Fragment的添加，移除，替换等操作。当一切操作都添加完毕后我们可以通过commit方法将当前事务给提交。不过，被提交的事务并不会被马上执行，相反的，它会等待主线程，一旦它可以被执行了才会被执行。当然了，我们也可以通过commitNow方法来马上触发事务，不过需要说明的是commitNow是和addToBackStack不兼容的，也就是说一旦你调用了commitNow方法就不能再使用返回栈了。还有一种方法就是调用executePendingTransactions方法，这个方法会执行所有被挂起的事务。

触发事务可能会引起Fragment的生命周期的变化，具体来说，当一个Fragment实例被执行add操作后，它会进入到STARED状态之中去。

通过事务我们还可以限制Fragment的生命周期，调用setMaxLifecycle方法可以为Fragment设置最大的生命周期，所谓的大和小就是靠近运行状态(Resume)的距离，距离运行状态越近生命周期越大。

Fragment的生命周期

接下来我们要谈到的是Fragment的生命周期，每一个Fragment都有其生命周期。Fragment实现了LifecycleOwner接口，说明Fragment也可以使用Lifecycle进行检测。实际上，Activity的LifecycleOwner状态的变化也是通过一个特殊的Fragment来进行跟踪的。除了使用Lifecycler之外，Fragment与Activity一样本身就带有关于生命周期的回调方法。

还需要说明的是Fragment的视图也单独有一个Lifecycle，它独立于Fragment的Lifecycle的，Fragment会为其视图维护一个LifecycleOwner，我们可以通过 getViewLifecycleOwner() 或 getViewLifecycleOwnerLiveData()进行访问。

生命周期之下的Fragment和Fragment管理器

具体来说Fragment的生命周期是由其FragmentManager所管理的，在实例化Fragment之后，它会从INITIALIZED状态开始，并且将其添加进入FragmentManager之中，FragmentManager负责确定ragment应该是处于哪个状态的。而且FragmentManager还会负责Fragment与其宿主Activity的附加和分离。将 Fragment 添加到 FragmentManager 并附加到其宿主 Activity 后，系统将调用 onAttach() 回调。此时，该 Fragment 处于活跃状态，FragmentManager 管理其生命周期状态。此时，findFragmentById() 等 FragmentManager 方法会返回此 Fragment。

在发生任何生命周期状态变更之前，系统都始终会调用 onAttach()。在发生生命周期状态变更之后，系统始终都会调用 onDetach()。

当Fragment被从FragmentManager之中移除并被分离之后会被触发其onDetach()方法，说明该Fragment已经不再处于活跃状态，并且我们无法通过findFragmentById()检索到。

Fragment生命周期状态与回调

在确定 Fragment 的生命周期状态时，FragmentManager 会考虑以下方面：

• Fragment 的状态极限由其 FragmentManager 确定。Fragment 不能超过其 FragmentManager 的状态。
• 作为 FragmentTransaction 的一部分，您可以使用 setMaxLifecycle() 在 Fragment 上设置生命周期状态极限。
• Fragment 的生命周期状态绝对不能超过其父级。例如，父 Fragment 或 Activity 必须在其子 Fragment 之前启动。同样，子 Fragment 必须在其父 Fragment 或 Activity 之前停止。

这整个规则是很合理的，当然只有先启动了父Fragment才能启动子Fragment，下面便搬出Fragment生命周期转变的图,可以看到Fragment的生命周期和它的View的生命周期是不一样的：

在Fragment发生状态改变的过程中系统会首先调用其新状态关联的生命周期回调，然后才会向Lifecycle发送Event事件触发Lifecycle框架下的回调方法。如果Fragment已经实例化的话，Fragment 的视图 Lifecycle 也会紧随其后向观察者发出此事件。

当Fragment到达了CREATED状态时就说明它已经被添加到了FragmentManager之中，并且已经调用了onAttach方法了。强烈建议将生命周期感知型组件与 Fragment 的 STARTED 状态相关联，因为该状态可确保 Fragment 的视图（如已创建）可用，并且可确保在 Fragment 的子 FragmentManager 上安全地执行 FragmentTransaction。如果 Fragment 的视图为非 null，在 Fragment 的 Lifecycle 转为 STARTED 后，Fragment 的视图 Lifecycle 会立即转为 STARTED。

当 Fragment 转为 STARTED 时，系统会调用 onStart() 回调。

Fragment 不再可见后，Fragment 及其视图的 Lifecycle 将转为 CREATED 状态，并向其观察者发出 ON_STOP 事件。不仅停止父 Activity 或 Fragment 会触发该状态转换，而且父 Activity 或 Fragment 保存状态也会触发该状态转换。此行为可保证在保存 Fragment 的状态之前调用 ON_STOP 事件。这使得 ON_STOP 事件成为能够安全地在子 FragmentManager 上执行 FragmentTransaction 的最后一个时间点。

如图所示，onStop() 回调与使用 onSaveInstanceState() 保存状态之间的顺序因 API 级别而异。对于 API 28 之前的所有 API 级别，在 onStop() 之前调用 onSaveInstanceState()。对于 API 28 及更高级别，调用顺序正好相反。