🔹 什么是模块化
📌 模块化 = 将大型应用拆分为独立、可复用、职责单一的功能单元。
在 Android / Jetpack Compose 中，每个模块可以是一个 Gradle 子项目（:core:ui、:feature:home 等），拥有自己的代码、资源和依赖。模块之间通过明确定义的接口通信，实现高内聚、低耦合。
🧩 独立编译
📦 按需复用
🔄 并行开发
🧪 独立测试
⚖️ 模块化的优势 & 挑战
✅ 优势
- 编译加速 — 只编译变更模块，Gradle 构建缓存更高效。
- 团队协作 — 不同团队负责不同模块，减少代码冲突。
- 复用性 — 公共模块 (network, design-system) 可在多个 App 中使用。
- 可测试性 — 模块可独立进行单元测试与 UI 测试。
- 关注点分离 — 架构清晰，业务与基础能力解耦。
⚠️ 挑战
- 依赖管理复杂 — 模块间版本、传递依赖需谨慎。
- 初始化开销 — 模块数量增多后，Gradle 配置变重。
- 通信成本 — 模块间接口定义、路由、依赖注入增加设计难度。
- 重构门槛 — 拆分不合理的模块可能带来循环依赖。
- Compose 预览 — 跨模块预览需要额外参数。
📊 单体应用 vs 多模块应用
| 对比维度 | 🏠 单体应用 | 🧱 多模块应用 |
|---|---|---|
| 项目结构 | 单一 app module，所有代码在一起 | 多个 Gradle module（app, core, feature, data…） |
| 编译速度 | 每次改动全量编译，较慢 | 增量编译，仅编译受影响模块，快 ⚡ |
| 代码组织 | 按包名分层 (model, ui, utils)，易混乱 | 按功能/层级拆分，强制隔离，清晰 |
| 复用能力 | 低，代码拷贝或依赖整个工程 | 高，公共模块可发布为内部库 |
| 团队协作 | 合并冲突频繁，代码所有权模糊 | 模块负责人明确，并行开发 |
| 测试策略 | 全量测试，难以单独 mock | 模块级单元测试 + 集成测试 |
| Compose 实践 | 所有 Composable 混在一起，预览依赖全局 | 每个 feature 模块拥有独立 Composable，预览快速 |
🧭 多模块架构示意 (Compose 视角)
⭐ 典型的多模块 Compose 项目：app 壳依赖 feature，feature 依赖 core 基础库
📄 模块化配置示例 (build.gradle.kts)
// :feature:home 模块的 build.gradle.kts
plugins {
id("com.android.library")
id("org.jetbrains.kotlin.android")
id("org.jetbrains.kotlin.kapt") // 如需
}
android {
namespace = "com.example.feature.home"
compileSdk = 34
defaultConfig {
minSdk = 26
}
buildFeatures {
compose = true
}
composeOptions {
kotlinCompilerExtensionVersion = "1.5.8"
}
}
dependencies {
// 依赖 core 模块
implementation(project(":core:ui"))
implementation(project(":core:network"))
implementation(project(":core:data"))
// Compose BOM
implementation(platform("androidx.compose:compose-bom:2024.02.00"))
implementation("androidx.compose.material3:material3")
implementation("androidx.compose.ui:ui")
implementation("androidx.compose.ui:ui-tooling-preview")
debugImplementation("androidx.compose.ui:ui-tooling")
}
✅ 每个模块独立配置，仅引入所需依赖，编译隔离。