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就是要降低程式碼耦合度，否則就不要用，即使要用也限定在自己可以掌控的範圍內使用（其實大公司能自己掌控的東西並不多），不要痴心妄想可以推進讓全組廣泛使用