Dagger Hilt 中 WorkerFactory 的创建问题分析与解决方案

问题背景

在 Android 应用开发中，使用 Dagger Hilt 进行依赖注入时，开发者可能会遇到 WorkerFactory 在 APK 构建中无法正确创建的问题。具体表现为：使用 @HiltWorker 注解的 Worker 类在 Android Studio 构建中工作正常，但在 APK 构建时却抛出 NoSuchMethodException 异常，提示无法实例化 Worker 类。

问题分析

这个问题通常与以下几个因素有关：

1. 多模块项目结构：当 Worker 类位于非主应用模块时，Hilt 的依赖注入机制可能无法正确聚合所有必要的绑定。

2. 构建过程差异：Android Studio 构建和 APK 构建（如通过 Fastlane）可能使用不同的构建配置或优化策略，导致 Hilt 注解处理器行为不一致。

3. WorkerFactory 初始化时机：WorkManager 的初始化配置需要在 Application 生命周期早期完成，否则可能导致 Worker 工厂无法正确注册。

技术细节

在标准 Hilt 实现中，@HiltWorker 注解会生成一个多绑定（multibinding）的 WorkerFactory，它会收集所有被 @HiltWorker 标记的 Worker 类。当这个机制失效时，通常是因为：

• Hilt 注解处理器没有正确运行
• 多模块间的绑定关系没有被正确聚合
• ProGuard/R8 优化移除了必要的构造函数

解决方案

方案一：自定义 WorkerFactory

当 Hilt 的自动 WorkerFactory 创建机制失效时，可以手动实现 WorkerFactory：

class BleWorkerFactory @Inject constructor(
    private val bleServiceModule: BleServiceModule,
) : WorkerFactory() {
    override fun createWorker(
        appContext: Context, 
        workerClassName: String, 
        workerParameters: WorkerParameters
    ): ListenableWorker? {
        return when (workerClassName) {
            RemoteConfigSyncWorker::class.java.name -> 
                RemoteConfigSyncWorker(appContext, workerParameters)
            HardwareReportWorker::class.java.name -> 
                HardwareReportWorker(appContext, workerParameters, bleServiceModule)
            ActivitySyncWorker::class.java.name -> 
                ActivitySyncWorker(appContext, workerParameters, bleServiceModule)
            else -> null
        }
    }
}

然后创建一个委托工厂来整合多个 WorkerFactory：

@Singleton
class MyDelegatingWorkerFactory @Inject constructor(
    bleWorkerFactory: BleWorkerFactory
) : DelegatingWorkerFactory() {
    init {
        addFactory(bleWorkerFactory)
    }
}

方案二：正确配置 Application 初始化

在 Application 类中正确初始化 WorkManager 配置：

@HiltAndroidApp
open class RandomHiltApplication : MyApplication() {
    
    @EntryPoint
    @InstallIn(SingletonComponent::class)
    interface WorkerFactoryEntryPoint {
        fun workerFactory(): MyDelegatingWorkerFactory
    }

    override fun onCreate() {
        val workManagerConfiguration: Configuration = Configuration.Builder()
            .setWorkerFactory(EntryPoints.get(this, WorkerFactoryEntryPoint::class.java).workerFactory())
            .setMinimumLoggingLevel(Log.VERBOSE)
            .build()
        WorkManager.initialize(this, workManagerConfiguration)
        super.onCreate()
    }
}

最佳实践建议

1. 模块依赖检查：确保主应用模块直接依赖包含 Worker 类的模块。

2. 构建配置验证：检查 APK 构建配置是否与 Android Studio 构建一致，特别是关于 Hilt 注解处理器的配置。

3. ProGuard/R8 规则：确保必要的 Worker 构造函数不被优化移除：

-keepclassmembers class * extends androidx.work.Worker {
    public <init>(android.content.Context,androidx.work.WorkerParameters);
}

-keepclassmembers class * extends androidx.work.CoroutineWorker {
    public <init>(android.content.Context,androidx.work.WorkerParameters);
}

4. 初始化时机：WorkManager 的初始化应尽早完成，最好在 Application 的 onCreate() 方法中。

总结

Dagger Hilt 中的 WorkerFactory 创建问题通常源于多模块项目的绑定聚合问题或构建配置差异。当自动机制失效时，采用自定义 WorkerFactory 是一个可靠的解决方案。开发者应特别注意模块间的依赖关系和初始化时机，确保依赖注入系统能够正确识别和实例化所有 Worker 类。

对于复杂的多模块项目，建议在开发早期就建立完整的 Worker 测试流程，包括 APK 构建后的功能验证，以尽早发现和解决这类问题。