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

时间  2020-07-18
标签 android hilt 实战 体验 dagger 替换 栏目 Android 繁體版
原文   原文链接

2020_07_16_00_05.png

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

简单来讲就是费劲，有许多大量的相似定义。可能google也意识到这一点了，因此前不久发布出了Hilt。git

Hilt

为了防止没据说过的小伙伴们一头雾水，首先咱们来了解下Hilt是什么？github

Hilt是Android的依赖注入库，可减小在项目中执行手动依赖项注入的样板代码。微信

Hilt经过为项目中的每一个 Android 类提供容器并自动管理其生命周期，提供了一种在应用中使用 DI（依赖项注入）的标准方法。Hilt 在Dagger 的基础上构建而成，于是可以具备 Dagger 的编译时正确性、运行时性能、可伸缩性。架构

那么有的小伙伴可能会有疑问，既然已经有了Dagger那为何还要Hilt的呢？app

Hilt与Dagger的主要目标都是一致的：ide

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

可是Android中会实例化许多组件类，例如Activity，所以在应用中使用Dagger须要开发者编写大量的样板代码。Hilt能够减小这些样板代码。函数

Hilt作的优化包括组件化

  1. 无需编写大量的Component代码
  2. Scope也会与Component自动绑定
  3. 预约义绑定，例如 Application与Activity
  4. 预约义的限定符，例如@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要作的很简单，添加几个注释

@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
}

不一样的是须要添加@InstallIn，ActivityComponent::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类而且构造方法不能有参数。

@ActivityContext是 Hilt提供的预约限定符，它能提供来自与 Activity的 Context，对应的还有 @ApplicationContext

提供的组件

对于以前提到的@InstallIn会关联不一样的Android类，除了@ActivityComponent还有如下几种

hilt_1.png

对应的生命周期以下

hilt_2.png

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

hilt_3.png

因此Hilt的默认提供将大幅提升开发效率，减小许多重复的定义

ViewModel

最后再来讲下ViewModel的注入。若是你使用到了Jetpack相信少不了它的注入。

对于Dagger咱们须要自定义一个ViewModelFactory，而且提供注入方式，例如在AwesomeGithub的componentbridget模块中定义了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() { ... }

以上是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等流行开源技术。

awesome_github.png

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

若是你喜欢个人文章模式，或者对我接下来的文章感兴趣，你能够关注个人微信公众号：【Android补给站】

或者扫描下方二维码，与我创建有效的沟通，同时可以更方便的收到相关的技术推送。

Android补给站.jpg

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程