参考资料:
Google Developer: Dagger2 - A New Type of dependency injection
Dagger 2. Part II. Custom scopes, Component dependencies, Subcomponents
写在前面
为什么要学习 dagger2 呢？
回答这个问题，首先要知道dagger2是什么，它有什么优势，能解决什么问题？
如果之前没有接触过依赖注入概念的话，Dagger2学起来会有不少知识点要填，
甚至有很多现有的开发思维方式都要抛开，
因为在Android开发中，大部分人已经习惯了简单粗暴的 MVC/MVP ，或者 MVVM 框架，
而这些框架中最基本的思维方式就是接口编程， View - Presenter - Model 之间以约定好的 Interface 来调用，整个应用被切割为 View - Presenter - Model 三个层次，或者 View - ViewModel - Model 这种 MVVM 架构。
这种代码架构方式已经验证了它的高效，低耦合，易扩展性，任何业务逻辑的修改，都只需要修改具体的实现方法，因为不需要修改 Interface，MVP 之间的调用不需要做任何调整
但是仍然存在一些问题，比如需要手动写大量的工厂代码，替换测试代码不够方便，还有像 Presenter的实例化需要插入到UI代码中，
这意味着当Presenter的构造方法发生更改的时候需要修改到UI的代码。
Dagger2可以解决这些问题。
简单介绍依赖注入的历史
移动端的依赖注入应用不多，耳熟能详的像ButterKnife，用最多的是在UI的绑定上。为什么应用不多呢？
因为依赖注入框架本身比移动应用本身更庞大更复杂
Spring -> Guice -> Dagger -> Dagger2
这个箭头的方向比较粗略的描述了依赖注入的发展，
依赖注入， Dependencies Injection（下文用 DI 表示）主要是在服务端开发上应用，因为服务端的业务逻辑复杂，需要切割为各个不同的子模块，互相之间尽可能低的耦合，才能适应快速的开发需求。像 Spring 和 Guice，在服务端开发上非常普遍的应用，但是能不能用他们来应用在移动端开发呢？
答案是不能的，因为他们引入的问题比解决的问题更多。像Spring，需要用xml来描述各个模块之间的依赖关系，意味着移动开发者还要维护一份依赖表，这对移动端开发者来说业务量反而增加了，而且不熟悉的人不知道这都是些什么，增加了大量的维护成本。
到了Dagger1的时候，发展到了用简单的java接口就可以描述模块之间的依赖关系，大大提高了开发效率。然而Dagger1有个问题，它是在运行时注入的，意味着会导致运行效率低下，在服务端开发的场景中，很可能会导致CPU和内存占用大幅度提高，这也是不允许的。
于是Dagger2出来了，它在Dagger1的基础上，使用apt在编译过程中自动生成工厂代码，实现注入，因为它是编译期注入，因此性能提高了很多。
Google的Dagger2开发负责人给的数据，从Dagger1升级到Dagger2后，服务端的运行开销得到了13%的减少，这是相当可观的。
Android-Architecture
来到了2017年，Google的I/O大会上推出了两个东西，一个是Kotlin，其实Kotlin早已推出，只是Google并没有把它放到首位，直到今年才把他作为Android开发的首推语言。另外一个是Android-Architecture，填补了从Android推出到现在一直以来遗留下来的空白，就是Android App框架的问题。
不管是MVC/MVP/MVVM，其实都没有解决的一个问题是，如何在业务层比如Presenter层，去监控Activity的生命周期。
举个例子，当我们的Presenter去load data的时候，可能处于子线程，当加载完成，返回到主线程的时候，我们并不知道Activity/Fragment处于哪个生命周期。
另外，Android应用的数据维护。像一个健壮的app经常需要处理d 横竖屏转换，语言切换问题，目前很多应用粗暴的只允许竖屏，在语言切换回来的时候直接重新初始化，然而这并不好。虽然用onSaveInstanceState也能解决，但是UI层额外的代码会显得冗余。
Android-Architecture解决了这些，而且它把App的层次划分的很明确，在这种前提下，用Dagger2就显得理所当然了。
Dagger2的优点
· 全局对象实例的简单访问方式
· 复杂的依赖关系只需要简单的配
· 让单元测试和集成测试更加方便
· 作用域实例（Scoped instances）
以上这些优点在后面几篇分析里会逐步体会
