目录
- 1. 概述
- 1.1 依赖注入(DI)概念
- 1.2 为什么在代码中使用外部去注入依赖
- 1.2.1 满足合理的架构设计
- 1.2.2 满足一些数据共享场景
- 1.3 Hilt是什么
- 1.4 Hilt使用地方
- 2. Hilt使用
- 2.1 导入
- 2.2 一个简单的例子
- 2.3 实现接口实例注入
- 2.4 实现第三方依赖注入
- 2.5 Hilt 的内置组件和作用域
- 2.5.1 @InstallIn 注解
- 2.5.2 使注入对象单例
- 2.5.3 作用域的包含关系
- 2.6 Hilt 预置的 Qualifier
- 3 小结
- 参考文章
Git学习地址:传送门
1. 概述
随着Android 11 的发布,Jetpack家族新添了 Hilt
和 App Startup
等成员。
而 Hilt 是被定义为 依赖注入框架而被发布。什么?又是依赖注入框架?不是之前已经有了一个 Dagger2
了吗?除了 Dagger2, 还有 ButterKnife
,Kotlin甚至还有轻量级的 Koin
。
为什么?为什么谷歌这么 这么的想让我们去了解依赖注入,并使用依赖注入的框架呢?下面请听我慢慢分析。
1.1 依赖注入(DI)概念
什么是依赖注入?先来看下面代码:
class MyClass {
val user = User()
}
我们在一个类 MyClass
中 声明了一个变量 user,并初始化-------调用 User
构造函数,创建一个对象。
上面这段代码就产生了一个依赖关系。
我们要先看懂谁依赖了谁?首先 MyClass
是我们的类,User
可以是我们自己写的类,也可以是通过第三方Jar包或SDK里面的类。
在我们写的 MyClass
的代码里面,我们需要一个 User 对象来完成一些任务,所以我们创建了 User 对象,这就说明 MyClass 依赖了 User。对于 MyClass来说,User是外面之物,但是又需要依赖它。
如果上面这个 User,不是由自己创建,而是由外部创建,然后在本类只做赋值工作 ,这个过程就是 依赖注入。
有一个我们非常熟悉的设计模式,就使用了依赖注入的方法—工厂模式:
class UserFactory {
fun newUser(): User{
return User()
}
}
class MyClass {
val user = UserFactory.newUser()
}
我们的 MyClass 类需要使用 User 类,但是这次没有自己来创建(没有自己new出来),而是交由给 UserFactory
来创建出来,MyClass就做了最后的赋值工作。
对于 MyClass 来说,这就是一次依赖注入,和上面例子相比,把对象创建的过程交由给了别的类。
所以我们通过上面两个例子就能知道依赖注入的本质是什么:借由外部得到对象。依赖注入框架就是这个外部
现在流行的 Dagger2、Koin框架,只是让我们更轻松、更容易的去得到对象。
Dagger的中文翻译是 “刀”,它就像一把刀,插进我们代码中。那相信你也知道 ButterKnife
为什么这么取名了吧。
PS: 对于我来说,针筒注射更适合来描述这个过程。
1.2 为什么在代码中使用外部去注入依赖
1.2.1 满足合理的架构设计
举一个Andorid常用的例子。 在 MVP / MVC / MVVM
架构没有流行之前,我们的代码都是如何的?
我们会把所有的 数据逻辑代码、视图代码都写在了 Activity / Fragment 中。
这会导致什么结果:
- Activity / Fragment 代码臃肿,逻辑混乱
- 难维护,难复用
举一个代码例子,我们要在冰箱中放一个苹果,那么我们代码会这样写:
class Fridge {
val apple = Apple() // 创建一个苹果
fun store() {
storeAnApple(apple) // 存放苹果
}
}
这样写有没有问题?如果你觉得没有问题,那我的文章你应该继续往下读,如果觉得有问题,那你可以跳过这整节了。
Fridge
是冰箱类,那么按照 单一职责原则
,它的作用应该是存储物品。但是在代码中,它却做了一个事情:那就是将苹果创建出来了。
冰箱类,它不应该知道苹果是如何产生的,它只需要拿到苹果并存储就行了。不然的话,冰箱要存储香蕉,那岂不是又new出一个香蕉,要放水果蔬菜,又要new出水果蔬菜…
显然,我们不需要 Fridge 来创建 Apple 对象,所以我们需要外部来帮我创建。比如苹果工厂。
或者我们使用 依赖注入框架 Dagger2,通过类似下面的代码:
class Fridge {
@Inject lateinit val apple: Apple // 从DI框架中拿到一个苹果
fun store() {
storeAnApple(apple) // 存放苹果
}
}
这样,冰箱就可以不用关心苹果的构造,而直接存储了。
1.2.2 满足一些数据共享场景
假设我们 Activity
有一个自定的TextView,并且该 TextView 需要依赖 MainActivity 的数据,那么这个TextView要这样写:
@AndroidEntryPoint
class MainActivity : AppCompatActivity() {
@Inject lateinit var user: User
...
}
class MyTextView: TextView(...) {
...
// 需要用到 MainActivity中的 user 对象
override fun onAttachedToWindow() {
super.onAttachedToWindow()
// 强制转化
text = (context as MainActivity).user.name
}
}
这样的代码很丑,因为做了强转,并且只适用于 MainActivity
,不灵活。
而如果使用了Dagger、Hilt框架,就能这样写:
@ActivityScoped
data class User(var id: Int, var name: String, var mood: String) {
...
}
@AndroidEntryPoint
class MyTextView(context: Context?, attrs: AttributeSet?) : TextView(context, attrs) {
@Inject
lateinit var user: User
override fun onAttachedToWindow() {
super.onAttachedToWindow()
// 直接使用 MainActivity的
text = user.name
}
}
这里就能直接使用到 MainActivity的user对象。相当于 MainActivity 中注入后 User 后,又在代码的运行中将该数据分享到了 MyTextView 中。
在我们的代码中,就有许多需要数据共享的地方,比如 OkHttp / Retrofit
的单例,一些数据Bean等。
那这里有一个问题:假如我的数据不需要被共享,只在一处用,那我还要给它做依赖注入吗?
答案是:根据设计原则的扩展性,我们不能在一开始就断定一个类之后的迭代中是否会被各种类使用、继承,既然我们保证不了其以后不被共享,那我们就可以在一开始设计时,给它使用依赖注入的形式被创建,这样便于以后的迭代。
1.3 Hilt是什么
了解了 依赖注入 是什么之后,我们再来了解 Hilt,反正我们知道他是一种得到对象的手段。
Hilt 是基于 Dagger2 的针对 Android场景定制化 的框架。
这有点像什么? RxAndroid 是 RxJava 的Android平台定制化扩展。Andorid虽然由Java、Kotlin构成,但是它有很多平台的特性,比如它有 Java开发 所不知道的 Context
等。
Dagger框架虽然很出名,在国外也很流行,但是在国内使用其的App少之又少,列举一些缺点:
- 上手难,众多Android应用框架中,Dagger必定是最难学的那一档;
- 它就是一个复杂框架,没有针对任何平台,所以对于所有平台来说会难用;
- 在Android Studio4.0版本以前,无法追踪Dagger的依赖关系(就类比IDE无法通过快捷键知道一个接口有哪些实现类)
- 开发者不知道为啥要做依赖注入
对于第三点,Android Studio4.1已经支持了该功能,但是4.1有许多Bug,很多开发者都没有升级 = =。
Hilt的出现解决前两点问题,因为 Hilt 是 Dagger 针对Android平台的场景化框架,比如Dagger需要我们手动声明注入的地方,而Android声明的地方不都在 onCreate()
吗,所以Hilt就帮我们做了,除此之外还做了很多事情,这样一来,相较于Dagger,我们能用更少代码、更容易、更轻松的配置依赖注入。
至于 Koin
和 Hilt
的对比,两者配置的代码都比较少, 所以比较的层次更多在性能方面,我因为没有学习过Koin,所以这里就不做比较,可以看看这篇文章: 全方面分析 Hilt 和 Koin 性能
1.4 Hilt使用地方
Daager
、Koin
、Hilt
,Google为什么致力于让开发者使用DI框架,可以看下Android开发者文档的这篇文章:传送门
Google认为移动端应用的架构设计,最重要的 Separation of concerns(分离关注点)。上网找解释,其实它就是 模块解耦。下面是Google官方推荐的Android应用架构图:
该图不多做说明,郭神的文章中就已经分析了该图片,Jetpack完全就是为该图架构服务。
Activity / Fragment是由系统所创建的,所以我们可以不用关心如何去创建。 ViewModel 层由 JetPack
来提供,所以我们也不用关心其创建。但是该有谁来创建 Repository
呢?
该架构下,Activity是不知道 Repository 存在的, 而 ViewModel 显然不能来创建 Repository,因为它只是依赖。
如果我们将Repostirory 设置成单例类,那每处地方都能够引用它,这样的处理显得有些不好。
这个问题比较棘手,但是如果我们使用 依赖注入框架,就能灵活的解决这个问题了。
2. Hilt使用
2.1 导入
在 app 的 build.gradle
中加入:
plugins {
...
id 'kotlin-kapt'
id 'dagger.hilt.android.plugin'
}
dependencies {
...
implementation 'com.google.dagger:hilt-android:2.28-alpha'
kapt 'com.google.dagger:hilt-android-compiler:2.28-alpha'
}
在 project的 build.gradle
中加入:
classpath 'com.google.dagger:hilt-android-gradle-plugin:2.28-alpha'
2.2 一个简单的例子
Hilt 需要 AndroidManifest
使用带有 @HiltAndroidApp
注解的 Application 类,所以我们的 Application需要这样:
@HiltAndroidApp
class HiltApp : Application() {
...
}
然后在 AndroidManifest 文件中声明:
<application
android:name=".HiltApp"
...
</application>
假如我们要在 MainActivity
中注入一个 User
对象, 我们首先编写一个 User 类,User类有两个属性 name
和 age
。
诶,这个时候有同学就会问了:我通过 @Inject
声明一个User,Hilt就能给我创建一个 User 对象,那这个User对象里面的name和age是啥?答案是:编译会报错,因为我们自己都不知道这两个参数是啥,Hilt怎么可能会知道,所以这两个属性也要通过依赖注入的方式来注入。
为了简化这个问题,我定义一个默认的无参构造函数,反正创建之后,里面的值也是可以修改的嘛。
data class User(var name: String, var age: Int) {
// 定义一个默认的无参构造函数,并使用 @Inject 注解修饰
@Inject
constructor() : this("Rikka", 23)
}
接着我们在 MainActivity
中声明一个 User,通过 @Inject
来修饰,并且MainActivity 需要通过 @AndroidEntryPoint
修饰:
// 1
@AndroidEntryPoint
class MainActivity : AppCompatActivity() {
// 2
@Inject
lateinit var user: User
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
setContentView(R.layout.activity_main)
Log.d(TAG, "user name:${user.name} age:${user.age}")
}
}
Logcat 打印结果如下:
代码解析:
注释1: 为 MainActivity 修饰 @AndroidEntryPoint
,该注解表明 该类为需要进行依赖注入的 Android类,是Dagger针对Android场景化的地方。当我们类中需要进行依赖注入,我们为该类加入这个注解,它会帮助创建一个单独的 Hilt组件。它不能修饰Abstract,它只能修饰:
- ComponentActivity
- (Support)Fragment
- View
- Service
- BroadcastReceiver
注释2:我们需要注入一个 User,所以我们给它加一个 @Inject
注解,告诉 Hilt。因为Kotlin的语法问题,这里不得不声明 lateinit(而这里Koin的写法更加优雅),接下来步骤大概是这样的:
- Hilt 会去找
User
这个类的构造函数,以此来创建一个对象 - Hilt 发现 有两个个构造函数,而无参构造函数被
@Inject
声明 - Hilt 会去调用被
@Inject
的构造函数,创建一个User("Rikka", 23)
对象 - 返回这个对象, MainActivity 实现外部帮忙创建 User对象,实现 User 的依赖注入。
Inject 的中文翻译是 “注入、注射”,所以可以形象的认为, @Inject
修饰的变量是被外界通过针筒注入进来的。
@Inject
可以修饰
- 构造函数 Constructors
- 变量 Fields
- 方法 Methods
构造函数是最先被注解的,然后再是变量和方法。所以它修饰构造函数和修饰变量,其实是不同的作用。但为了便于理解,我们可以把它看成是一个插眼工具,便于Hilt去寻找要注入的地方。
我们上面的 User 类是无参构造函数,这次假设我们要有参数的呢?其实就是参数也要注入嘛,这就是套娃来的,来看看我们给User新增一个 属性:Clothes
:
class Clothes @Inject constructor() {
}
class User @Inject constructor(var clothes: Clothes){
}
@AndroidEntryPoint
class MainActivity : AppCompatActivity() {
...
Log.d(TAG, "user clothes:${user.clothes}")
}
打印结果:
PS:大家不要太拘泥于有参构造函数的创建,我认为注入的作用是创建出一个对象,这个对象里面的内容可以后续再传入,它更多的体现、或者我们需要注意的是 “分离关注点”
2.3 实现接口实例注入
因为接口没有构造函数,所以当我们想要依赖一些接口时,该怎么办。
我们来下面的示例,我们写一个 Profession
接口,代表职业:
interface Profession {
fun doJob()
}
假设我们有两个实现接口的类:医生类和程序猿类:
class Doctor : Profession{
override fun doJob() {
Log.d("Doctor", "doctor do job")
}
}
class Programmer : Profession{
override fun doJob() {
Log.d("Programmer", "programmer do job")
}
}
这个时候我给 User 类添加一个职业的属性,并希望它能够自动注入:
class User @Inject constructor(var clothes: Clothes){
@Inject
lateinit var profession: Profession
}
因为 Profession
是一个接口,它有两个实现类,所以这样 Hilt 并不能知道我们要实例化哪个具体的实现类,所以编译的时候就会报错。
而 Hilt 也解决这种问题,首先我们要在每个实现类上注入构造函数:
class Doctor @Inject constructor() : Profession{
...
}
class Programmer @Inject constructor() : Profession{
...
}
接着我们需要实现一个和该接口有关的 XXXModule
类,它被 @Module
修饰,这个和 Dagger 中的一样,代表它会为接口提供一个创建实例的工厂,同时需要加上 @InstallIn
注解,用来声明它是被安装到哪个组件中,该注解后面会说到。 代码如下:
@Module
@InstallIn(ActivityComponent::class)
abstract class ProfessionModule { // 1
// 2
@Binds
abstract fun bindDoctor(doctor: Doctor): Profession
}
注释1: 我们写出来的类是一个抽象类,因为我们不需要具体的实现它,而且它没有具体的命名规则,因为我们也不会在代码中直接调用它,但是为了便于理解,我们起名一般叫 接口名 + Module
。
注释2: 我们假设该Module提供一个 Doctor 的职业,那我们需要定义一个 抽象方法 来获取一个Doctor类。 并且 该方法需要被 @Binds
注解修饰。这样就能被 Hilt 识别。
这样一来,我们就实现了接口的一个实例化的注入,我们来实验一下,在 User 中去展示它:
class User @Inject constructor(var clothes: Clothes){
@Inject
lateinit var profession: Profession
fun showMyself() {
profession.doJob()
}
}
// MainActivity
@AndroidEntryPoint
class MainActivity : AppCompatActivity() {
@Inject
lateinit var user: User
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
setContentView(R.layout.activity_main)
user.showMyself()
}
}
打印结果为:
可以看到我们的 Doctor 成功的注入了。
OK,我们了解了接口某一个实现类的注入 (Doctor),那假设这个时候,另外一个类需要注入接口的另一个实现类 Programmer,那我们是不是也得按照同样的做法,在 Module类中添加呢?
@Module
@InstallIn(ActivityComponent::class)
abstract class ProfessionModule {
@Binds
abstract fun bindDoctor(doctor: Doctor): Profession
@Binds
abstract fun bindProgrammer(programmer: Programmer): Profession
}
这个时候发现运行,编译也会报错:
提示我们被绑定多次了。
这是因为 Doctor
和 Programmer
都是相同类型,当他们一起被 Binds 注解,那 Hilt 不知道要去绑定哪一个。
这个时候就需要使用 @Qualifier
注解来帮助我们了,它就是为了这种 相同类型 依赖注入而产生的:
@Qualifier
@Retention(AnnotationRetention.BINARY)
annotation class BindDoctor
@Qualifier
@Retention(AnnotationRetention.BINARY)
annotation class
我们创建了新的注解 BindDoctor
和 BindProgrammer
,他们都被 @Qualifier
修饰,表示他们用来作用在同种类型上, @Retention
选择使用 BINARY类型,表明该注解保留到编译后,但无法通过反射来得到,是比较适合的注解。
接下来,我们要将这些注解作用在被 Binds
注解的抽象方法上:
@Module
@InstallIn(ActivityComponent::class)
abstract class ProfessionModule {
@BindDoctor
@Binds
abstract fun bindDoctor(doctor: Doctor): Profession
@BindProgrammer
@Binds
abstract fun bindProgrammer(programmer: Programmer): Profession
}
最后,在 User 中声明使用哪一个类型的注入:
class User @Inject constructor(var clothes: Clothes){
@BindProgrammer // 这次注入一个 Programmer
@Inject
lateinit var profession: Profession
fun showMyself() {
profession.doJob()
}
}
打印结果如下所示:
这下我们就实现了具体某个实例的注入啦。
2.4 实现第三方依赖注入
假设一些类不是由我们自己写的,而是由第三方库导入的。比如 OkHttp
,我们在使用网络请求的时候,需要使用它,为了分离关注点,我们需要对他进行依赖注入。
但是 OkHttp
是我们不能修改的类,所以我们不能在它的构造函数上加入 @Inject
, 这个时候该怎么办呢?
Dagger 中也有类似的场景,我们需要 @Providers
来帮助我们。除此之外,我们也需要 @Module
注解来声明一个 Module 类, 基于上面的例子,我们可以把这种 Module 类看成是一个工厂:
@Module
@InstallIn(ApplicationComponent::class)
class NetModule { // 1
// 2
@Provides
fun provideOkHttpClient(): OkHttpClient {
// 3
return OkHttpClient.Builder().build()
}
}
注释1: 声明一个 NetModule,提供网络库相关的组件,并没有和上面例子一样声明为抽象函数,这是因为里面的都有具体的实现方法。
注释2: 编写一个 provideOkHttpClient()
方法,返回一个 OkHttpClient对象。 声明一个 @Providers
注解,表示这个提供的依赖对象,是第三方的类或者系统类,我们因为不能直接更改其构造函数,所以得加上这个注解。
注释3:new 一个对象,并返回。
这样,我们就能在我们代码中直接使用了:
@Inject
lateinit var okHttpClient:
@Providers 的本质是什么?
第三方类因为其只读性,Hilt不能找到其构造函数,所以需要我们自己手动的创建,创建的方法被 @Providers
修饰, Hilt 找到这个方法,并提供由我们手动创建的对象。
所以 @Providers
的本质,是由我们自己创建对象, Hilt 帮我们注入。
现在大家都不会直接使用 OkHttp,而是使用 Retrofit
,所以我们来提供一个 Retrofit 把:
...
@Provides
fun provideRetrofit(okHttpClient: OkHttpClient): Retrofit {
return Retrofit.Builder()
.addConverterFactory(GsonConverterFactory.create())
.client(okHttpClient)
.build()
}
因为 Retrofit的创建需要依赖一个 OkHttpClient
对象,所以我们需要创建一个,但是我们也可以注入一个,因为我们之前已经有 provideOkHttpClient
,所以它就能提供一个实例,我们不用在担心什么了。
2.5 Hilt 的内置组件和作用域
2.5.1 @InstallIn 注解
我们之前看到了 @InstallIn
这个注解,它的作用是用来表明 Module 作用的地方,它的参数时 xxxComponent
格式,前面xx代表作用域。
因为 Hilt 是Dagger的Android场景化,所以它能作用的地方和我们Android息息相关,有下面几处:
- Application ->
ApplicationComponent
- ViewModel ->
ActivityRetainedComponent
- Activity ->
ActivityComponent
- Fragment ->
FragmentComponent
- View ->
ViewComponent
- Service ->
ServiceComponent
- View Annotation with
@WithFragmentBindings
->ViewWithFragemntComponent
除了最后一个,别的作用域还是挺常见的。他们都要通过 @InstallIn
注入。
比如我们ProfessionModule
是声明成 @InstallIn(ActivityComponent::class)
,这就说明只有在 Activity 的代码中可以使用它,而在 Service 中是不能使用的。
而 NetModule
则是声明成 InstallIn(ApplicationComponent::class)
的,这说明在全局都可以使用它提供的 OkHttpClient 和 Retrofit 对象。
2.5.2 使注入对象单例
像 Retrofit 、 OkHttpClient 这样的全局都需要使用到的对象,我们希望它的作用域是全局,并且单例的。
但是 Hilt 提供的 @Inject
对象并不是单例的,每次 注入时都会重新生成一个新的实例,这就说明,假设我们要使用 Retrofit 来做网络请求, @Providers
每次提供的都是不一样的,这样对性能来说很不友好,而且不符合常规的逻辑设定。
按照以往,我们可以通过给 NetModule
声明一个 @Singleton
注解,来让这个类实现单例,来解决这个问题。
Hilt 也有自己的解决方案,那就是使用 @xxxScope
注解,它和上面的 xxxComponent
所对应,表示 在这个作用域内单例,来看看对应关系:
- Application ->
ApplicationComponent
->@Singleton
- ViewModel ->
ActivityRetainedComponent
->@ActivityRetainedScoped
- Activity ->
ActivityComponent
->@ActivityScoped
- Fragment ->
FragmentComponent
->@FragmentScoped
- View ->
ViewComponent
->@ViewScoped
- Service ->
ServiceComponent
->@ServiceScoped
- View Annotation with
@WithFragmentBindings
->ViewWithFragemntComponent
->@ViewScoped
使用 @xxScoped
来替代 @InstallIn(xxxComponent::class)
声明组件为单例。
因为 Application 是作用于全局,所以它的注解是 @Singleton
,比较好理解。
2.5.3 作用域的包含关系
作用域也有自己的包含关系,比如被 @ActivityScoped
声明的组件,可以在 Fragment 或者 View 中使用,他们的具体包含关系如下图所示:
2.6 Hilt 预置的 Qualifier
我介绍过 Hilt 是 Dagger针对Android的场景化,所以它低层做了很多事情,使得在Android上更好的使用。除了上面介绍过的那些注解外,还有很多别的东西,可以让我们去探索,同时也了解了Dagger本身。
Context 上下文是Android 独特的存在,它代表着 Application、Activity、Service的一些fwk层的东西。
而我们的代码中经常会需要 Context 来创建一些东西:
class A @Inject constructor(context: Context) {
...
}
但是我们知道,它是系统类,我们无法注入 Context。那我们可以通过使用 @Providers
来创建吗?
@Providers
fun provideContext() {
???
}
很明显,Context 是由AMS来创建的,我们无法直接创建一个上下文出来。这个问题该如何解决呢?
答案是:我们不用解决,Hilt 为我们提供了它自己预置的注解 @ApplicationContext
和 @ActivityContext
,我们直接使用,Hilt会帮我们注入上下文。
class A @Inject constructor(@ApplicaitonContext context: Context)
而现在没有 ServiceContext
,可能是用的比较少吧?
@ApplicationContext
提供的类型是 Application, 而不是我们自己的 App 自定义的 Application,加入我们要使用自己的该怎么办呢?答案是也很简单:
@Providers
fun provideApplicaiton(application: Application): MyApplication {
return applicaiton as MyApplication
}
直接在 Module 中提供一个,并强转就 OK啦。
注意
ApplicationContext
的作用域是全局, 所以它修饰的类的作用只能是 @InstallIn(Applicaiton)
或 @Singleton
,其他的也同理。
3 小结
之前没有用过 Dagger,因为项目不需要,且难学,问题多。 Hilt 出来之后解决了大部分的痛点,再不上车属实就有点说不过去了。
Hilt 相较与 Dagger,肯定是更好用,更适合Android来使用。 它和 Koin
的比较,只是性能上的差异,网上大部分的文章都认为 Hilt 性能更优,但是代码量更多,在大的项目使用 Hilt 会更好,而小的项目两者差别不会太大。具体还请开发者自己研究。
Hilt 作用是 提供依赖注入,帮助程序分离关注点,帮助搭建低耦合高内聚的框架,学习它,有利于我们学习 Android应用架构 方面的技能。
至于还有一些其他的用法,例如 ViewModel的注入,可以看下郭神、鸿洋等大佬的文章,现在使用Hilt的项目是越来越多了。
题外话:
因为项目庞大,我们团队一直没有迁到AndroidX,很多同学空有一身Jetpack本领却无处施展呀,不过AndroidX终将还是会来,我们今年将会迁移至AndroidX,届时将会上 Jetpack 全家桶,我学习 Hilt 也是基于这样的契机,我是完全没有 AndroidX 的开发经验,所以为了跟上大部队,就是补一些大佬的Blog、书籍等,将会在接下来的几个月学习Jetpack上的框架。
参考文章
Hencoder 从 Dagger 到 Hilt,谷歌为什么执着于让我们使用依赖注入?郭霖 Jetpack新成员,一篇文章带你玩转Hilt和依赖注入应用架构指南