目录

0. 前言
1. 依赖与注入
2. @Inject
3. @Module & @Provides
4. @Component
5. @Qualifier
6. Provider & Lazy
7. @Scope
8. 注入到Set和Map容器
9. Bind系列注解
10. dagger中依赖关系与继承关系
11. dagger.android

回顾

我们回顾一下目前为止的代码，我们通过ApplicationModule数据仓库，提供应用名数据，而Activity和Computer为了拿到这个数据，是通过定义@Subcomponent，使其与ApplicationComponent称为类似内部类组合的关系，从而可以使用到ApplicationModule中的内容。在Android系统中，Activity、Fragment都是由系统创建的，我们无法通过dagger管理其构造函数而仅能将注入语句插入到其生命周期中，并且每多出一个Activity，我们都要在ApplicationComponent中针对性的添加一个返回Subcomponent.Builder的方法，最严重的是，Activity在使用时需要知道使用的Component的具体类型，这违反了被注入类不应该知道注入细节这个原则

Sample需求

之前用的显示Computer信息那个项目太混乱了，我们这里重新创建一个应用模块，目前的需求如下：

• 该应用总共有两个主要Activity（OneActivity与TwoActivity），我们需要指定其标题、背景色和一段文本内容
• 这两个Activity有其各自的标题，但背景色需要统一，文本内容对应着一个全局单例的data类

就这两点需求，我们使用dagger来注入这些内容，其中统一的数据由ApplicationModule提供，而各自的数据由各自的Module提供：

使用dagger.android前的代码

我们先编写data类和那些@Module：

// data类相当简单，其内部由一个String和一个Int数据组成
data class VirtualData(private val name: String, private val num: Int)

// ActivityModule仅提供各自Activity自己的数据
@Module
class OneActivityModule {
    
    @Qualifier annotation class Title // 对于基本类型、String和一些共享性较强的数据类型，通常习惯定义别名，以免造成冲突以及增加语义性
    @[Provides Title] fun provideTitle() = "One Activity"
}

@Module
class TwoActivityModule {
    
    @Qualifier annotation class Title
    @[Provides Title] fun provideTitle() = "Two Activity"
}

// ApplicationModule中提供统一数据
@Module
class ApplicationModule {
    
    @Qualifier annotation class ActivityColor
    @[Provides ColorInt] fun provideActivityColor(@[ActivityColor ColorInt] color: Int) = color // @ColorInt是androidx中的注解，与dagger无关，这里仅为增强语义

    @Qualifier annotation class ActivityData
    @[Provides Singleton ActivityData] fun provideActivityData() = VirtualData(Date().toString(), Random.nextInt()) // Application生命周期即应用声明周期，就直接使用了@Singletion注解；为了证明其单例，data类中使用的为随机数据
}

通过@Module我们准备好了数据仓库，接下来我们通过@Inject在Activity中将需要注入的数据打上标记：

class OneActivity : AppCompatActivity() {
    
    @filed:[Inject OneActivityModule.Title] lateinit var title: String
    
    // kotlin对于基本数据类型的成员变量，其默认都是使用private+get/set方法，这里就必须使用set和setparam指定注解目标了（其实也可以使用@JvmField注解，不过会丢失get/set方法）
    @set:Inject
    @setparam:ApplicationModule.ActivityColor
    var color: Int = 0 // kotlin中的基本数据类型是不能用lateinit关键字的，使用字面量指定初始值时需要注意数据合法性
    
    @filed:[Inject ApplicationModule.ActivityData] lateinit var data: VirtualData
    /* ... */
}
// TwoActivity类似，这里就不贴出来了

编译后，通过@Inject我们得到了注入器（MembersInjector），接下来就是编写各种@Component桥接类，将数据与注入器结合起来了：

@Subcomponent(modules = [OneActivityModule::class]) // Activity所需的数据并不能通过此Component建立完整依赖关系，所以使用@Subcomponent等待父Component辅助使其依赖完整
interface OneActivityComponent {
    
    fun inject(target: OneActivity)

    @Subcomponent.Builder // 使用@Subcomponent必须要将自定义Component构造器 
    interface Builder {
    
        fun build(): OneActivityComponent
    }
}
// TwoActivityComponent类似，这里就不贴出来了

