提升你的 Android 应用：Jetpack Compose 架构模式

Source: Dev.to

我们称之为 Android 架构模式的是什么？

它们是组织 Android 应用代码的推荐方式，使其：

• 更易维护
• 更具可扩展性
• 更易测试
• 更易在团队中理解

使用 Kotlin + Jetpack Compose，Google 推崇响应式和单向的数据流架构。

主要角色

@Composable 函数

• 仅展示状态
• 不包含业务逻辑
• 响应状态变化

@Composable
fun HomeScreen(state: HomeState) {
    Text(text = state.title)
}

ViewModel

• 管理 UI 状态
• 包含展示层逻辑
• 在配置更改时存活
• 暴露 StateFlow 或 LiveData

class HomeViewModel : ViewModel() {
    private val _state = MutableStateFlow(HomeState())
    val state = _state.asStateFlow()
}

业务规则

• 用例（UseCases）——与 Android 无关
• 仓库
  • API（Retrofit）
  • 数据库（Room）

推荐的 Compose 架构

UI (Compose)
   ↓
ViewModel
   ↓
Repository
   ↓
Data Source (API / DB)

用户操作流程

@Composable
fun HomeScreen(viewModel: HomeViewModel = viewModel()) {
    val state by viewModel.state.collectAsState()

    Button(onClick = { viewModel.loadData() }) {
        Text("Cargar")
    }
}

此方法的优势

• 责任划分清晰
• 易于测试
• 适用于 Compose
• 在大型应用中非常流行

MVI（Model‑View‑Intent）模式

• Intent：用户操作
• State：屏幕的完整状态
• Reducer：转换状态

Intent → ViewModel → Reducer → New State → UI

sealed class HomeIntent {
    object LoadData : HomeIntent()
}

data class HomeState(val loading: Boolean = false)

优势

• 状态不可变
• 流程可预测
• 适用于复杂 UI

劣势

• 代码更多，复杂度提升
• 不仅是 UI 模式，而是完整的架构

分层组织

• Presentation：Compose + ViewModel
• Domain：用例
• Data：仓库、API、数据库

特性

• 内层不依赖外层。
• UI 不了解数据细节。

优势

• 可扩展
• 易于测试
• 适用于大型项目

MVVM + 单向数据流 + StateFlow + Jetpack Compose

• ViewModel 作为唯一的状态源
• Compose 只观察并渲染
• 状态不可变
• 事件与状态分离

Event → ViewModel → State → Compose UI

这避免了 bug，使 UI 可预测。

按项目类型的推荐

结论

• Jetpack Compose 改变了对 UI 的思考方式。
• MVVM 仍然是基础。
• 状态是应用的核心。
• 单向数据流减少错误。

有用链接

• Jetpack Compose 文档
• 应用架构指南
• Kotlin 中的 Clean Architecture