Android | 依赖注入与 Dagger2 框架

2021-01-10  本文已影响0人  彭旭锐

点赞关注,不再迷路,你的支持对我意义重大!

🔥 Hi,我是丑丑。本文 「Android 路线」| 导读 —— 从零到无穷大 已收录,这里有 Android 进阶成长路线笔记 & 博客,欢迎跟着彭丑丑一起成长。(联系方式在 GitHub)


前置知识

这篇文章的内容会涉及以下前置 / 相关知识,贴心的我都帮你准备好了,请享用~


1. 什么是依赖注入?

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

—— 引用自 https://developer.android.google.cn/training/dependency-injection/manual —— 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)

这种方法最为常见,但是问题也很多:

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

可以发现,第一种和后面两种的区别在于 构造依赖对象的位置是在类内部 / 类外部。如果构造依赖对象的位置是在类外部,则称为控制反转(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 小结

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


2. Android 依赖注入框架

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

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

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

例如 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. 总结


参考资料


创作不易,你的「三连」是丑丑最大的动力,我们下次见!

上一篇 下一篇

猜你喜欢

热点阅读