// 别忘了将两个子Component加入到父Component的module依赖的subcomponents中，以便父Component能够访问到子Component的Builder构造器，以及让子Component能够共享父Component的Module依赖
@Module(subcomponents = [OneActivityComponent::class, TwoActivityComponent::class])
class ApplicationModule {
     /* ... */ }

// ApplicationComponent主要提供ActivityComponent.Builder构造器，另外还需要将Module中的依赖补充完整
@Singleton // 别忘了ApplicationModule中的数据需要@Singleton作用域
@Component(modules = [ApplicationModule::class])
interface ApplicationComponent {
    
    fun newOneActivityComponentBuilder(): OneActivityComponent.Builder
    fun newTwoActivityComponentBuilder(): TwoActivityComponent.Builder

    @Component.Builder
    interface Builder {
    
        @BindsInstance // 使用@BindsInstance使得ApplicationModule中的@ActivityColor依赖完整
        fun activityColor(@[ApplicationModule.ActivityColor ColorInt] color: Int): Builder
        
        fun build(): ApplicationComponent
    }
}

编译通过后我们就可以尽情的使用dagger帮我们生成的Component类了：

// Application中准备好ApplicationComponent，以便Activity可以访问到
class Case11Application : Application() {
    
    private lateinit var _component: ApplicationComponent
    val component get() = _component

    override fun onCreate() {
    
        super.onCreate()

        _component = DaggerApplicationComponent
            .builder()
            .activityColor(Color.CYAN)
            .build()
    }
}

// Activity中通过访问Application拿到自己的Component.Builder
class OneActivity : AppCompatActivity() {
    
    /* ... */
    override fun onCreate(savedInstanceState: Bundle?) {
    
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_one)

        (application as Case11Application)
            .component
            .newOneActivityComponentBuilder()
            .build()
            .inject(this)

        setTitle(title)
        container.setBackgroundColor(color)
        content.text = data.toString()
    }
}

运行一下，代码逻辑完全没有问题，该是单例的就是单例，两个页面的标题也不同。虽然目的是达到了，但我们假设下如果随着需求的增多，有几十上百个这样的Activity时会怎样？

• 我们不得不将每一个Activity对应的Subomponent.Builder和ApplicationComponent中
• 每一个Activity都需要重复那么一长段代码，随着项目的迭代和新人的接手，这段代码将变得容易出错且难以理解
• 每个Activity都需要知道自己要调用什么样的方法才能得到自己的Component（比如上面的newOneActivityComponentBuilder()方法），但被注入对象不应该知道任何被注入的细节（最少知道原则）

为了解决这种冗余和重复代码，通常解决途径都是抽象和统一管理，于是乎dagger.android扩展库就由此产生了

使用dagger.android重构代码

官方将dagger.android的使用过程分成5步

第0步：引入扩展库

implementation 'com.google.dagger:dagger-android:2.22.1'
implementation 'com.google.dagger:dagger-android-support:2.22.1' // 适用于使用了support包的应用
kapt 'com.google.dagger:dagger-android-processor:2.22.1' // 别忘了kotlin中使用的是kapt

第一步：添加AndroidInjectionModule

AndroidInjectionModule是dagger.android框架提供的Module，官方要求我们将其添加到ApplicationComponent中：

@Singleton
@Component(modules = [ApplicationModule::class, AndroidInjectionModule::class])
interface ApplicationComponent {
     /* ... */ }

第二步：编写Subcomponent

也就是我们之前写的ActivityComponent，不过dagger.android要求其继承AndroidInjector接口，并且其内部需要有一个继承了AndroidInjector.Factory的@Subcomponent.Factory接口：

@Subcomponent(modules = [OneActivityModule::class])
interface OneActivityComponent: AndroidInjector<OneActivity> {
    
    @Subcomponent.Factory 
    interface Factory: AndroidInjector.Factory<OneActivity>
}
// TwoActivityComponent修改类似，不再贴出代码

这里对比之前有几点注意：

• AndroidInjector和AndroidInjector.Factory都需要指定泛型，类型为Component对应的被注入对象
• 无需在@Subcomponent接口中写inject()方法了
• Factory与Builder不能混用，因此这里删去@Subcomponent.Builder
• Factory中也不需要（且不能够）定义其他方法了

第三步：在Module中添加Subcomponent

这一步不仅要在ApplicationModule的@Module.subcomponents中添加上一步的@Subcomponent，还需要添加一个较为复杂的抽象方法；之前文章说过**@Module中不能同时有抽象方法和非静态方法**，所以这里我专门为这种@Subcomponent新建一个抽象@Module，并引入到ApplicationComponent中：

