美文网首页Android开发经验谈Android技术知识Android补给站
Android Hilt实战初体验: Dagger替换成Hilt

Android Hilt实战初体验: Dagger替换成Hilt

作者: 午后一小憩 | 来源:发表于2020-07-17 07:37 被阅读0次

    在组件化AwesomeGithub项目中使用了Dagger来减少手动依赖注入代码。虽然它能自动化帮我们管理依赖项,但是写过之后的应该都会体会到它还是有点繁琐的。项目中到处充斥着Component,这让我想起了传统MVP模式的接口定义。

    简单来说就是费劲,有许多大量的类似定义。可能google也意识到这一点了,所以前不久发布出了Hilt

    Hilt

    为了防止没听说过的小伙伴们一头雾水,首先我们来了解下Hilt是什么?

    HiltAndroid的依赖注入库,可减少在项目中执行手动依赖项注入的样板代码。

    Hilt通过为项目中的每个 Android 类提供容器并自动管理其生命周期,提供了一种在应用中使用 DI(依赖项注入)的标准方法。HiltDagger 的基础上构建而成,因而能够具有 Dagger 的编译时正确性、运行时性能、可伸缩性。

    那么有的小伙伴可能会有疑问,既然已经有了Dagger那为什么还要Hilt的呢?

    HiltDagger的主要目标都是一致的:

    1. 简化 Android 应用的 Dagger 相关基础架构。
    2. 创建一组标准的组件和作用域,以简化设置、提高可读性以及在应用之间共享代码。
    3. 提供一种简单的方法来为各种构建类型(如测试、调试或发布)配置不同的绑定。

    但是Android中会实例化许多组件类,例如Activity,因此在应用中使用Dagger需要开发者编写大量的样板代码。Hilt可以减少这些样板代码。

    Hilt做的优化包括

    1. 无需编写大量的Component代码
    2. Scope也会与Component自动绑定
    3. 预定义绑定,例如 ApplicationActivity
    4. 预定义的限定符,例如@ApplicationContext@ActivityContext

    下面通过AwesomeGithubDagger来对比了解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要做的很简单,添加几个注释

    @HiltAndroidApp
    class 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)
    }
    

    module的部分先不说,后面会提及

    下面看Hilt的实现

    @AndroidEntryPoint
    class MainActivity : BaseHiltActivity<ActivityMainBinding, MainVM>() { ... }
    

    Hilt要做的是添加@AndroidEntryPoint注释即可。

    惊讶,结合上面的,两个注解就替换了Dagger的实现,现在是否体会到Hilt的简洁?对新手来说也可以降低很大的学习成本。

    目前Hilt支持下面Android

    1. Application (@HiltAndroidApp)
    2. Activity
    3. Fragment
    4. View
    5. Searvice
    6. 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
    }
    

    不同的是需要添加@InstallInActivityComponent::class用来表明该模块作用范围为Activity

    其实上面这块对ViewModel的注入,使用Hilt时会自动帮我们编写,这里只是为了展示与Dagger的不同之处。后续会提到ViewModel的注入。

    @Providers

    提供一个FragmentManager的实例,首先是Dagger的使用

    @Module
    class 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类并且构造方法不能有参数。

    @ActivityContextHilt提供的预定限定符,它能提供来自与ActivityContext,对应的还有@ApplicationContext

    提供的组件

    对于之前提到的@InstallIn会关联不同的Android类,除了@ActivityComponent还有以下几种

    对应的生命周期如下

    同时还提供了相应的作用域

    所以Hilt的默认提供将大幅提高开发效率,减少许多重复的定义

    ViewModel

    最后再来说下ViewModel的注入。如果你使用到了Jetpack相信少不了它的注入。

    对于Dagger我们需要自定义一个ViewModelFactory,并且提供注入方式,例如在AwesomeGithubcomponentbridget模块中定义了ViewModelFactory

    @Module
    abstract 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

    @Module
    abstract 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() { ... }
    

    以上是DaggerViewModel使用的注入方式。

    虽然自定义的ViewModelFactory是公用的,但是对于不同的ViewModel还是要手动定义不同的bindViewModel方法。

    而对于Hilt却可以省略这一步,甚至说上面的全部都不需要手动编写。我们需要做的是只需在ViewModel的构造函数上添加@ViewModelInject

    例如上面的MainVM,使用Hilt的效果如下

    class MainVM @ViewModelInject constructor() : BaseVM() { ... }
    

    至于Hilt为什么会这么简单呢?我们不要忘了它的本质,它是在Dagger之上建立的,本质是为了帮助我们减少不必要的样板模板,方便开发者更好的使用依赖注入。

    Hilt中,上面的实现会自动帮我们生成,所以才会使用起来这么简单。

    如果你去对比看AwesomeGithub上的feat_daggerfeat_hilt两个分支中的代码,就会发现使用Hilt明显少了许多代码。对于简单的Android类来说就是增加几个注释而已。

    目前唯一一个比较不理想的是对于@Providers的使用,构造方法中不能有参数,如果在用Dagger使用时已经有参数了,再转变成Hilt可能不会那么容易。

    庆幸的是,DaggerHilt可以共存。所以你可以选择性的使用。

    但是整体而言Hilt真香,你只要尝试了绝不会后悔~

    AwesomeGithub

    AwesomeGithub是基于Github的客户端,纯练习项目,支持组件化开发,支持账户密码与认证登陆。使用Kotlin语言进行开发,项目架构是基于JetPack&DataBinding的MVVM;项目中使用了Arouter、Retrofit、Coroutine、Glide、Dagger与Hilt等流行开源技术。

    除了Android原生版本,还有基于Flutter的跨平台版本flutter_github

    如果你喜欢我的文章模式,或者对我接下来的文章感兴趣,你可以关注我的微信公众号:【Android补给站】

    或者扫描下方二维码,与我建立有效的沟通,同时能够更方便的收到相关的技术推送。

    相关文章

      网友评论

        本文标题:Android Hilt实战初体验: Dagger替换成Hilt

        本文链接:https://www.haomeiwen.com/subject/ucswhktx.html