MVVM & compose

Abstract

本文旨在总结pos开发过程中使用compose ui进行业务开发时，对mvvm思想在pos系统中实践的总结。

Intro

在日常的 Android 开发中，MVVM 架构和 Compose UI 已经成为主流的开发方式。在我的 POS 系统的实际开发过程中，观察发现将 MVVM 的分层思想和 Compose UI 的响应式特性结合起来，不仅让界面和业务逻辑分工更明确，也让代码更容易维护和扩展。比如在购物车、update等模块，界面只负责展示和收集用户操作，具体的业务处理都交给 ViewModel。对于校招同学来说，理解和掌握这些实践经验，有助于更快上手实际业务开发。通过归纳总结，自己整理的MVVM相关知识如下。

MVVM的核心构成

MVVM 模式由三个核心组件构成：

Model: 负责数据层，提供原始数据
ViewModel: 处理业务逻辑，维护 UI 状态
View: 负责 UI 渲染，响应用户交互

MVVM的单向数据流

在 MVVM 中，数据流动遵循单向原则：

ViewModel 管理状态（State）
View 观察并展示状态
用户操作触发 Action
Action 传递给 ViewModel 处理
ViewModel 更新状态，循环往复

ViewModel -> State -> View -> Action -> ViewModel

Compose UI 中的 MVVM 实践方式

Compose UI 作为现代化的 View 层实现：

响应式更新：
- 自动观察 ViewModel 中的状态变化
- 基于状态变化进行 UI 重组
职责分离：
- View 层：专注于 UI 展示逻辑
- ViewModel 层：专注于业务逻辑和状态管理
解耦效果：
- UI 修改仅需关注 View 层
- 业务逻辑修改仅需关注 ViewModel 层
- 降低模块间耦合度，提高代码可维护性

Method

在一个业务场景中，如果需要实现一个功能，由用户行为触发某些视图的更新，实现思路如下：

UI 层只负责 UI 展示，并收集状态，展示不同的交互效果

通常定义在名为，view文件夹 / View.kt / Component.kt 等结尾，的文件中
*通过@Composable 定义组件；通过@preview预览对应组件

基础要素

在 View 层收集状态
利用 collectAsState() 观察状态变化，实现数据驱动 UI 更新的闭环
在 View 层完成状态到 UI 的映射
利用when (State.value) 进行条件判断，并根据对应的state展示对应需要展示的ui

向上传递用户事件

*最基础的事件上报方式：*直接调用 ViewModel 方法
*传递必要的参数给 ViewModel：*传递带参数的事件

保持组件内部状态

利用remember +mutableStateOf() 传递状态变化的值，比如：

UI 临时状态
动画状态
用户输入缓存
仅影响UI展示的状态

避免 ⚠️

不在 View 层处理业务逻辑
不在 View 层直接修改状态
不在 View 层保存全局状态
避免组件间强耦合
不在 View 层处理业务逻辑
不在 View 层直接修改状态
不在 View 层保存全局状态
避免组件间强耦合

ViewModel 负责更新视图变化相关的业务逻辑

通常定义在名为'ViewModel'等结尾的文件夹中

通过@Composable 定义组件；通过@preview预览对应组件

基础要素

负责业务逻辑处理、状态管理和数据转换，确保 UI 层专注于展示和交互。
作为 UI 层与数据层（Repository、UseCase 等）之间的桥梁，协调数据流动。

状态管理

内部使用MutableStateFlow 保存和更新状态，保证状态的可变性和响应性。
对外仅暴露 StateFlow，确保外部只能读取状态，不能直接修改，提升封装性和安全性。

事件处理

接收来自 UI 层的用户事件（如点击、输入等），在 ViewModel 内部处理业务逻辑。
根据事件结果更新 MutableStateFlow，驱动 UI 层自动响应状态变化。

数据转换与生命周期感知

负责将数据层返回的原始数据转换为 UI 层所需的状态或数据结构，简化 UI 层逻辑。
ViewModel 生命周期与 UI 组件（如 Activity、Fragment、Composable）绑定，自动管理资源释放，避免内存泄漏。