// 将Subcomponents转移到新的抽象Module上
@Module
class ApplicationModule {
     /* ... */ }

@Module(subcomponents = [OneActivityComponent::class, TwoActivityComponent::class])
abstract class ActivityFactoryModule {
    
    @[Binds IntoMap ClassKey(OneActivity::class)] // @Binds是一种用于决定抽象类型的依赖具体实现类型的方案，可以看下之前的文章有介绍到
    abstract fun bindOneActivityInjectorFactory(
        factory: OneActivityComponent.Factory
    ): AndroidInjector.Factory<*>

    @[Binds IntoMap ClassKey(TwoActivity::class)]
    abstract fun bindTwoActivityInjectorFactory(
        factory: TwoActivityComponent.Factory
    ): AndroidInjector.Factory<*>
}

// 在ApplicationComponent中引入上面新的抽象Module
@Singleton
@Component(modules = [ApplicationModule::class, AndroidInjectionModule::class, ActivityFactoryModule::class])
interface ApplicationComponent {
    
    // 这两个方法不再需要
//    fun newOneActivityComponentBuilder(): OneActivityComponent.Builder
//    fun newTwoActivityComponentBuilder(): TwoActivityComponent.Builder
	fun inject(target: Case11Application) // 我们需要对Application注入一些依赖
	/* ... */ 
}

第四步：使Application实现HasActivityInjector接口

class Case11Application : Application(), HasActivityInjector {
    
    @field:Inject
    lateinit var activityInjectorDispatcher: DispatchingAndroidInjector<Activity> // 新增dagger注入对象

    // 不再需要这个属性
//    private lateinit var _component: ApplicationComponent
//    val component get() = _component

    override fun onCreate() {
    
        super.onCreate()

        DaggerApplicationComponent
            .builder()
            .activityColor(Color.CYAN)
            .build()
        	.inject(this) // 需要注入
    }

    override fun activityInjector(): AndroidInjector<Activity> = activityInjectorDispatcher // HasActivityInjector接口要求实现的方法
}

第五步：在Activity中调用注入逻辑

// Activity.onCreate()方法
override fun onCreate(savedInstanceState: Bundle?) {
    
    /* ... */
    //        (application as Case11Application)
    //            .component
    //            .newTwoActivityComponentBuilder()
    //            .build()
    //            .inject(this)
    AndroidInjection.inject(this)
    /* ... */
}

没错非常精简且经典的一个方法

我们先不慌分析其实现源码，从修改结果上，我们看下解决了什么问题，有带来了什么问题：

• 不必再将@Subcomponent.Builder写入ApplicationComponent中了，取而代之的，我们需要以一种特定的方式将@Subcomponent.Factory写入ApplicationComponent依赖的@Module中（似乎更复杂了？）
• Activity中不必再重复那样的模板代码，无论在哪个Activity中都是相同的一句AndroidInjection.inject(this)
• 对于@Subcomponent和@Component的改动都是向着简化的方面进行

整体上来说代码确实简化了不少，最重要的是，Activity不再需要知道注入细节了！接下来就看看其源码实现怎样的

源码分析

我相信大部分人看到上面用到的dagger.android中的类名、接口名、@IntoMap等就能猜到个大概了，大致就是通过Map容器收集各Component.Factory，通过AndroidInjection访问到这个Map容器，之后进行Factory的派发与注入，从而实现Activity与Component桥接类的构建器解耦；同时通过接口和抽象类规范化使用流程，顺便起到简化编码的作用

下面我们从第一步开始慢慢分析

AndroidInjectionModule

最开始我们将AndroidInjectionModule写到ApplicationComponent的modules依赖中，其源码如下：

@Module
public abstract class AndroidInjectionModule {
    
  @Multibinds abstract Map<Class<?>, AndroidInjector.Factory<?>> classKeyedInjectorFactories();
  @Multibinds abstract Map<String, AndroidInjector.Factory<?>> stringKeyedInjectorFactories();
  private AndroidInjectionModule() {
    }
}

这是一个抽象@Module，其用@Multibinds提供了两种类型的Map数据，之前文章说过@Multibinds是为了解决在编码时不能确定容器内是否有元素被注入的问题，即为了依赖完整性可以提供大小为0的容器（不熟悉的可以翻下前面文章看下）

