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

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

## Hilt

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

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

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

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

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

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要做的很简单，添加几个注释

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

}

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

下面看Hilt的实现

@AndroidEntryPointclass MainActivity : BaseHiltActivity() { ... }复制代码

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的默认提供将大幅提高开发效率，减少许多重复的定义

最后再来说下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等流行开源技术。

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

如果你喜欢我的文章模式，或者对我接下来的文章感兴趣，你关注一下我吧

我们还有《Android学习、面试；文档、视频资源》，可复制链接后用石墨文档 App 或小程序打开链接或者私信我资料领取。

https://shimo.im/docs/TG8PDh9D96WGTT8W