Android P中不推荐使用碎片

Question

我正在查看文档并找到了这个

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

为什么在Android P中不推荐使用片段？

Answer 1

在支持库27.1.0中重写

伊恩的中期帖子(2018年2月28日)给了我们一个解释.他是Google的Android Framework开发人员.

支持库27.1.0中的加载程序

对于支持库27.1.0,我重写了LoaderManager的内部,这是为Loaders API提供支持的类,我想解释这些更改背后的原因以及未来的发展方向.

装载机和碎片,历史
从一开始,装载机和碎片就紧紧地绑在一起.这意味着FragmentActivity和Fragment中的很多代码都支持Loaders,尽管确实存在相当独立的代码....

27.1.0中
有什么变化 27.1.0,装载机的技术债务大大减少:......

...

注意:显然,这些更改仅适用于支持库加载程序.如果您使用的是Android框架加载器,请尽快切换到支持库加载器.没有针对框架Loader API计划的错误修复或改进.

为了使Loaders成为可选的依赖项,似乎代码已被重构Fragment并且FragmentActivity已被重构.

根据发布说明,新的实施基于Lifecycle.

重要更改  已重写Loaders
的基础实现  以使用  Lifecycle.

架构组件

在支持库26.1.0,Fragment 并  FragmentActivity已通过Lifecycle.

这是一个将支持库与Architecture Components的Lifecycles集成的特殊版本.如果您没有使用Lifecycles库,则无需从26.0.2更新.有关更多信息,请参阅Architecture Components发行说明.

重要的变化

• Fragment和FragmentActivity(AppCompatActivity的基类)现在实现了Architecture Components的LifecycleOwner接口.

相比之下,Android P中的Fragment和Activity尚未实现该接口LifecycleOwner.

在Google+帖子中(在ThanosFisherman的回答中提到),Ian发表了评论:

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

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

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)

Answer 3

支持库片段仍然存在.Google鼓励您使用支持库版本在所有API级别,向后移植的错误修复以及Lifecycle和ViewModel支持中获得一致的行为.

https://plus.google.com/+IanLake/posts/WAGQiG7LaKs