懒加载原理与适用场景：Lazy、Provider 与延迟初始化条件

1. 延迟初始化的本质

Hilt 默认在构造时完成所有依赖的注入，导致应用启动阶段可能触发大量对象创建。懒加载将对象的创建推迟到首次真正使用的时刻，从而压缩启动关键路径上的工作量。

核心机制由两个接口提供：

• Lazy<T>：一个轻量级代理，只在首次调用 .get() 时触发 Dagger 组件树中的对应绑定并缓存结果；后续获取直接返回缓存实例。
• Provider<T>：每次调用 .get() 都会重新进入 Dagger 图重新创建或获取新的实例（作用域不同行为不同）；适用于需要每次获取新实例或不希望缓存的场景。

2. 适用场景工作表

3. 延迟初始化条件模型

并非所有依赖都适合懒加载。决定是否延迟需满足以下条件：

1. 非启动必经路径：对象不在 Application/Activity/Fragment 的 onCreate 关键链上。
2. 非立即需要的回调绑定：例如 LifecycleObserver 或 BroadcastReceiver 必须注册后才能工作。
3. 不产生副作用：对象的构造器不应包含需要确保顺序执行的初始化逻辑（如文件写入、发送埋点）。
4. 作用域明确：单例对象推荐用 Lazy；Factory 模式用 Provider。

4. 代码示例：Lazy 与 Provider 声明

@HiltViewModel
class MainViewModel @Inject constructor(
    private val userRepoLazy: Lazy<UserRepository>,
    private val loggerProvider: Provider<Logger>
) : ViewModel() {

    fun onUserClick(userId: String) {
        // 首次调用时创建 UserRepository（包括数据库连接、网络客户端）
        val repo = userRepoLazy.get()
        repo.fetchUser(userId)
    }

    fun logEvent(event: String) {
        // 每次调用都创建新的 Logger 实例（如果 Logger 未被 @Singleton 标注）
        val logger = loggerProvider.get()
        logger.record(event)
    }
}

5. 懒加载生命周期流程

下图展示了 Hilt 在注入时仅注入代理对象，代理内部维护 Dagger 组件引用，首次调用 .get() 时才触发真正的创建与缓存。

6. 常见错误与调试

• 循环依赖：如果两个类通过 Lazy 相互引用，代理仍会导致死锁。Dagger 编译时能检测循环依赖，但 Lazy 会推迟到运行时才抛出 StackOverflowError。
• 作用域误解：@Singleton 标注的对象通过 Provider.get() 仍然返回同一个实例（因为作用域限定），不会每次新建；如需每次新建应使用 @Reusable 或无作用域。
• 测试痛点：Lazy 在测试中较难断言延迟行为，可借助 dagger.Lazy 的子类型或 Mockito 的 Answer 进行验证。

7. 性能验收指标

以上数据基于中端设备测试，实际效果取决于项目对象图复杂度。建议在实现懒加载后使用 Macrobenchmark 验证启动时间。