之前的文章已经将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分支上最新的代码可能会比当前文章的示例代码稍微复杂点，提交记录里包含了每一步的迭代过程,可以顺藤摸瓜

dagger2从入门到放弃-为何放弃