将项目从Guice DI迁移到Hilt/Dagger DI需要遵循哪些特定规则？

前置准备 #

• 确认项目AGP版本≥7.0，选择和AGP、Kotlin版本匹配的Hilt版本，避免编译兼容问题
• 在根目录build.gradle引入hilt-android-gradle-plugin，在对应模块的build.gradle引入Hilt核心依赖，全程保留现有Guice的依赖和配置，保证迁移过程中原项目可正常编译运行
• 迁移前跑完全量单元测试、集成测试，留存基准测试结果，方便迁移过程中快速定位问题

增量迁移步骤 #

• 第一步：配置Hilt全局入口
  给自定义Application类添加@HiltAndroidApp注解，同时保留原有Guice Injector初始化逻辑，两套DI框架可并行运行，互不影响业务逻辑
• 第二步：自顶向下迁移组件
  优先迁移系统级组件（Activity、Service、BroadcastReceiver、ContentProvider），给对应组件添加@AndroidEntryPoint注解，原有JSR-330标准的@Inject注入字段不需要修改，Hilt可直接识别并完成注入
• 第三步：迁移Guice绑定配置
  将Guice的@Module类改为Hilt的@Module + @InstallIn注解，指定对应绑定的作用域组件（比如全局单例绑定指定@InstallIn(SingletonComponent::class)），原有@Provides方法、@Singleton作用域注解可直接复用，不需要修改逻辑
• 第四步：迁移自定义作用域与特殊绑定
  原有Guice自定义作用域可直接对应转换为Hilt自定义Component，也可优先复用Hilt原生提供的ActivityScoped、FragmentScoped、ViewModelScoped等作用域，减少自定义代码量
• 第五步：清理Guice残留
  每完成一个模块的迁移后跑对应模块的测试，确认逻辑无误后删除该模块的Guice相关配置，全量迁移完成后移除Guice依赖以及Application中的Guice初始化代码

自动化迁移方案 #

目前已有成熟的半自动化迁移方案，可覆盖80%以上的常规迁移场景

• Android Studio 内置迁移工具：可自动识别项目中的Guice Module、注入点、绑定配置，一键批量转换为Hilt对应配置，仅自定义作用域、多绑定、动态绑定等特殊场景需要手动调整
• 基于AST语法树的自定义转换脚本：适合大型多模块项目的批量迁移，可根据项目特有配置自定义转换规则，大幅降低手动修改的工作量
• 注意：所有自动化转换结果都需要经过测试验证，避免特殊绑定场景下的逻辑异常

内容的提问来源于stack exchange，提问作者Jitin