🧸 依赖注入基础

📌 什么是依赖注入

依赖注入 (Dependency Injection, DI) 是一种设计模式，它让一个对象不再自己创建它所依赖的其他对象，而是由外部容器或框架“注入”进来。简单说就是：“我要什么，你给我，我不 new”。

在 Android 中，依赖注入通常通过构造函数、字段或方法将依赖传入。例如 Car(engine: Engine) 而不是 Car() { engine = Engine() }。

🎯 为什么需要依赖注入

依赖注入让代码更灵活、可测试、可维护。以下是核心优势：

没有 DI，类会变成“硬骨头”，难以替换、难以测试。尤其在大型 Compose 项目中，DI 让 UI 与业务逻辑干净分离。

⚠️ 手动依赖注入的缺点

手动 DI 就是自己写“工厂”或“构造器”来组装依赖。在小项目中勉强可用，但规模一大，问题就暴露了：

• 🧱 样板代码爆炸 —— 每个依赖都要手动 new，重复代码多。
• 🕸️ 依赖管理混乱 —— 容易忘记传递某个依赖，或搞错生命周期。
• 🐌 难以扩展 —— 新增一个依赖，要修改多处工厂代码。
• 🧪 测试依然麻烦 —— 手动替换 Mock 需要改很多地方。
• 📦 作用域失控 —— 单例、ActivityScope 等需要自己维护。

📊 手动 DI vs 框架 DI (Hilt) 架构对比

手动 DI 就像自己搬砖盖房子，而 Hilt 就像有了施工队和图纸 —— 省心、规范、不易塌。在 Compose 中，Hilt 配合 hiltViewModel() 让注入变得优雅。

📄 手动 DI 代码示例 (缺点展示)

// ❌ 手动依赖注入：每个地方都要 new，耦合严重
class Car {
    private val engine = Engine()          // 硬编码依赖
    private val battery = Battery()        // 难以替换
    fun start() { engine.run() }
}

// 测试时想用 MockEngine？必须修改 Car 内部！
// 如果 Engine 又依赖 SparkPlug，手动创建更加痛苦

// ✅ Hilt 注入：清晰、可测试、自动管理
@HiltViewModel
class CarViewModel @Inject constructor(
    private val engine: Engine,
    private val battery: Battery
) : ViewModel() {
    fun start() { engine.run() }
}

// 在 Compose 中直接使用
@Composable
fun CarScreen(viewModel: CarViewModel = hiltViewModel()) {
    // ...
}