寻求从Hilt迁移至Dagger的指南及技术建议

一、移除Hilt相关依赖与注解 #

• 从模块的build.gradle（或build.gradle.kts）中删除Hilt专属依赖，保留基础Dagger依赖（dagger、dagger-compiler）。
• 替换所有Hilt注解：
  • 移除Application类上的@HiltAndroidApp，后续改为手动创建Dagger组件。
  • 去掉页面组件（Activity/Fragment）上的@AndroidEntryPoint，改为在onCreate中手动调用DaggerXXComponent.create().inject(this)完成注入。
  • 将@HiltViewModel、@ViewModelInject替换为普通@ViewModel+构造注入，配合自定义ViewModelProvider.Factory实现注入逻辑。

二、重构Dagger组件与模块 #

• 拆分可移植模块的组件逻辑：把原本绑定Android生命周期的Hilt组件（如ActivityComponent）拆分为独立的Dagger组件，可移植模块仅提供@Module和纯业务依赖绑定，不依赖Android Application或生命周期类。
• 解耦Android系统类依赖：若模块必须用到Context，通过依赖倒置定义ContextProvider接口，模块依赖接口，由集成该模块的应用实现并注入，避免模块直接依赖Android类。
• 定义可复用的基础组件：在可移植模块中创建基础Dagger组件接口（如PortableCoreComponent），包含注入业务类的方法；上层应用可通过继承或依赖该组件，结合自身Application组件完成全局注入。

三、处理Android组件的注入逻辑 #

• 自定义DaggerViewModelFactory，通过构造函数接收Dagger组件，在create方法中利用组件注入ViewModel实例，上层应用在ViewModelProvider中使用该工厂。
• Activity/Fragment的注入：从Application获取全局Dagger组件，或为页面创建子组件，在onCreate中手动调用组件的inject方法完成注入。

四、模块化解耦核心要点 #

• 可移植模块仅作为纯依赖库存在，不包含任何Android生命周期相关的Dagger绑定逻辑，所有Android侧的注入逻辑由集成应用负责实现。
• 使用@Component.Builder或@Component.Factory让上层应用灵活配置模块依赖，比如传入全局Context、业务配置参数等，避免模块硬编码依赖Application。

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