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

本文介绍了Android依赖注入库Hilt,对比了它与Dagger的区别。Hilt减少了手动依赖注入的样板代码,简化了Application、Android类的配置。通过@AndroidEntryPoint、@Inject、@Module、@Binds等注解,Hilt在减少开发者工作量的同时,提高了代码的可读性和维护性。此外,文章还展示了如何在项目中逐步引入和使用Hilt。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

在组件化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,
   
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值