Dagger依赖注入详解(二)

2017-04-16 本文已影响285人 tinyfight

系列文章第一篇：
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是怎样实现注入的。

Dagger依赖注入详解(二)

猜你喜欢

热点阅读