Android---Fragment- 的过去、现状与未来,android 网络层框架设计实战
override fun onCreate(savedInstanceState: Bundle?) {supportFragmentManager.fragmentFactory = MyFactory()super.onCreate(savedInstanceState)}
为了保证 API 的一致性,我们还准备通过下面的方式统一其他地方创建 Fragment 的方式。比如 Commit 操作,我们代理了您的 FragmentFactory,现在您只需要使用 Fragment 的类名,通过一行简单的代码,便能完成 Fragment 的创建、添加和初始化。
// 通过类名来添加 FragmentsupportFragmentManager.commit {add<MyFragment>(R.id.container)}
类似的,使用 FragmentScenario 时,只需要传入您的 FragmentFactory 即可。这个 FragmentFactory 既可以是只用来模拟依赖的虚拟 Factory,也可以是用于更多测试的真实 FragmentFactory。
// 使用自定义 FragmentFactory 创建 FragmentScenarioval scenario =launchFragmentInContainer<MyFragment>(factory = MockFactory())
FragmentContainerView
关于 API 的一致性,我们也尝试解决了 Fragment 的另一个一致性问题。
我们发现在添加 Fragment 时,通过 <Fragment> 标签添加与通过 FragmentTransaction 使用的是完全不同的两套系统。为了提供行为一致的 API,我们创建了 FragmentContainerView,并把它作为 Fragment 专属的容器。
FragmentContainerView 继承于 FrameLayout,但它只允许填充 FragmentView。它同时也替代了 <Fragment> 标签,只要在 class 属性中传入类名即可。由于 FragmentContainerView 内部使用的是 FragmentTransaction,所以无需担心,稍后在替换这个 Fragment 时也不会出现问题。
FragmentContainerView 也让我们有机会解决一些动画问题。例如 Fragment 在 Z 轴的层级问题。如下图所示,我们可以看到在 FrameLayout 中,Fragment 切换时没有显示动画,而是整个跳出到了屏幕上。这种问题是由于切入的 Fragment 和它的动画位于之前的 Fragment 的层级之下导致的。而 FragmentContainerView
会确保 Fragment 间的层级关系处于正确的状态,我们就可以看到切换动画了。

OnBackPressedDispatcher
另一个长期困扰我们的问题,是在 Fragment 中处理系统回退事件。为了解决这个问题,我们加入了 onBackPressedDispatcher。我们没有选择在 Fragment 中添加这个 API,而是将其加入了 Activity 中。现在任何组件都可以通过依赖 Activity 来处理回退事件。
下面是一段使用 onBackPressedDispatcher 的示例代码。您可以看到,首先 Fragment 从调用它的 Activity 中获取 onBackPressedDispatcher 对象,然后通过 addCallBack() 方法创建了一个 OnBackPressCallback,由于 Fragment 是 LifecycleOwner,所以这里可以传入 "this"。在此示例中,如果用户触发了回退操作,就会弹出一个确认窗口,而如果用户随后表示无论如何都想要退出的话,您可以先使回调失效,然后就可以执行默认的回退操作。
val dispatcher by lazy { requireActivity().onBackPressedDispatcher }lateinit var callback: OnBackPressedCallback
override fun onCreate(savedInstanceState: Bundle?) {super.onCreate(savedInstanceState)callback = dispatcher.addCallback(this) {showConfirmDialog()}}
private fun onConfirm() {callback.enabled = falsedispatcher.onBackPressed()}
所以这里其实并没有新的 API,只是整合了 Fragment 和架构组件现有功能。而我们接下来也打算进一步加深与架构组件的整合。举个例子,在 Fragment 中理应可以方便地获得 ViewModel 实例,但现实的状况却稍微有些麻烦。为了解决这个问题,我们创建了一些 Kotlin 属性代理。如下面的代码所示,利用这些属性代理,您可以轻松获得不同作用域的 ViewModel。
// 让获取 ViewModel 实例变得简单 val viewModel : MyViewModel by viewModels()val navGraphViewModel: MyViewModel by navGraphViewModels(R.id.main)val activityViewModel: MyViewModel by activityViewModels()
我们也从 Lifecycle 组件中受益良多。比如,我们不再使用自定义的生命周期方法 setUserVisibleHint,取而代之的是在添加 Fragment 到 ViewPager 或 Adapter 时调用统一的生命周期。这便是 ViewPager2 目前的工作机制,只有当前页面的 Fragment 会调用 onResume 方法。
// 设置只让当前展示的 Fragment 调用 onResume() 方法 class MyAdapter : FragmentPagerAdapter(BEHAVIOR_RESUME_ONLY_CURRENT_FRAGMENT)
Fragment 的未来
前面讲过的功能大多在 Fragment 1.1 中已经提供,与此同时,我们强烈建议使用 FragmentContainerView 容器来存储动态添加的 Fragment,而不要使用 FrameLayout 或其他布局。
当然,未来我们还将对 Fragment 做出许许多多的改进,下面我就来介绍几个我们当前正在进行的长期规划。不过要注意的是,接下来部分内容目前还没有正式推出,所以一些细节可能会有改变。
多重回退栈 (Multiple Back Stack)
首先要讲的是多重回退栈 (Multiple Back Stack)。我们知道在 Android 中,总是会有一个 Activity 栈,而 Fragment 也实现了同样的结构,用于保存回退栈信息。而我们想要实现的则是一种同时支持单一回退栈和多重回退栈的模型,好让屏幕上不可见的 Fragment 也能保存自己的状态,从而避免状态的丢失。与此相关的使用场景,比较典型的就是底部导航一类的导航视图。
下面是一个我们的示例应用。我们想要做的事情就是让应用中每个底部标签页都拥有自己的栈,这样它们就能保存各自的状态。而当您在这些标签页间切换时,我们也将帮您处理好从一个栈到另一个栈时状态的保存和恢复。

