4. Module懒加载设计：按需绑定、动态模块、条件注入

启动耗时的优化核心在于减少非必要的初始化工作。Hilt 默认的 @Module 绑定会在组件初始化时全部注册，即使某些依赖只在特定界面或特定条件下使用。本章将讲解如何通过延迟绑定、动态组装和条件控制，让 Module 只在真正需要时才被加载，从而降低应用启动的 CPU 和内存压力。

4.1 懒加载的核心原理

Hilt 的依赖图基于 @Module 和 @InstallIn 在编译期生成。若 Module 处于 SingletonComponent 中，其内部的所有绑定都会在 Application 创建时被实例化（即使使用了 @Lazy 或 Provider）。Module 懒加载设计的目标是：将绑定作用域缩小、拆解为按需挂载，而非一次性全量注册。

4.2 按需绑定的三种策略

4.3 动态模块：按需组装的实现流程

动态模块并非真正的热插拔，而是利用 @Module 的 includes 和 @InstallIn 在不同组件树中组装。以下是一个典型流程：

1. 定义基础接口：声明懒加载依赖的抽象 API。
2. 编写子 Module：为每个条件分支编写专属 @Module，并标记不同的 @InstallIn。
3. 创建组装器：使用 @Module(includes = [...] ) 聚合子 Module，并根据 BuildConfig 或运行时配置启用。
4. 在 Activity 或 Fragment 中注入：只在生命周期内使用依赖，不再需要时允许 GC 回收。

// 1. 定义接口
public interface ImageAnalyzer {
    Result analyze(Bitmap bitmap);
}

// 2. 子 Module - 基础版（轻量）
@Module
@InstallIn(ActivityComponent.class)
public abstract class BasicImageModule {
    @Binds
    public abstract ImageAnalyzer bindBasicAnalyzer(BasicImageAnalyzer impl);
}

// 3. 子 Module - 高级版（重型）
@Module
@InstallIn(ActivityComponent.class)
public abstract class ProImageModule {
    @Binds
    public abstract ImageAnalyzer bindProAnalyzer(ProImageAnalyzer impl);
}

// 4. 组装器（根据条件编译）
@Module(includes = {BuildConfig.IS_PRO ? ProImageModule.class : BasicImageModule.class})
@InstallIn(ActivityComponent.class)
public class ImageModuleAssembler {
    // 空 Module，仅用于条件 include
}

4.4 条件注入：@BindsOptionalOf 与 Qualifier 配合

@BindsOptionalOf 允许声明一个可选的绑定，当该绑定存在时注入实例，否则注入 Optional.empty()。这适合控制一些高级特性在低端设备上不加载。

// 声明可选绑定
@Module
@InstallIn(SingletonComponent.class)
public abstract class OptionalModule {
    @BindsOptionalOf
    abstract AdvancedLogger bindOptionalLogger();
}

// 消费方：根据设备等级决定是否提供高级实现
@Module
@InstallIn(SingletonComponent.class)
public class LoggerSelectorModule {
    @Provides
    @Singleton
    public Logger provideLogger(Optional<AdvancedLogger> advancedLogger) {
        if (advancedLogger.isPresent() && Build.MODEL.contains("HighEnd")) {
            return advancedLogger.get();
        }
        return new SimpleLogger();
    }
}

4.5 懒加载决策流程图

下面这张图展示了 Module 懒加载设计的整体决策路径，从编译期到运行时的绑定过程：

4.6 调试与验证

启用 Hilt 的编译时图表输出，可验证 Module 是否被正确限制在子作用域：

// 在 build.gradle 中配置
android {
    defaultConfig {
        javaCompileOptions {
            annotationProcessorOptions {
                arguments["dagger.guicedebug"] = "true"
                arguments["dagger.moduleBindingGraph"] = "full"
            }
        }
    }
}

运行后查看 build/generated/source/kapt/debug/ 下的 Hilt_*.java 文件，确认 @Module 的组件归属。若 Module 出现在 SingletonComponent 的绑定图中，说明懒加载未生效。

4.7 性能优化与稳定性

• 避免碎片化过度：Module 拆得太细会导致组件图编译时间增加，且容易产生循环依赖。保持每个作用域 3-5 个 Module 为佳。
• 使用 @Reusable 代替 @Singleton：@Reusable 允许 Hilt 在同一个组件内复用实例，但不会跨组件保留。适合那些创建成本中等、偶尔使用的依赖。
• 验证内存泄漏：将大型依赖移入 Fragment 作用域后，务必在 Fragment 销毁时确认引用被清除。可借助 LeakCanary 检测。