系列文章第一篇：
http://www.jianshu.com/p/33b739bd721a
概述
上一期我们已经对Dagger的基本概念以及结构做了介绍。那么现在我们将对Dagger作深入探究，了解它究竟是怎么实现自动注入的，它在我们引用注解后做了哪些工作。探究
2.1 思路
在古代，人们选择靠近水源的地点作为聚居地，很大一部分原因是我们需要水来灌溉庄稼。我们可以把步骤大概简化为：水源（提供水）——水车(获取水)——导管(引流)——农田。其实Dagger注入也是遵循这个过程，下面我们按照这个思路对dagger进行剖析。
上篇我们说过，Module是专门提供依赖的，可以看作水源；Component是注入器，我们可以把它看成水车；Inject是被注入的对象，是农田和庄稼。
2.2 Module
在探究Module之前我们首先了解一下Module类的写法:
@Module
public class ApplicationModule {
private final AndroidApplication mApplication;
private final DaoSession mDaoSession;
private final RxBus mRxBus;
public ApplicationModule(AndroidApplication application, DaoSession daoSession, RxBus rxBus) {
mApplication = application;
mDaoSession = daoSession;
mRxBus = rxBus;
}
@Provides
@Singleton
Context provideApplicationContext() {
return mApplication.getApplication();
}
@Provides
@Singleton
RxBus provideRxBus() {
return mRxBus;
}
@Provides
@Singleton
DaoSession provideDaoSession() {
return mDaoSession;
}
}
@Providers表示此处会提供依赖，而@Singleton表示提供的依赖对象将是单例形式。
好的，我们现在已经有了依赖提供者，就相当于有了一个农民伯伯为庄稼找到了水源，现在我们需要想办法将水源导出来，注入到种庄稼的田地里，也就是我们需要有一个踩水车，而我们的Component则是负责踩水车这个角色。
2.3 Component
首先我们看下Component类
@Singleton
@Component(modules = ApplicationModule.class)
public interface ApplicationComponent {
Context getContext();
RxBus getRxBus();
DaoSession getDaoSession();
}
我们这里定义的是ApplicationComponent，我们在自己的Application类中实例化：
public App extends Applicaion{
private static ApplicationComponent sAppComponent;
...//省略
@Override
public void onCreate() {
super.onCreate();
initConfig();
}
...//省略
private void initInjector() {
sAppComponent = DaggerApplicationComponent.builder()
.applicationModule(new ApplicationModule(this, mDaoSession, mRxBus))
.build();
}
...//省略
}
这里Dagger会根据相应的注解自动使用apt在/app/build/generated/apt/debug/中生成对应的DaggerApplicationComponent类。我们观察一下该类，也就是看下水车的结构。
public final class DaggerApplicationComponent implements ApplicationComponent {
private Provider<Context> provideApplicationContextProvider;
private Provider<RxBus> provideRxBusProvider;
private Provider<DaoSession> provideDaoSessionProvider;
private DaggerApplicationComponent(Builder builder) {
assert builder != null;
initialize(builder);
}
public static Builder builder() {
return new Builder();
}
@SuppressWarnings("unchecked")
private void initialize(final Builder builder) {
this.provideApplicationContextProvider =
DoubleCheck.provider(
ApplicationModule_ProvideApplicationContextFactory.create(builder.applicationModule));
this.provideRxBusProvider =
DoubleCheck.provider(
ApplicationModule_ProvideRxBusFactory.create(builder.applicationModule));
this.provideDaoSessionProvider =
DoubleCheck.provider(
ApplicationModule_ProvideDaoSessionFactory.create(builder.applicationModule));
}
@Override
public Context getContext() {
return provideApplicationContextProvider.get();
}
@Override
public RxBus getRxBus() {
return provideRxBusProvider.get();
}
@Override
public DaoSession getDaoSession() {
return provideDaoSessionProvider.get();
}
public static final class Builder {
private ApplicationModule applicationModule;
private Builder() {}
public ApplicationComponent build() {
if (applicationModule == null) {
throw new IllegalStateException(
ApplicationModule.class.getCanonicalName() + " must be set");
}
return new DaggerApplicationComponent(this);
}
public Builder applicationModule(ApplicationModule applicationModule) {
this.applicationModule = Preconditions.checkNotNull(applicationModule);
return this;
}
}
}
代码不多，但是比较混杂，我们慢慢撸：
我们观察到Dagger使用在生成相应的DaggerApplicationComponent 类时采用了建造者模式，其构造方法私有意味着并不能直接new出来，而是需要通过建造者类Builder。而Builder类是DaggerApplicationComponent 中的公共静态内部类，其构造方法中会传入ApplicationModule 并持有它。
那么这样就清楚了，首先我们通过建造者类将ApplicationModule 传入并持有引用，其次将建造者类作为DaggerApplicationComponent 构造方法的参数传入DaggerApplicationComponent 类中，这样DaggerApplicationComponent 就持有了ApplicationModule ，也就是持有了依赖提供者。这时候我们可以理解为我们成功建造了水车，并且接入了水源。
现在我们仔细分析一下DaggerApplicationComponent 类。
首先Dagger获取被@Providers注解的方法的返回值，使用Provider结构包裹返回值，生成相应的Provider的私有字段，然后在initialize方法中，拿到建造者类Builder中持有的applicationModule。
于此同时在/app/build/generated/apt/debug/生成被@Providers注解方法的返回值的对应的工厂类，例如ApplicationModule_ProvideApplicationContextFactory。
我们顺着工厂类看下去：
public final class ApplicationModule_ProvideApplicationContextFactory implements Factory<Context> {
private final ApplicationModule module;
public ApplicationModule_ProvideApplicationContextFactory(ApplicationModule module) {
assert module != null;
this.module = module;
}
@Override
public Context get() {
return Preconditions.checkNotNull(
module.provideApplicationContext(),
"Cannot return null from a non-@Nullable @Provides method");
}
public static Factory<Context> create(ApplicationModule module) {
return new ApplicationModule_ProvideApplicationContextFactory(module);
}
}
我们看到工厂类实现了Factory<T>接口，其实在深入一层的话，我们会发现Factory是继承自Provider接口的，所以Factory实际上也是提供者,使用Factory的原因在于利于更好的拓展性。在Factory中传入相应的module，并在get方法中拿取到被@Provider注解的方法返回的具体的对象(详见：module.provideApplicationContext())。
我们继续返回上层的DaggerApplicationComponent 的initialize方法。我们发现从工厂类中获取的对象直接就赋值给了相应的Provider字段。
至此，DaggerApplicationComponent 实现了获取ApplicationModule中被@Provider注解的相应方法的返回对象并使用Provider持有该对象DaggerApplicationComponent 重写ApplicationComponent 的方法中直接从Provider字段中get相应的对象就行。就相当于我们的水车已经顺利的水源取水了。
3.总结
总而言之，Dagger根据@Provider直接生成相应的工厂类和DaggerApplicationComponent 类，DaggerApplicationComponent 类持有Module和相应的工厂类字段，实现了从水源取水这一过程。
第二篇比较枯燥，全是代码的解读和分析。下一篇我们将关注@Inject是怎样实现注入的。