Q1：这两种类型的Map容器在哪里被使用到呢？

AndroidInjector & AndroidInjector.Factory

第二步中，我们修改了@Subcomponent注解的接口，使其继承自AndroidInjector，并且其内部的@Subcomponent.Factory注解的接口也需要继承自AndroidInjector.Factory，看下这两个的源码：

public interface AndroidInjector<T> {
    
  void inject(T instance);
  
  interface Factory<T> {
    
    AndroidInjector<T> create(@BindsInstance T instance);
  }

  @Deprecated // 在Factory出现前都是用的Builder，不过现在已经被弃用了
  abstract class Builder<T> implements AndroidInjector.Factory<T> {
    
    /* ... */
  }
}

难怪我们不用再在@Subcomponent中手写inject()方法，并且@Subcomponent.Factory中必须有的唯一一个方法，也被这个接口规范化了

Q2：虽然这样规范化大幅度简化了开发者的编码，但当我们需要自定义Builder对象时怎么办呢？（比如需要使用上@BindsInstance）

@Binds + @IntoMap + @ClassKey

在第三步中我们在新建的抽象@Module中用到了这三个注解，这三个注解也在之前文章都有介绍过。在dagger.android中将三者结合使用，不得不说学到了新姿势。我们重新看下我们编写的代码：

@[Binds IntoMap ClassKey(OneActivity::class)]
abstract fun bindOneActivityInjectorFactory(
    factory: OneActivityComponent.Factory
): AndroidInjector.Factory<*>

@Binds用于注入抽象类时指明具体的实现类；@IntoMap和@ClassKey用于指明Map容器注入，并且是Map<Class<*>, AndroidInjector.Factory<*>>这样的容器。这个容器是不是很熟悉？没错，就是AndroidInjectionModule中定义的Map容器，但其中还定义了一个Map<String, AndroidInjector.Factory<*>>容器，由此可得出上面的@ClassKey可以换成@StringKey

Q3：如果将@ClassKey换成@StringKey，应该怎样写？（自定义一个String吗？）

在第三步中我们还去掉了ApplicationComponent中fun newOneActivityComponentBuilder(): OneActivityComponent.Builder这样的代码，并不是说不需要@Subcomponent.Builder了，而是dagger.android将其注入到了上面的Map容器中去了

HasActivityInjector

第四步中我们让Application实现了HasActivityInjector接口，其定义如下：

public interface HasActivityInjector {
    
  AndroidInjector<Activity> activityInjector();
}

接口虽然简单，但问题变得更多了

Q4：HasActivityInjector有什么作用？为什么其要定义一个返回AndroidInjector<Activity>的方法？

DispatchingAndroidInjector

同样在第四步中，我们还在Application添加了如下代码：

@field:Inject 
lateinit var activityInjectorDispatcher: DispatchingAndroidInjector<Activity>

在变量上添加了@Inject代表这个变量是要需要被注入的，但我们在ApplicationComponent所依赖的modules中并没有看到提供这种数据的方法，怎么回事？赶快点开源码看看：

public final class DispatchingAndroidInjector<T> implements AndroidInjector<T> {
    
  /* ... */
  private final Map<String, Provider<AndroidInjector.Factory<?>>> injectorFactories; // 两个map合并后的map

  @Inject
  DispatchingAndroidInjector(
      Map<Class<?>, Provider<AndroidInjector.Factory<?>>> injectorFactoriesWithClassKeys,
      Map<String, Provider<AndroidInjector.Factory<?>>> injectorFactoriesWithStringKeys) {
    
    this.injectorFactories = merge(injectorFactoriesWithClassKeys, injectorFactoriesWithStringKeys);
  }
  
  private static <C, V> Map<String, Provider<AndroidInjector.Factory<?>>> merge(
      Map<Class<? extends C>, V> classKeyedMap, Map<String, V> stringKeyedMap) {
     /* 合并两个map，非重要部分 */ }

  @CanIgnoreReturnValue
  public boolean maybeInject(T instance) {
    
    Provider<AndroidInjector.Factory<?>> factoryProvider =
        injectorFactories.get(instance.getClass().getName()); // 寻找真正的AndroidInjector
    if (factoryProvider == null) {
    
      return false;
    }

    @SuppressWarnings("unchecked")
    AndroidInjector.Factory<T> factory = (AndroidInjector.Factory<T>) factoryProvider.get();
    try {
    
      AndroidInjector<T> injector =
          checkNotNull(factory.create(instance), "%s.create(I) should not return null.", factory.getClass());

      injector.inject(instance);
      return true;
    } catch (ClassCastException e) {
     /* 抛出异常，非重要部分 */ }
  }

