dagger2從入門到放棄-為何放棄
之前的文章已經將dagger2的用法大致介紹了一遍,但是最終沒有真正在專案中用起來,下面說明下原因
技術原因
專案規模
個人所在公司的專案雖然程式碼量很大,但是實際上業務程式碼的層級並不多,而且模組的複用度也不算太高
這種情況下其實依賴注入的思想用的都不多,dagger使用帶來的便利有限,比較關鍵的任務其實是先去細緻的梳理業務,分解功能模組這樣的工程上解耦,而不是先側重工具使用
錯誤提示
錯誤: 找不到符號 符號:類 DaggerXXXComponent 位置: 程式包 ...
dagger作為編譯期的靜態依賴注入框架,大部分時候的編譯錯誤都可以直接定位問題,但是偶爾的類似上面的錯誤提示就讓人非常頭疼
沒什麼有效資訊,出錯原因也特別多,出錯的地方可能跟XXXComponent也隔著十萬八千里
靜態依賴注入的侷限
沒有像spring根據一個字串等動態資料生成一個物件的能力,不過好像android上也沒有類似功能的框架
通用性與android的特殊化需求
dagger是一個通用的依賴注入框架,它的目的是程式碼模組解耦而不是簡化android中一些常用程式碼
所以android中view、點選事件、資源的繫結這些比較特殊化的需求都沒有實現
dagger.android帶來的限制
dagger.android遮蔽了要注入的元件的Subcomponet,導致繼承體系終止了
不過在ContributesAndroidInjector的modules中指定的Module中還可以繼續使用ContributesAndroidInjector,使得Activity->Fragment這樣常規的Component繼承方式還是可以實現
@Module(subcomponents = MvvmComponent.class) public abstract class MvvmLibActivitiesModule { @ContributesAndroidInjector(modules = {MvvmLibFragmentModule.class}) abstract MeiziTimerActivity bindFragmentActivity(); } @Module(subcomponents = MvvmComponent.class) public abstract class MvvmLibFragmentModule { @ContributesAndroidInjector(modules = FragmentModule.class) abstract MeiziTimerFragment bindFragmentActivityFragment(); }
非技術原因
以上列舉的原因主要是想說明,dagger使用即使單純從技術上來看都是有利有弊的,往往使用造成的時間投入並不能帶來期望的收益
而更難解決的問題其實是人的問題,如何推進新技術的普遍使用;如何解決因為使用新技術造成的問題;在公司的層面上如何衡量學習使用新技術的成本與收益;如何解決新技術造成招人難或者新手上手難的問題 。這些其實都比技術問題難解決的多
建議
如果是個人專案,dagger可以毫不猶豫的使用,即使坑的自己想罵娘其實也只是耗費一些時間而已,學啥不需要費點工夫呢
如果是創業公司從0開始的專案,要用得自己先有把握能解決好使用過程中的坑,如果你在建立專案的時候還猶豫要不要用dagger,那還是先等等再說
如果是一個成熟的公司專案,除非kpi就是要降低程式碼耦合度,否則就不要用,即使要用也限定在自己可以掌控的範圍內使用(其實大公司能自己掌控的東西並不多),不要痴心妄想可以推進讓全組廣泛使用