[译] 支持库 27.1.0 中的 Loader

• 原文地址：Loaders in Support Library 27.1.0
• 原文做者：Ian Lake
• 译文出自：掘金翻译计划
• 本文永久连接：github.com/xitu/gold-m…
• 译者：dreamhb
• 校对者：Starriers

为了 支持库 27.1.0，我重写了 LoaderManager 的内部结构，Loaders API 以它为基础，我也想解释下这些改变背后的原因以及接下来会有什么期待。

Loader 和 Fragment 的一小段历史

一开始，Loader 和 Fragment 牢牢的联系在一块儿。这意味着，为了支持 Loader，在 FragmentActivity 和 Fragment 中有许多的代码，然而事实上他们几乎没有关联。这也意味着和 Activity、Fragment 以及架构组件生命周期 相比，Loader 的生命周期和保障是彻底独特的且受制与它那有趣且激动人心的行为差别和 bug。

27.1.0 中的改变

在 27.1.0 中，Loader 的遗留问题已经大幅度的减小：实现 LoaderManager 的代码行数只有以前的三分之一，也有不少的测试让 Loader 在将来可以保持一个良好的状态。

全部这些都得意于架构组件。更确切的说是 ViewModel ( 在配置变化时保持状态 ) 和 LiveData( 支持生命周期和回调 )。如今的 Loader 基于这些更高级别且充分测试的组件并从中受益，减小了不断增长的性能损失，提升了 Loader 的可靠性和正确性。

行为变化

这确实意味着一些行为变动。

首先，必须在主线程中调用 initLoader、restartLoader 和 destroyLoader。这提供了一些很是特别的保障在回调结束或开始时，例如在销毁一个 loader 后，你将永远不会拿到 onLoadFinished 的回调。

注意事项：就技术来讲，此次发布以前，你能够在其余线程中作 loader 操做，可是 LoaderManager 再也不是线程安全的，会致使常常性的未定义行为。

最重要的是，如今 onLoadFinished 和 LiveData Observers 同样，老是在 onStart 和 onStop 之间被调用，且不会在 onSaveInstanceState 以后。这样你能够在 onLoadFinished 中安全的作 Fragment Transactions 了。

我应当使用什么，loader 后续如何？

像我在以前的博客 Lifecycle Aware Data Loading with Architecture Components 中提到的那样，我强烈建议开发者使用 ViewModel+LiveData 的组合，我认为他们绝对是一个更灵活更容易理解的系统。然而，若是你已经有基于 loader 的 APIs，这些改变应当会极大的提高组件之后的可依赖性和稳定性。

这许多的改变让 Loader 变成一个功能，更加可选的依赖，不须要对 LifecycleOwner/ViewModelStoreOwner 作很底层的修改。

尝试下吧！

若是你正在使用 Loader，请尽快仔细查看并注意行为变动，他们都在发布事项 中。

注意事项：显而易见，只有支持库有这些更改。若是你使用的是 Android 框架的 Loader，请尽快切换到支持库。由于框架的 Loader APIs 不会有错误修复或者计划中的改进。

---

掘金翻译计划 是一个翻译优质互联网技术文章的社区，文章来源为 掘金 上的英文分享文章。内容覆盖 Android、iOS、前端、后端、区块链、产品、设计、人工智能 等领域，想要查看更多优质译文请持续关注 掘金翻译计划、官方微博、知乎专栏。