  @Override
  public void inject(T instance) {
    
    boolean wasInjected = maybeInject(instance);
    if (!wasInjected) {
     /* 注入失败抛异常，非重要部分 */ }
  }
  /* 异常与报错等，非重要部分 */
}

首先我们注意DispatchingAndroidInjector的构造函数上有@Inject，说明dagger可以通过此构造函数提供对象，所以不用写到@Module内；@Inject注解的构造函数中的参数也是被看做为依赖，刚好与AndroidInjectionModule中@Multibinds定义的两个Map容器类型相同（注意这里用了dagger的Provider封装了AndroidInjector.Factory<?>，dagger对于Provider和Lazy都有自动转换依赖的能力），这里也就回答了Q1问题

其次我们发现DispatchingAndroidInjector实现了AndroidInjector接口，没错，就和我们修改@Subcomponent实现的接口是同一个，其inject()方法的实现是通过入参的全类名（即包含包名）去搜寻Map从而找到真正的AndroidInjector注入器，正如其名字一样，是一个对注入器的分发类。这里我们可以解答Q3问题：第三步中通过@StringKey规定注入Key值的话，其需要写上对应的全类名（这里注意下，使用@StringKey需要注意混淆问题）

AndroidInjection

最后，我们在Activity中通过AndroidInjection.inject(this)就能完成注入，这显然是一个静态方法，也能想到会调用到上面我们分析的DispatchingAndroidInjector，来看下源码是怎样调用的吧：

public final class AndroidInjection {
    
  private static final String TAG = "dagger.android";
    
  public static void inject(Activity activity) {
    
    checkNotNull(activity, "activity");
    Application application = activity.getApplication();
    if (!(application instanceof HasActivityInjector)) {
    
      throw new RuntimeException( /* ... */ );
    }

    AndroidInjector<Activity> activityInjector =
        ((HasActivityInjector) application).activityInjector();
    /* ... */
    activityInjector.inject(activity);
  }
    
  public static void inject(Fragment fragment) {
    
    checkNotNull(fragment, "fragment");
    HasFragmentInjector hasFragmentInjector = findHasFragmentInjector(fragment);
    /* ... */
    AndroidInjector<Fragment> fragmentInjector = hasFragmentInjector.fragmentInjector();
    /* ... */
    fragmentInjector.inject(fragment);
  }

  private static HasFragmentInjector findHasFragmentInjector(Fragment fragment) {
     // 寻找fragment的注入器
    Fragment parentFragment = fragment;
    while ((parentFragment = parentFragment.getParentFragment()) != null) {
     // 先从parentFragment中搜索
      if (parentFragment instanceof HasFragmentInjector) {
    
        return (HasFragmentInjector) parentFragment;
      }
    }
    Activity activity = fragment.getActivity();
    if (activity instanceof HasFragmentInjector) {
     // 再从宿主Activity中搜索
      return (HasFragmentInjector) activity;
    }
    if (activity.getApplication() instanceof HasFragmentInjector) {
     // 最后通过Application搜索
      return (HasFragmentInjector) activity.getApplication();
    }
    /* ... */
  }
    
  public static void inject(Service service) {
    
    /* ... */
    Application application = service.getApplication();
    if (!(application instanceof HasServiceInjector)) {
     /* ... */ }
    AndroidInjector<Service> serviceInjector = ((HasServiceInjector) application).serviceInjector();
    /* ... */
    serviceInjector.inject(service);
  }
    
  public static void inject(BroadcastReceiver broadcastReceiver, Context context) {
    
    /* ... */
    Application application = (Application) context.getApplicationContext();
    if (!(application instanceof HasBroadcastReceiverInjector)) {
     /* ... */ }
    AndroidInjector<BroadcastReceiver> broadcastReceiverInjector =
        ((HasBroadcastReceiverInjector) application).broadcastReceiverInjector();
    /* ... */
    broadcastReceiverInjector.inject(broadcastReceiver);
  }

