前言
DI(Dependency Injection)，即“依赖注入”：组件之间依赖关系由容器在运行期决定，形象的说，即由容器动态的将某个依赖关系注入到组件之中。依赖注入的目的并非为软件系统带来更多功能，而是为了提升组件重用的频率，并为系统搭建一个灵活、可扩展的平台。通过依赖注入机制，我们只需要通过简单的配置，而无需任何代码就可指定目标需要的资源，完成自身的业务逻辑，而不需要关心具体的资源来自何处，由谁实现。
最近业务同学需要接入谷歌推的Hilt框架。因为哔哩哔哩的业务上很容易出现业务层面的交叉，而因为项目完成了大量的组件化拆分。由于不希望业务之间产生相互引用，所有在技术评估完成之后我们决定由我们部门来对Hilt进行接入。
接入Hilt
摘自官方文档 使用 Hilt 实现依赖项注入
首先先声明下dagger.hilt.android.plugin相关的plugin。
buildscript {
...
dependencies {
...
classpath 'com.google.dagger:hilt-android-gradle-plugin:2.35.1'
}
}
其次由于hilt一大部分相关的都是基于kapt的代码生成逻辑，所以我们要在使用到hilt的模块的build.gradle中都定义如下相关的。
...
apply plugin: 'kotlin-kapt'
apply plugin: 'dagger.hilt.android.plugin'
android {
...
}
dependencies {
implementation "com.google.dagger:hilt-android:2.35.1"
kapt "com.google.dagger:hilt-android-compiler:2.35.1"
}
我们需要给我们的Application增加一个注解。
@HiltAndroidApp
class ExampleApplication : Application() { }
根据官方接入文档哦，我们组只要把Application只要打上@HiltAndroidApp的注解，就可以完成这部分接入能力了。
Hilt在组件化
但是但是官方有个声明是这样的。
Hilt 代码生成操作需要访问使用 Hilt 的所有 Gradle 模块。编译 Application 类的 Gradle 模块需要在其传递依赖项中包含所有 Hilt 模块和通过构造函数注入的类。
从这部分说明上来看，这个注解最好是能放在com.android.application模块中, 这样就能保证依赖到所有的子模块中去了。
但是实际我们在使用过程中，由于com.android.application模块还是有一些代码量的，而由于kapt代码生成机制，需要先将kotlin代码转化成java代码，之后才能生成ast语法树。
根据ci上的实验结果，在com.android.application模块下kapt耗时在30s左右，而整体编译时间大概为3分钟左右。这种耗时我个人觉得还是属于不能接受的。
所以我们调整了下这部分代码。这次建立了一个壳module，这边只有HiltApplication的注解相关。然后将这个module依赖了所有业务仓库，按照编译逻辑来说，基于gradle task的depend逻辑，他会在application模块编译之前，所有业务模块编译之后，这样能保证hilt生成的代码逻辑正常。
同时由于是一个空工程，我们把空工程定义为bundle-kapt，所以整体来说对于编译速度影响会变到最小。让各位大佬看下我们后续的优化结果。
上述是我最后截图出来的结果，我们将一个耗时大概30s的任务优化到3s，其实效果上来说已经非常明显，达到我们想要的预期了已经。
当然如果后续hilt支持了ksp之后，这部分速度应该可以更快，毕竟我么可以直接抛弃java语法树了吗。
出现了点小问题
这两天业务方实际在使用过程中，突然反馈说貌似我们接入的Hilt貌似不行啊，进入到页面直接崩溃了。
有一说一，一脸懵逼。先看看异常吧。初一开始我以为是kapt没有生成好或者别的什么原因导致的。
com.xxxxxx.xxxxxx}: java.lang.ClassCastException: xxxxx.DaggerHiltApplication_HiltComponents_SingletonC$ActivityRetainedCImpl$ActivityCImpl cannot be cast to xxxxx_GeneratedInjector
只能一步步调试咯，我打开项目开启编译项目，之后进入蛮长的等待过程中。10分钟过去了终于好了。
由于Hilt使用了kapt，所以很自然的打开了build/generated/source/kapt文件路径，之后我看了下DaggerHiltApplication_HiltComponents_SingletonC这个类的生成。
ActivityRetainedCImpl从这里我大概猜测出了一小部分Hilt原理,通过收集不同子Module的抽象接口，然后把这部分能力聚合在HiltApplication中，举个例子Hilt_BangumiDetailActivityV3这个就是一个子业务内的DI注入的一个类的实现。
突然这个时候我想到了一件事哦，也就是说我们的bundle-kapt模块，其实它的实际编译产物会根据接入业务的不同而产生实际的变更。也就是说虽然这个模块的代码没有发生变更，但是由于子业务增加了注解和代码变更，导致了这个模块的kapt还是需要重新执行，这样才能保证输出的产物是变化的。
然而我们的项目之前由于工程结构太庞大了，可能有30-40个Module,所有我们将一部分没有变更的代码产物化，也就是基于commit变成了一个个aar或者jar发布到了远端。之后根据commit来重新定向到产物。
而bundle-kapt这个模块也很不幸，被当做了一个静态模块，变成了一个远端的产物，之后即时业务添加了再多的注入相关的，因为bundle-kapt没有参与编译，所以注入的能力就出错了。
总结
我们团队算是一个比较好玩的团队了，团队有两位巨佬，一位大佬专门负责编译相关的，基本gradle方面都懂了，而且玩的也很花里胡哨的。另外一位大佬lancet作者，gradle方面懂得多就不提了，上一篇文章最后的问题也是这位大佬帮忙处理的。
而其他的组员其实人也都非常的不错，而且我们团队也做了很多东西。比如之前介绍的网络优化，资源混淆插件优化，图片中间件，动态化，自研的路由框架，还有blkv自研的ky存储框架等等。
同样的我们的kt版本还有agp版本都算是业内比较靠前的了。一方面是大佬能cover住，另一方面我们也会在这部分投入人力，我们也已经开始用viewbinding的代理啦
以上就是哔哩哔哩在Hilt组件化的使用技术探索的详细内容，更多关于哔哩哔哩Hilt组件化使用的资料请关注Devmax其它相关文章！