建設銀行征信中心官方網(wǎng)站,wordpress 新建文件權限,wordpress側邊欄顯示單個分類列表,制作網(wǎng)頁的軟件它是理性、技術導向且務實的。 文章的策略不是“為了用框架而用框架”#xff0c;而是從痛點出發(fā)#xff08;手動寫 Factory 的繁瑣、SavedStateHandle 的難搞、Compose 的未來#xff09;#xff0c;最后通過對比得出結論。 Android 架構進化之路#xff1a;為何在 Retro…它是理性、技術導向且務實的。文章的策略不是“為了用框架而用框架”而是從痛點出發(fā)手動寫 Factory 的繁瑣、SavedStateHandle 的難搞、Compose 的未來最后通過對比得出結論。Android 架構進化之路為何在 Retrofit 協(xié)程重構中我們需要引入 Hilt背景目前我們的項目正在進行現(xiàn)代化的架構升級網(wǎng)絡層從 RxJava 遷移到Kotlin CoroutinesRetrofit。數(shù)據(jù)流使用Flow和密封類 (NetworkResult) 替代回調實現(xiàn)更安全的單向數(shù)據(jù)流。UI層逐步引入Jetpack Compose同時兼容現(xiàn)有的 View/XML。在重構交易模塊Trade Module時我發(fā)現(xiàn)了一個繞不開的架構痛點ViewModel 的依賴注入問題。為了解決這個問題并為未來的 Compose 鋪路我建議在部分新模塊中引入Hilt。本文將通過實際代碼對比解釋為什么要這么做以及它能為團隊帶來什么實際收益。痛點手動管理的“依賴地獄”在新的架構中我們遵循 MVVM 原則。一個標準的TradeViewModel通常需要兩個依賴TradeApiService用于網(wǎng)絡請求我們需要注入它。SavedStateHandle用于在進程被殺后恢復數(shù)據(jù)系統(tǒng)提供用于獲取 Intent 參數(shù)。? 如果不使用 Hilt現(xiàn)狀由于SavedStateHandle是系統(tǒng)創(chuàng)建的而ApiService是我們要傳入的手動把這兩個東西組合進 ViewModel 的構造函數(shù)非常痛苦。我們必須不得不為每一個 ViewModel 手動寫一個Factory類1. 繁瑣的 ViewModelFactory// 每一個 ViewModel 都要寫這樣一個 Factory全是樣板代碼classTradeViewModelFactory(privatevalapiService:TradeApiService,owner:SavedStateRegistryOwner,defaultArgs:Bundle?null):AbstractSavedStateViewModelFactory(owner,defaultArgs){overridefunT:ViewModelcreate(key:String,modelClass:ClassT,handle:SavedStateHandle):T{// 我們必須手動組裝系統(tǒng)給的 handle 我們給的 apiServiceif(modelClass.isAssignableFrom(TradeViewModel::class.java)){Suppress(UNCHECKED_CAST)returnTradeViewModel(handle,apiService)asT}throwIllegalArgumentException(Unknown ViewModel class)}}2. 在 Activity 中尷尬的調用// 我們必須手動獲取 Retrofit 實例手動創(chuàng)建 Repository再手動 new FactoryvalapiRetrofitClient.getInstance().create(TradeApiService::class.java)valfactoryTradeViewModelFactory(api,this,intent.extras)// 終于拿到了 ViewModelvalviewModelViewModelProvider(this,factory)[TradeViewModel::class.java]問題總結代碼冗余每增加一個頁面就得寫一個 Factory維護成本高。容易出錯如果 ViewModel 加了一個參數(shù)比如UserHelper需要修改 Factory 和所有調用這個 Factory 的 Activity。生命周期風險如果RetrofitClient不是單例或者我們需要傳遞一個Activity級別的對象手動管理生命周期很容易導致內存泄漏。解決方案引入 Hilt 后的世界Hilt 是 Google 官方推薦的依賴注入庫它是專門為 Android 場景優(yōu)化的基于 Dagger 但去除了復雜性。? 使用 Hilt 之后1. ViewModel 極其清爽刪掉 Factory 類直接在構造函數(shù)上加注解。Hilt 會自動處理SavedStateHandle和ApiService的混合注入。HiltViewModelclassTradeViewModelInjectconstructor(privatevalsavedStateHandle:SavedStateHandle,// Hilt 自動處理系統(tǒng)參數(shù)privatevalapiService:TradeApiService// Hilt 自動從容器中注入):ViewModel(){// ... 業(yè)務邏輯}2. Activity 中零樣板代碼AndroidEntryPointclassTradeActivity:AppCompatActivity(){// 就像魔法一樣直接獲取所有依賴自動注入完成privatevalviewModel:TradeViewModelbyviewModels()overridefunonCreate(savedInstanceState:Bundle?){super.onCreate(savedInstanceState)// ...}}收益總結消滅樣板代碼徹底刪除了所有的ViewModelFactory。關注點分離Activity 不需要知道 ViewModel 依賴了什么只需要使用它。自動生命周期管理Hilt 自動處理單例Singleton或跟隨 Activity 銷毀的對象杜絕內存泄漏。核心收益分析1. 解決SavedStateHandle的注入難題這是最直接的收益。在現(xiàn)代 Android 開發(fā)中SavedStateHandle是標準組件。手動混合注入它和其他業(yè)務 Service 非常反人類。Hilt 對此有原生支持能夠極大地提升開發(fā)體驗。2. 為 Jetpack Compose 鋪路團隊規(guī)劃未來會引入 Compose。在 Compose 中UI 是一棵函數(shù)樹。沒有 Hilt我們需要把 ViewModel 或者 Repository 從最頂層的Screen一層層傳到最底層的Button即 Prop Drilling代碼非常丑陋。有了 Hilt我們可以在任何層級的 Composable 函數(shù)中通過hiltViewModel()直接獲取 ViewModel這是 Compose 開發(fā)的最佳實踐。3. 漸進式遷移不影響舊代碼引入 Hilt不需要重構現(xiàn)有的 Java 代碼或舊模塊。Hilt 可以和手動注入共存。我們可以在新的“交易模塊”中試用 Hilt。舊的 Activity 和 Java 邏輯保持原樣互不干擾。常見顧慮解答Q: 引入 Hilt 會不會讓代碼變得很復雜A:不會反而更簡單了。以前的 Dagger2 確實復雜但 Hilt 隱藏了 Component/Module 的組裝邏輯。對于業(yè)務開發(fā)來說90% 的場景只需要HiltViewModel、Inject和AndroidEntryPoint三個注解。Q: 會影響編譯速度嗎A:Hilt 使用 KAPT/KSP 處理注解會有輕微的編譯時間增加通常幾秒但換來的是運行時性能的提升沒有反射和代碼量的顯著減少。對于我們的項目規(guī)模這點損耗完全可以接受。結論引入 Hilt 不是為了追求新技術而是為了解決ViewModel 工廠代碼冗余和依賴管理混亂的實際問題。特別是在結合Retrofit Coroutines Sealed Classes的新架構下Hilt 補全了最后一塊拼圖讓我們能以更少的代碼寫出更健壯的邏輯。建議方案在當前的“交易模塊”重構分支中試行 Hilt驗證其對開發(fā)效率的提升若效果良好再逐步推廣。