  public static void inject(ContentProvider contentProvider) {
    
    /* ... */
    Application application = (Application) contentProvider.getContext().getApplicationContext();
    if (!(application instanceof HasContentProviderInjector)) {
     /* ... */ }
    AndroidInjector<ContentProvider> contentProviderInjector =
        ((HasContentProviderInjector) application).contentProviderInjector();
    /* ... */
    contentProviderInjector.inject(contentProvider);
  }

  private AndroidInjection() {
    }
}

final类、私有构造函数、全是静态方法，充分说明AndroidInjection就是一个工具类，其对inject()有5个重载方法，分别针对于Activity、Fragment、Service、BroadcastReceiver、ContentProvider进行注入，方法内的流程也都类似：首先判断Application是否有实现HasXXXInjector接口，然后通过接口指定的xxxInjector方法拿到第四步中提到的DispatchingAndroidInjector进行注入（这里回答了Q4问题）。这里说下几个特殊处理：

• 对于Fragment的注入，因为Fragment的灵活性，导致Fragment（嵌套）、Activity或Application都能作为其“容器”，自然这些都能管理Fragment的注入器；因此先通过parentFragment、再通过Activity、最后通过Application去寻找HasFragmentInjector。由此，如果一个Fragment没有“容器”，那么对其进行AndroidInjection.inject()注入是注定会失败的
• BroadcastReceiver是没有对应的Context的（但其onReceive()回调中会传入Context，这个Context会因广播是静态或动态、本地或非本地而不同，这里不深入探讨），因此对BroadcastReceiver进行AndroidInjection.inject()是要手动传入Context对象的

解答Q2

我们知道@Subcomponent.Factory中有且仅能有唯一一个方法代表@Subcomponent的工厂方法，但是dagger.android中AndroidInjector.Factory甚至已经将这个方法规范化了，因为dagger.android需要统一管理这些Factory，那么我们怎么做到像之前文章介绍@Component.Builder一样自定义这个Builder/工厂类呢？就目前来看，答案是不能，我们从两个角度来思考为什么不能：

• 为什么要自定义@Component.Builder构建器：
  • 自定义构建器需要为每一个@Component.modules、@Component.dependencies指定set系列方法，首先@Subcomponent是没有dependencies属性的，其次如果不使用@Component.Builderdagger也会创建默认的Builder，所以我认为这不是主要原因
  • 自定义构建器可以让dagger以外的容器管理其构建器本身，就像我们使用dagger.android之前一样，将ActivityComponent的构建器都交由ApplicationComponent管理
  • 自定义构建器还可以结合@BindsInstance使依赖树完整，有些依赖我们想在运行时决定，于是需要给构建器留出定义接口，以便能在运行时动态传入这些参数
• 为什么要使用dagger.android：
  • 使用dagger.android框架一方面就是为了解决上述第二点带来的问题，我们不想每一个Activity中都有着意义不明、仅有细微差别的代码
  • 还记得我们分析使用dagger.android前的代码吗？被注入对象不应该知道任何被注入的细节，这是依赖注入的核心原则。回想下我们使用@BindsInstance时，对于被注入对象，不仅需要知道自己对应的Component桥接类类型，还得调用@BindsInstance注解的方法以绑定实例，这样甚至就和使用dagger框架前的代码一样，实在是知道得太多了

那么如果真的遇到这种需求时怎么办呢？（比如@Module所提供的依赖就是不完整的）其实解决方案有很多，要么直接写死在@Module中或者将判断逻辑迁移到@Module中，要么就将这种数据交由“容器”保管（就像上面例子中的@ActivityColor一样），或者对于可能出现的数据使用dagger.Lazy注入以免无用内存的产生，再不然就不要使用dagger框架了，正所谓好钢要用在刀刃上，不适合依赖注入的数据为何还要强行让其配合依赖注入框架呢？

流程小结

源码分析完后是不是豁然开朗了？其实和我们最初想法即猜测是吻合的，Activity的子Subomponent的构建器还是由Application管理着的，不过dagger.android将这些构建器以全类名作为Key值其注入到Map容器中，之后Activity调用注入时，dagger.android就从Map容器中通过类名查找到对应的构建器，构建出Component调用其注入方法完成注入，这样Activity就可以实现完全不知道注入细节的依赖注入了

其实就是通过AndroidInjection实现解耦，至于解耦的目的，也是本文一直强调的被注入对象不应该知道任何被注入的细节

