Android Dagger替换成Hilt
在组件化AwesomeGithub项目中使用了Dagger
来减少手动依赖注入代码。虽然它能自动化帮我们管理依赖项,但是写过之后的应该都会体会到它还是有点繁琐的。项目中到处充斥着Component
,这让我想起了传统MVP
模式的接口定义。
简单来说就是费劲,有许多大量的类似定义。可能google
也意识到这一点了,所以前不久发布出了Hilt
。
Hilt
为了防止没听说过的小伙伴们一头雾水,首先我们来了解下Hilt
是什么?
Hilt
是Android
的依赖注入库,可减少在项目中执行手动依赖项注入的样板代码。
Hilt
通过为项目中的每个 Android
类提供容器并自动管理其生命周期,提供了一种在应用中使用 DI
(依赖项注入)的标准方法。Hilt
在Dagger
的基础上构建而成,因而能够具有 Dagger
的编译时正确性、运行时性能、可伸缩性。
那么有的小伙伴可能会有疑问,既然已经有了Dagger
那为什么还要Hilt
的呢?
Hilt
与Dagger
的主要目标都是一致的:
- 简化
Android
应用的Dagger
相关基础架构。 - 创建一组标准的组件和作用域,以简化设置、提高可读性以及在应用之间共享代码。
- 提供一种简单的方法来为各种构建类型(如测试、调试或发布)配置不同的绑定。
但是Android
中会实例化许多组件类,例如Activity
,因此在应用中使用Dagger
需要开发者编写大量的样板代码。Hilt
可以减少这些样板代码。
Hilt
做的优化包括
- 无需编写大量的
Component
代码 Scope
也会与Component
自动绑定- 预定义绑定,例如
Application
与Activity
- 预定义的限定符,例如
@ApplicationContext
与@ActivityContext
下面通过AwesomeGithub中Dagger
来对比了解Hilt
的具体使用。
依赖
使用之前将Hilt
的依赖添加到项目中。
首先,将hilt-android-gradle-plugin
插件添加到项目的根级 build.gradle
文件中:
buildscript {...
dependencies {
...
classpath 'com.google.dagger:hilt-android-gradle-plugin:2.28-alpha'
}
}
然后,应用Gradle
插件并在app/build.gradle
文件中添加以下依赖项:
...apply plugin: 'kotlin-kapt'
apply plugin: 'dagger.hilt.android.plugin'
android {
...
}
dependencies {
implementation "com.google.dagger:hilt-android:2.28-alpha"
kapt "com.google.dagger:hilt-android-compiler:2.28-alpha"
}
Application类
使用Dagger
时,需要一个AppComponent
单例组件,项目中的其它SubComponent
都将依赖于它,所以在AwesomeGithub中它大概是这个样子
@Singleton@Component(
modules = [
SubComponentModule::class,
NetworkModule::class,
ViewModelBuilderModule::class
]
)
interface AppComponent {
@Component.Factory
interface Factory {
fun create(@BindsInstance applicationContext: Context): AppComponent
}
fun welcomeComponent(): WelcomeComponent.Factory
fun mainComponent(): MainComponent.Factory
...
fun loginComponent(): LoginComponent.Factory
}
@Module(
subcomponents = [
WelcomeComponent::class,
MainComponent::class,
...
LoginComponent::class
]
)
object SubComponentModule
上面的我已经省略了大半,是不是看起来很多,而且最重要的是很多重复的结构基本都是一样的。所以Hilt
基于这一点进行了简化,将这些重复的编写转成构建的时候自动生成。
Hilt
要做的很简单,添加几个注释
@HiltAndroidAppclass App : Application() { ... }
所有的Hilt
应用都必须包含一个带@HiltAndroidApp
注释的Application
。它将替代Dagger
中的AppComponent
。
Android类
对于Android
类,使用Dagger
时需要定义SubComponent
并将它依赖到Application
类中。下面以WelcomeActivity
为例。
@Subcomponent(modules = [WelcomeModule::class])interface WelcomeComponent {
@Subcomponent.Factory
interface Factory {
fun create(): WelcomeComponent
}
fun inject(activity: WelcomeActivity)
}
下面看Hilt
的实现
@AndroidEntryPointclass MainActivity : BaseHiltActivity<ActivityMainBinding, MainVM>() { ... }
Hilt
要做的是添加@AndroidEntryPoint
注释即可。
惊讶,结合上面的,两个注解就替换了Dagger
的实现,现在是否体会到Hilt
的简洁?对新手来说也可以降低很大的学习成本。
目前Hilt
支持下面Android
类
- Application (@HiltAndroidApp)
- Activity
- Fragment
- View
- Searvice
- BroadcastReceiver
有一点需要注意,如果使用@AndroidEntryPoint
注释了某个类,那么依赖该类的其它类也需要添加。
典型的就是Fragment
,所以除了Fragment
还需要给依赖它的所有Activity
进行注释。
@AndroidEntryPoint
的作用,对照一下Dagger
就知道了。它会自动帮我们生成对应Android
类的Componennt
,并将其添加到Application
类中。
@Inject
@Inject
的使用基本与Dagger
一致,可以用来定义构造方法或者字段,声明该构造方法或者字段需要通过依赖获取。
class UserRepository @Inject constructor(private val service: GithubService
) : BaseRepository() { ... }
@Module
Hilt
模块也需要添加@Module
注释,与Dagger
不同的是它还必须使用@InstallIn
为模块添加注释。目的是告知模块用在哪个Android
类中。
@Binds
@Binds
注释会告知Hilt
在需要提供接口的实例时要使用哪种实现。
它的用法与Dagger
没什么区别
@Module@InstallIn(ActivityComponent::class)
abstract class WelcomeModule {
@Binds
@IntoMap
@ViewModelKey(WelcomeVM::class)
abstract fun bindViewModel(viewModel: WelcomeVM): ViewModel
}
不同的是需要添加@InstallIn
,ActivityComponent::class
用来表明该模块作用范围为Activity
@Providers
提供一个FragmentManager
的实例,首先是Dagger
的使用
@Moduleclass MainProviderModule(private val activity: FragmentActivity) {
@Provides
fun providersFragmentManager(): FragmentManager = activity.supportFragmentManager
}
对比一下Hilt
@InstallIn(ActivityComponent::class)@Module
object MainProviderModule {
@Provides
fun providerFragmentManager(@ActivityContext context: Context) = (context as FragmentActivity).supportFragmentManager
}
区别是在Hilt
中@Providers
必须为static
类并且构造方法不能有参数。
提供的组件
对于之前提到的@InstallIn
会关联不同的Android
类,除了@ActivityComponent
还有以下几种
对应的生命周期如下
同时还提供了相应的作用域
所以Hilt
的默认提供将大幅提高开发效率,减少许多重复的定义
ViewModel
最后再来说下ViewModel
的注入。如果你使用到了Jetpack
相信少不了它的注入。
对于Dagger
我们需要自定义一个ViewModelFactory
,并且提供注入方式,例如在AwesomeGithub的componentbridget
模块中定义了ViewModelFactory
@Moduleabstract class ViewModelBuilderModule {
@Binds
abstract fun bindViewModelFactory(factory: ViewModelFactory): ViewModelProvider.Factory
}
class ViewModelFactory @Inject constructor(private val creators: @JvmSuppressWildcards Map<Class<out ViewModel>, Provider<ViewModel>>) : ViewModelProvider.Factory {
override fun <T : ViewModel?> create(modelClass: Class<T>): T {
var creator = creators[modelClass]
if (creator == null) {
for ((key, value) in creators) {
if (modelClass.isAssignableFrom(key)) {
creator = value
}
}
}
if (creator == null) {
throw IllegalArgumentException("Unknown model class: $modelClass")
}
try {
@Suppress("UNCHECKED_CAST")
return creator.get() as T
} catch (e: Exception) {
throw RuntimeException()
}
}
}
通过@Inject
来注入构造实例,但构造方法中需要提供Map
类型的creators
。这个时候可以使用@IntoMap
,为了匹配Map
的类型,需要定义一个@MapKey
的注释
@Target(AnnotationTarget.FUNCTION, AnnotationTarget.PROPERTY_GETTER, AnnotationTarget.PROPERTY_SETTER)@Retention(AnnotationRetention.RUNTIME)
@MapKey
annotation class ViewModelKey(val value: KClass<out ViewModel>)
然后再到对应的组件下使用,例如匹配MainVM
@Moduleabstract class MainModule {
@Binds
@IntoMap
@ViewModelKey(MainVM::class)
abstract fun bindViewModel(viewModel: MainVM): ViewModel
}
这样就提供了Map<Class<MainVM>, MainVM>
的参数类型,这时我们自定义的ViewModelFactory
就能够被成功注入。
例如basic
模块里面的BaseDaggerActivity
abstract class BaseDaggerActivity<V : ViewDataBinding, M : BaseVM> : AppCompatActivity() {protected lateinit var viewDataBinding: V
@Inject
lateinit var viewModelFactory: ViewModelProvider.Factory
protected val viewModel by lazy { ViewModelProvider(this, viewModelFactory)[getViewModelClass()] }
...
}
当然,别忘了MainVM
也需要使用@Inject
来声明注入
class MainVM @Inject constructor() : BaseVM() { ... }
以上是Dagger
的ViewModel
使用的注入方式。
虽然自定义的ViewModelFactory
是公用的,但是对于不同的ViewModel
还是要手动定义不同的bindViewModel
方法。
而对于Hilt
却可以省略这一步,甚至说上面的全部都不需要手动编写。我们需要做的是只需在ViewModel
的构造函数上添加@ViewModelInject
。
例如上面的MainVM
,使用Hilt
的效果如下
class MainVM @ViewModelInject constructor() : BaseVM() { ... }
至于Hilt
为什么会这么简单呢?我们不要忘了它的本质,它是在Dagger
之上建立的,本质是为了帮助我们减少不必要的样板模板,方便开发者更好的使用依赖注入。
在Hilt
中,上面的实现会自动帮我们生成,所以才会使用起来这么简单。
如果你去对比看AwesomeGithub上的feat_dagger与feat_hilt两个分支中的代码,就会发现使用Hilt
明显少了许多代码。对于简单的Android
类来说就是增加几个注释而已。
目前唯一一个比较不理想的是对于@Providers
的使用,构造方法中不能有参数,如果在用Dagger
使用时已经有参数了,再转变成Hilt
可能不会那么容易。
庆幸的是,Dagger
与Hilt
可以共存。所以你可以选择性的使用。
但是整体而言Hilt
真香,你只要尝试了绝不会后悔~
AwesomeGithub
AwesomeGithub是基于Github的客户端,纯练习项目,支持组件化开发,支持账户密码与认证登陆。使用Kotlin语言进行开发,项目架构是基于JetPack&DataBinding的MVVM;项目中使用了Arouter、Retrofit、Coroutine、Glide、Dagger与Hilt等流行开源技术。
除了Android原生版本,还有基于Flutter的跨平台版本flutter_github。
以上是 Android Dagger替换成Hilt 的全部内容, 来源链接: utcz.com/a/33354.html