[譯] 支持庫 27.1.0 中的 Loader

爲了 支持庫 27.1.0,我重寫了 LoaderManager 的內部結構,Loaders API 以它爲基礎,我也想解釋下這些改變背後的原因以及接下來會有什麼期待。html

Loader 和 Fragment 的一小段歷史

一開始,Loader 和 Fragment 牢牢的聯繫在一塊兒。這意味着,爲了支持 Loader,在 FragmentActivityFragment 中有許多的代碼,然而事實上他們幾乎沒有關聯。這也意味着和 Activity、Fragment 以及架構組件生命週期 相比,Loader 的生命週期和保障是徹底獨特的且受制與它那有趣且激動人心的行爲差別和 bug。前端

27.1.0 中的改變

在 27.1.0 中,Loader 的遺留問題已經大幅度的減小:實現 LoaderManager 的代碼行數只有以前的三分之一,也有不少的測試讓 Loader 在將來可以保持一個良好的狀態。android

全部這些都得意於架構組件。更確切的說是 ViewModel ( 在配置變化時保持狀態 ) 和 LiveData( 支持生命週期和回調 )。如今的 Loader 基於這些更高級別且充分測試的組件並從中受益,減小了不斷增長的性能損失,提升了 Loader 的可靠性和正確性。ios

行爲變化

這確實意味着一些行爲變動。git

首先,必須在主線程中調用 initLoaderrestartLoaderdestroyLoader。這提供了一些很是特別的保障在回調結束或開始時,例如在銷燬一個 loader 後,你將永遠不會拿到 onLoadFinished 的回調。github

注意事項:就技術來講,此次發佈以前,你能夠在其餘線程中作 loader 操做,可是 LoaderManager 再也不是線程安全的,會致使常常性的未定義行爲。後端

最重要的是,如今 onLoadFinished 和 LiveData Observers 同樣,老是在 onStartonStop 之間被調用,且不會在 onSaveInstanceState 以後。這樣你能夠在 onLoadFinished 中安全的作 Fragment Transactions 了。安全

我應當使用什麼,loader 後續如何?

像我在以前的博客 Lifecycle Aware Data Loading with Architecture Components 中提到的那樣,我強烈建議開發者使用 ViewModel+LiveData 的組合,我認爲他們絕對是一個更靈活更容易理解的系統。然而,若是你已經有基於 loader 的 APIs,這些改變應當會極大的提高組件之後的可依賴性和穩定性。架構

這許多的改變讓 Loader 變成一個功能,更加可選的依賴,不須要對 LifecycleOwner/ViewModelStoreOwner 作很底層的修改。app

嘗試下吧!

若是你正在使用 Loader,請儘快仔細查看並注意行爲變動,他們都在發佈事項 中。

注意事項:顯而易見,只有支持庫有這些更改。若是你使用的是 Android 框架的 Loader,請儘快切換到支持庫。由於框架的 Loader APIs 不會有錯誤修復或者計劃中的改進。


掘金翻譯計劃 是一個翻譯優質互聯網技術文章的社區,文章來源爲 掘金 上的英文分享文章。內容覆蓋 AndroidiOS前端後端區塊鏈產品設計人工智能 等領域,想要查看更多優質譯文請持續關注 掘金翻譯計劃官方微博知乎專欄

相關文章
相關標籤/搜索