接下来就是dagger.android为了极致简化开发者编写代码而推出的各种辅助注解和辅助类了

@ContributesAndroidInjector

在第二步和第三步中，我们将Activity的@Subcomponent进行了一番改造，并在ApplicationComponent依赖的@Component.modules中添加了@Binds @IntoMap @ClassKey ...这种代码，其实对于大多数Activity来说都是这样的模板代码。因此dagger.android针对性的提供了@ContributesAndroidInjector注解，这个注解会辅助生成一个@Subcomponent以及一个使用此@Subcomponent的抽象@Module，我们改动一下ActivityFactoryModule：

@Module(subcomponents = [/*OneActivityComponent::class, */TwoActivityComponent::class]) // 不再需要手动编写@Subcomponent
abstract class ActivityFactoryModule {
    
    @ContributesAndroidInjector(modules = [OneActivityModule::class]) // @ContributesAndroidInjector一定是在@Module中注解一个无参方法，其modules属性和我们手写的@Subcomponent.modules等价
    abstract fun contributeOneActivityInjector(): OneActivity // 这个方法的返回值表示被@Subcomponent桥接的被注入对象

//    @[Binds IntoMap ClassKey(OneActivity::class)] // 不再需要手动编写这个函数了
//    abstract fun bindOneActivityInjectorFactory(
//        factory: OneActivityComponent.Factory
//    ): AndroidInjector.Factory<*>
}

编译一下，你会发现由@ContributesAndroidInjector生成了一个新的辅助类：

@Module(subcomponents = ActivityFactoryModule_ContributeOneActivityInjector.OneActivitySubcomponent.class) // 这个@Module可以被认为是默认添加到了ActivityFactoryModule的@Module.includes中
public abstract class ActivityFactoryModule_ContributeOneActivityInjector {
    
  private ActivityFactoryModule_ContributeOneActivityInjector() {
    }

  @Binds
  @IntoMap
  @ClassKey(OneActivity.class)
  abstract AndroidInjector.Factory<?> bindAndroidInjectorFactory(
      OneActivitySubcomponent.Factory builder);

  @Subcomponent(modules = OneActivityModule.class)
  public interface OneActivitySubcomponent extends AndroidInjector<OneActivity> {
    
    @Subcomponent.Factory
    interface Factory extends AndroidInjector.Factory<OneActivity> {
    }
  }
}

很直接，就和我们手写的一模一样。当然，@ContributesAndroidInjector注解还能使用在服务、广播等上，由其注解的方法返回值决定生成的@Subcomponent的桥接对象

DaggerActivity & DaggerAppCompatActivity

你有没有想过，我们甚至连AndroidInjection.inject(this)这一句也不用手写？没错，只需编写一个BaseActivity在其onCreate()加入这句，其他Activity继承自BaseActivity就好了。dagger.android也想到了这一点，于是提供了DaggerActivity/DaggerAppCompoatActivity，修改我们的Activity如下：

class OneActivity : DaggerAppCompatActivity() {
    
    /* ... */
    override fun onCreate(savedInstanceState: Bundle?) {
    
        /* ... */
//        AndroidInjection.inject(this) // 这句已经不需要了
    }
}

来看下其源码（这里以DaggerAppCompatActivity举例，DaggerActivity类似）：

public abstract class DaggerAppCompatActivity extends AppCompatActivity
    implements HasFragmentInjector, HasSupportFragmentInjector {
    

  @Inject DispatchingAndroidInjector<Fragment> supportFragmentInjector;
  @Inject DispatchingAndroidInjector<android.app.Fragment> frameworkFragmentInjector;

  @Override
  protected void onCreate(@Nullable Bundle savedInstanceState) {
    
    AndroidInjection.inject(this); // dagger推荐依赖注入在生命周期中应该越早越好
    super.onCreate(savedInstanceState);
  }

  @Override
  public AndroidInjector<Fragment> supportFragmentInjector() {
    
    return supportFragmentInjector;
  }

  @Override
  public AndroidInjector<android.app.Fragment> fragmentInjector() {
    
    return frameworkFragmentInjector;
  }
}

没错，DaggerAppCompatActivity不仅为你写好了AndroidInjection.inject(this)，还贴心的为你将HasFragmentInjector/HasSupportFragmentInjector接口实现好了，极大方便了Fragment的注入。类似的，dagger.android还提供了DaggerBroadcastReceiver、DaggerContentProvider、DaggerDialogFragment、DaggerFragment、DaggerIntentService和DaggerService以在不同场景使用，任君挑选

