前置知识
这篇文章的内容会涉及以下前置 / 相关知识，贴心的我都帮你准备好了，请享用~
- APT： 【点赞催更】
- 注解：「Java 路线」| 注解（含 Kotlin）
- Dagger 官网：Dagger
- Hilt 官网：Hilt
- Dagger 2 仓库：Github·Dragger
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、基于编译时注解的静态方案
例如 Dragger(:['dægə])、Hilt([hɪlt]) 和 ButterKnife。其中 ButterKnife 只能实现控件的依赖注入，而 Dragger 和 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 就到这里，先把 Hilt 安排上。
4. 总结
- 1、依赖注入在类外部构建依赖对象，使得依赖项的代码和组件能够重用，也可以注入依赖项的模拟实现，使代码更易于测试；
- 2、Dagger 本质上不是提供了依赖注入的能力，而是采用了注解的形式让依赖注入变得更加简易；Hilt 是对 Dagger2 的二次封装，本质上是对 Dagger进行场景化；
