Ian 的 Medium 文章(2018 年 2 月 28 日)为我们解释了相关内容。他是谷歌 Android 框架开发人员。
支持库 27.1.0 中的加载器
为了支持库 27.1.0,我重新编写了 LoaderManager 的内部实现,这个类支持 Loaders API。我想解释一下这些更改背后的原因以及未来可以期待什么。
加载器和片段,一个历史
从一开始,加载器和片段就紧密地联系在一起。这意味着尽管它们确实是相对独立的,但 FragmentActivity 和 Fragment 中的很多代码都是为了支持加载器而存在的。…27.1.0 中的变化
在 27.1.0 中,加载器技术债务已大大减少:……
注意:显然,这些更改仅适用于支持库加载器。如果您正在使用 Android 框架加载器,请尽快切换到支持库加载器。框架加载器 API 没有计划进行错误修复或改进。
似乎已经重构了Fragment
和FragmentActivity
的代码以使加载器成为可选依赖项。
根据发行说明,新实现基于 Lifecycle
。
重要变更
Loaders的底层实现已经被重新编写,以使用Lifecycle。架构组件
在Support Library 26.1.0中,
Fragment
和FragmentActivity
已经采用了Lifecycle
。这是一个特殊的版本,将Support Library与Architecture Components中的生命周期集成。如果您不使用Lifecycle库,则不需要从26.0.2进行更新。有关更多信息,请参阅Architecture Components发行说明。
重要变化
Fragment
和FragmentActivity
(作为AppCompatActivity
的基类)现在实现了Architecture Components的LifecycleOwner
接口。相比之下,Android P中的Fragment和Activity没有实现接口
LifecycleOwner
。在Google+发布的帖子中(在ThanosFisherman的答案中提到),Ian发表了评论:
你不能在发布后更改框架代码-它实际上被冻结在时间上。这意味着没有新功能,更重要的是没有错误修复。对于开发人员来说,这不是一个好的开发体验,尤其是当我们有一个完全支持、最新、向后兼容的版本的Support Library时。
我认为这就是Android P不采用
Lifecycle
的原因。因此,在Android P中,Fragment
已被弃用。
如果有人正在寻找通过类名实例化片段的方法。
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)
支持库 Fragment 已经逐渐成为主流。Google 鼓励您使用支持库版本,以获得在所有 API 级别上一致的行为、修复后移植的错误,并提供生命周期和 ViewModel 的支持。