DaggerApplication

和DaggerActivity目的一样，dagger.android自然也提供了DaggerApplication，修改我们的Application：

@Singleton
@Component(modules = [ApplicationModule::class, AndroidInjectionModule::class, ActivityFactoryModule::class])
interface ApplicationComponent : AndroidInjector<Case11Application> {
     // 需要继承AndroidInjector接口
//    fun inject(target: Case11Application) // 于是省去了inject()方法
    /* ... */
}

class Case11Application : DaggerApplication() {
     // 继承自DaggerApplication，于是我们只用实现applicationInjector将ApplicationComponent构建好后返回即可
    override fun applicationInjector(): AndroidInjector<out DaggerApplication> =
        DaggerApplicationComponent
            .builder()
            .activityColor(Color.CYAN)
            .build()
}

来来来，看下你猜的DaggerApplication源码对不对：

@Beta
public abstract class DaggerApplication extends Application
    implements HasActivityInjector, HasFragmentInjector, HasServiceInjector, HasBroadcastReceiverInjector, HasContentProviderInjector {
     // 实现了一系列的接口，以支持各种场景下的注入
  // 自然这些派发器也是@Inject进来的
  @Inject DispatchingAndroidInjector<Activity> activityInjector;
  @Inject DispatchingAndroidInjector<BroadcastReceiver> broadcastReceiverInjector;
  @Inject DispatchingAndroidInjector<Fragment> fragmentInjector;
  @Inject DispatchingAndroidInjector<Service> serviceInjector;
  @Inject DispatchingAndroidInjector<ContentProvider> contentProviderInjector;

  @Override
  public void onCreate() {
    
    super.onCreate();
    injectIfNecessary();
    
  @ForOverride
  protected abstract AndroidInjector<? extends DaggerApplication> applicationInjector(); // 我们需要重写的那个方法

  private void injectIfNecessary() {
    
  	/* 去掉其他关于同步的部分，关键是下面这两句，在Application.onCreate()时进行注入 */
    AndroidInjector<DaggerApplication> applicationInjector = (AndroidInjector<DaggerApplication>) applicationInjector();
    applicationInjector.inject(this);
  }
  /* 剩下都是一些实现接口的方法，比如activityInjector()等 */
}

总结

至此，总算把dagger所有内容都完全详细的介绍了一遍，从最开始手写依赖注入，到引入dagger实现依赖注入，再到最后使用dagger.android完成在Android中的依赖注入，我也从最开始看着dagger就头疼放弃了500遍后，终于下定决心自己深入学习一趟，边学边编写此系列，陆陆续续将近半个月，总算是画了个句号，也是对dagger框架和依赖注入有着更深的认识了

本系列肯定有各种不尽人意的地方，特别严重的就是前面大部分文章都错误理解了@Module的定位，不过个人认为作为学习笔记已经很够看了，这方面还请海涵

参考文章

其实最开始看到dagger已经是很久之前了，写本系列时也忘记刻意记下参考文章orz，我只能翻查浏览器记录希望能补全吧：

Dagger 官方文档 - 最不推荐看的文档了= =恕我直言，这个官方指引对新手来说就是一坨[哔——]
Dagger2 最清晰的使用教程 - 看得最久的一篇文章，不过我看的感觉和文章开头差不多，也是脑浆炸裂
Dagger 2 完全解析（一），Dagger 2 的基本使用与原理 - 这个系列还不错，能够理解什么是依赖关系，什么是继承关系，最重要的是最后一篇是用kotlin写的，好评如潮
广播onReceive()方法的context类型探究 - 关于广播接收器中的Context究竟是什么
Dagger2 依赖的接力游戏（六）：Bind、BindInstance、Multibinds注解 - 主要是学习了Bind系列注解，讲得蛮好的
Dagger 2 multibindings with Kotlin - dagger在kotlin中出现泛型问题？先试试@JvmSuppressWildcards吧
DI框架Dagger2系统性学习-不容错过的干货 - 官方文档的翻译，没怎么看
Dagger2 进阶使用 - 很多dagger的非基础使用，使用kotlin简直满分
深入Dagger:自定义AutoValue - 介绍了Google的AutoValue框架，以及如何与dagger混用