之前的文章已经将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就是要降低代码耦合度，否则就不要用，即使要用也限定在自己可以掌控的范围内使用（其实大公司能自己掌控的东西并不多），不要痴心妄想可以推进让全组广泛使用
相关文章
dagger2从入门到放弃-概念
dagger2从入门到放弃-最基础的用法介绍
dagger2从入门到放弃-Component的继承体系、局部单例
dagger2从入门到放弃-ActivityMultibindings
dagger2从入门到放弃-dagger.android
dagger2从入门到放弃-其他用法
dagger2从入门到放弃-多模块项目下dagger的使用
dagger2从入门到放弃-为何放弃
示例代码
DaggerInAction
欢迎star
master分支上最新的代码可能会比当前文章的示例代码稍微复杂点，提交记录里包含了每一步的迭代过程,可以顺藤摸瓜
