Fragments 在 Android P 中弃用

Question

我正在查看 文档 并发现了这个

此类在 API 级别 P 中已弃用。

为什么 fragments 在 android P 中被弃用？

原文由 RoyalGriffin 发布，翻译遵循 CC BY-SA 4.0 许可协议

Answer 1

支持库 27.1.0 中的重写

Ian 的中篇文章（2018 年 2 月 28 日）给了我们一个解释。他是 Google 的 Android 框架开发人员。

支持库 27.1.0 中的加载程序

对于 Support Library 27.1.0，我重写了 LoaderManager 的内部结构，该类为 Loaders API 提供支持，我想解释这些变化背后的原因以及未来的预期。

装载机和片段，一段历史

从一开始，Loaders 和 Fragments 就紧紧地绑在了一起。这意味着 FragmentActivity 和 Fragment 中的很多代码都在那里支持加载器，尽管事实上它们确实相当独立。 ……

27.1.0 中的变化

使用 27.1.0，Loaders 的技术债务已大大减少：……

……

注意：显然，这些更改仅适用于支持库加载器。如果您正在使用 Android framework Loaders，请尽快切换到 Support Library Loaders。没有为框架加载程序 API 计划的错误修复或改进。

似乎 Fragment 和 FragmentActivity 中的代码已被重构以使 Loaders 成为可选依赖项。

根据 发行说明，新实施基于 Lifecycle 。

重要变化

Loaders 的底层实现已被重写为使用 Lifecycle 。

架构组件

在 支持库 26.1.0 中， Fragment 和 FragmentActivity 采用了 Lifecycle 。

这是一个将支持库与架构组件的生命周期集成的特殊版本。如果您不使用 Lifecycles 库，则无需从 26.0.2 更新。有关详细信息，请参阅架构组件发行说明。

重要变化

• Fragment 和 FragmentActivity（AppCompatActivity 的基类）现在实现了 Architecture Components 的 LifecycleOwner 接口。

相比之下，Android P中的 Fragment 和 Activity 都没有实现接口 LifecycleOwner 。

在 Google+ 帖子 中（在 ThanosFisherman 的回答 中提到），Ian 发表了评论：

你不能在它发布后更改框架代码 - 它实际上是及时冻结的。这意味着没有新功能，更重要的是没有错误修复。这不是一个好的开发人员体验，特别是当我们在支持库中有一个完全支持的、最新的、向后兼容的版本时。

我认为这就是 Android P 不采用 Lifecycle 的原因。因此 Fragment 在 Android P 中被弃用。

原文由 qtmfld 发布，翻译遵循 CC BY-SA 3.0 许可协议

Answer 2

万一有人在寻找通过类名实例化片段的方法。

旧方法：

Fragment.instantiate(context, fragmentClass)

新的方法：

 val fm: FragmentManager = ...
fm.fragmentFactory.instantiate(ClassLoader.getSystemClassLoader(), fragmentClass)

---

使用扩展名：

文件名： FragmentManagerExt.kt

 import androidx.fragment.app.Fragment
import androidx.fragment.app.FragmentManager

fun FragmentManager.instantiate(className: String): Fragment {
    return fragmentFactory.instantiate(ClassLoader.getSystemClassLoader(), className)
}

用法示例：

 val fragment = supportFragmentManager.instantiate(fragmentClassName)

原文由 Markymark 发布，翻译遵循 CC BY-SA 4.0 许可协议