依赖注入与Dagger2简介

1. 什么是依赖注入？

在软件设计中，我们会根据不同的职责将代码划分为不同的类。而不同类之间又会相互组合，形成依赖关系。例如在 Android 应用的登录流程时，LoginActivity 依赖于 LoginViewModel，而又依赖于 UserRepository。

—— 引用自 developer.android.google.cn/training/de… —— Android Developers

LoginActivity 类获得依赖对象的最直接方式是在类内部构造依赖对象，例如：

val retrofit = Retrofit.Builder()
    .baseUrl("https://example.com")
    .build()
    .create(LoginService::class.java)

val remoteDataSource = UserRemoteDataSource(retrofit)
val localDataSource = UserLocalDataSource()

val userRepository = UserRepository(localDataSource, remoteDataSource)
loginViewModel = LoginViewModel(userRepository)

这种方法最为常见，但是问题也很多：

• 1、无法复用代码 / 对象： 如果项目中其他地方需要创建依赖对象，需要使用重复的代码 ，对象也需要重复创建；
• 2、必须按顺序创建对象： 必须先实例化 UserRepository，才能实例化 LoginViewModel；

为了优化这些问题，可以用以下两种方式改进：

• 1、服务提供模式：从外部服务容器抓取依赖对象
• 2、依赖注入：并以参数的形式注入依赖对象

可以发现，第一种和后面两种的区别在于 构造依赖对象的位置是在类内部 / 类外部。如果构造依赖对象的位置是在类外部，则称为控制反转（Inversion of Control，IoC）。IoC 可以认为是一种设计模式，但是由于理论成熟的时间相对较晚，所以没有包含在《设计模式·GoF》之中。

1.2 服务提供模式（Service Locator Pattern）

创建一个依赖容器类，用于构造并存储依赖对象。调用方主动从外部服务容器抓取依赖对象，例如：

服务提供容器

class AppContainer {
    private val retrofit = Retrofit.Builder()
        .baseUrl("https://example.com")
        .build()
        .create(LoginService::class.java)

    private val remoteDataSource = UserRemoteDataSource(retrofit)
    private val localDataSource = UserLocalDataSource()

    val userRepository = UserRepository(localDataSource, remoteDataSource)
}

class MyApplication : Application() {
    val appContainer = AppContainer()
}

val appContainer = (application as MyApplication).appContainer
loginViewModel = LoginViewModel(appContainer.userRepository)

1.3 依赖注入（Dependency Injection）

在类外部构造依赖对象，并以参数的形式注入依赖对象，例如在构造器、setter 方法注入，所以其实我们一直都在使用依赖注入。依赖注入与服务提供模式的本质区别是：使用服务提供模式时，调用方可以控制请求依赖对象的时机；而使用依赖项注入方式时，一般由外部主动注入所需对象。

1.4 小结

使用依赖注入可以为我们带来以下好处：

• 1、在外部注入或配置依赖项，因此我们可以重用这些组件。当我们需要修改依赖项的实现时，不需要大量修改很多处代码，只需要修改一小部分代码；
• 2、可以注入依赖项的模拟实现，让代码测试更加容易。

---

2. Android 依赖注入框架

上一节我们解释了依赖注入的概念，其实我们平时无意中就在使用依赖注入了。当只有一个依赖项时，手动进行依赖注入很简单，但随着项目规模变大，手动注入会变得越来越复杂。

而使用依赖注入框架，可以让依赖注入的过程更加简便，可以归为两类：

• 1、基于反射的动态方案

例如 Google guice，但由于使用了反射，性能上会有损耗。

• 2、基于编译时注解的静态方案

例如 Dagger(:['dægə])、Hilt([hɪlt]) 和 ButterKnife。其中 ButterKnife 只能实现控件的依赖注入，而 Dagger 和 Hilt 的应用场景更广。基于编译时注解的方案可在编译时生成链接依赖项的代码，因此不会使用反射。

2.1 Dagger

Dagger 框架最初由 Square 组织开发，而后来的 Dagger2 和 Hilt 框架则由 Square 和 Google 共同开发维护。Dagger 的名字取自有向无环图（DAG，Directed acyclic graph），Dagger 本质上不是提供了依赖注入的能力，而是采用了注解的形式让依赖注入变得更加简易。

2.2 Hilt

Hilt 其实是针对 Android 平台对 Dagger2 的二次封装，Hilt 本质上是对 Dagger 进行场景化，它为 Android 平台制定了一系列规则，大大简化了 Dagger 的使用。在 Dagger 里，你需要手动获取依赖图和执行注入操作，而在 Hilt 里，注入会自动完成，因为 Hilt 会自动找到 Android 系统组件中那些最佳的注入位置。

---

3. Dagger2

Dagger2 先到这里。

---

4. 总结

• 1、依赖注入在类外部构建依赖对象，使得依赖项的代码和组件能够重用，也可以注入依赖项的模拟实现，使代码更易于测试；

• 2、Dagger 本质上不是提供了依赖注入的能力，而是采用了注解的形式让依赖注入变得更加简易；Hilt 是对 Dagger2 的二次封装，本质上是对 Dagger进行场景化；

---

参考资料

•   Dependency Injection —— 维基百科
• 《Tasting Dagger 2 on Android.》 —— Fernando Cejas 著
• 《从 Dagger 到 Hilt，谷歌为何执着于让我们用依赖注入？》 —— 扔物线 著
• 《Android 中的依赖项注入》系列文档 —— Android Developers
• 《Android Studio 4.1 的 Dagger 导航更新》 —— Android Developers
• 《在 Kotlin 中使用 Dagger 会遇到的陷阱和优化方法》 —— Android Developers
• 《使用 Dagger 自定义 WorkManager》 —— Android Developers