Fragment 间的通讯问题
我们想要解决的另一个问题与返回结果有关。
一直以来,诸如如何在 Fragment 间通讯,或者说如何在 Android 的各种组件间通讯的这类问题都深深困扰着我们。想要在 Fragment 间通讯,方法有很多,它们有好有坏。而这正体现出 Fragment 在这方面的 API 设计不佳。我们可以设计一些用于 Fragment 间通讯的 API,并且让它们在基于 Fragment 间互相持有依赖的前提下工作。但是这样的话,当前的 Fragment 将无法感知其它 Fragment 的生命周期。如果通讯的 Fragment 处在不活跃的生命周期中,那么通讯也将失败。
还有一个选项,是使用类似 onActivityResult 的 API。但我们所考虑的,不只是在 Fragment 之间通讯,而是希望能设计出一套公用的 API。它应当同时兼容 Activity、Fragment 等可能的导航组件,这样就算不知道对方的类型,也能建立通讯。
简化 Fragment 的生命周期
最后要说的问题,是 Fragment 的生命周期。当前 Fragment 的生命周期十分复杂,它包含了两套不同的生命周期。Fragment 自己的生命周期从它被添加到 FragmentManager 的时候开始,一直持续到它被 FragmentManager 移除并销毁为止;而 Fragment 所包含的视图,则有一个完全分离的生命周期。当您的 Fragment 进入回退栈时,视图将会被销毁。但 Fragment 则会继续存活。
于是我们产生了一个大胆的想法: 将两者合二为一会怎么样?在 Fragment 视图销毁时便销毁 Fragment,想要重建视图时就直接重建 Fragment,这样的话将大大减少 Fragment 的复杂度。而诸如 FragmentFactory 和状态保存一类,以往在 onConfigrationChange、 进程的死亡和恢复时使用的方法,在这种情况下将会成为默认选项。
当然,这个改动将会是十分的巨大。我们目前处理的方式,是将它作为一个可选 API 加入到了 FragmentActivity 中。使用了这个新的 API,就可以开启生命周期简化过的新世界。
总结
我们前面讲了 Fragment 一些历史问题的由来,以及我们刚刚为它加入的一些特性,包括:
FragmentScenario,Fragment 的测试框架
FragmentFactory,统一的 Fragment 实例化组件
FragmentContainerView,Fragment 专属视图容器
OnBackPressedDispatcher,帮助您在 Fragment 或其他组件中处理返回按钮事件
最后还介绍了几个我们仍在开发中的功能:
多重回退栈
评论