- 原文地址：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、前端、後端、區塊鏈、產品、設計、人工智慧 等領域，想要檢視更多優質譯文請持續關注 掘金翻譯計劃、官方微博、知乎專欄。