为何仍有开发者在Jetpack Compose中使用ViewModel？

当然可以完全不用ViewModel写代码 #

对于简单的UI场景——比如按钮点击计数、输入框文本状态、临时UI切换逻辑——只用remember、rememberSavable和mutableStateOf这类工具完全足够，代码更简洁，上手成本也低，非常适合初学者练手或小型功能开发。

为什么很多开发者仍选择ViewModel？ #

这跟“舍不得旧知识”关系不大，而是ViewModel能解决Compose原生状态工具的核心痛点：

• 状态生命周期更稳定：ViewModel的生命周期绑定到界面组件（如Activity/Fragment），不会因为Compose重组、屏幕旋转、配置变化（比如语言切换）丢失状态。虽然rememberSavable也能处理配置变化，但它要求状态必须可序列化，对于复杂对象（比如自定义数据类、带业务逻辑的对象）处理起来很麻烦；而ViewModel无需序列化，直接持有对象更灵活。
• 业务逻辑与UI解耦：如果你的界面涉及网络请求、数据库操作、复杂数据计算这类业务逻辑，把这些代码放在ViewModel里，Composable只负责根据状态渲染UI，能避免UI代码臃肿，也能防止重组时重复执行逻辑（比如不小心在Composable里发起网络请求，导致每次重组都调用一次）。
• 跨组件状态共享：当多个Composable甚至多个页面需要共享同一状态（比如用户登录信息、购物车数据），ViewModel可以作为统一的状态容器，不用通过参数层层传递状态，代码结构更清晰。

怎么选择用不用ViewModel？ #

• 简单UI、临时状态：优先用remember/rememberSavable，减少代码量。
• 复杂业务逻辑、需要跨组件共享状态、或状态需在配置变化后保留：选择ViewModel，让代码更健壮、可维护。

内容的提问来源于stack exchange，提问作者Reza Zeraati