北京
多年以来，Android开发者都遵循一条简单的原则：把屏幕状态放入ViewModel。这不仅成了通用的建议，更是演变为Android架构的基石之一。ViewModel逐渐承担起几乎所有职责——UI状态、导航状态、业务逻辑、仓库协调与协程作用域，统统被塞了进去。
这套架构确实解决了实际问题。ViewModel能够跨配置变更留存数据，SavedStateHandle能在进程被杀死后恢复状态，Activity和Fragment的代码因此变得轻量许多。对于传统的View体系而言，这曾是正确无误的解法。但Android架构正在静默地演进，不是通过移除ViewModel，而是通过让每一种状态都找到更合适的归属者。
Compose引入的最大架构变革并非某个新API，而是一个全新的提问方式：这段状态天然该归谁管？官方指南对此给出了清晰的表述：状态应当尽可能贴近它的消费端。这意味着，开发者不必再习惯性地将每一个UI数值都推入ViewModel，只有当某个层级确实需要拥有该状态时，才需要向上提升。
Compose通过remember让这一理念变得不言自明。一个搜索框输入的文字、当前展开的卡片、对话框的可见性乃至滚动位置，它们的本质是UI关注点而非业务逻辑。把这些状态保留在UI内部会提升代码的局部性，因为状态恰好存活在它被使用的地方。当需要跨Activity重建留存时，rememberSaveable即可应对，不必为此动用一个ViewModel。
这种架构转向同样清晰地呈现在了官方文档中。Android不再将ViewModel描述为UI状态的通用容器，而是引入了更宽泛的“状态持有者”概念。文档明确指出，你可以通过ViewModel或者一个普通类来实现状态持有者。这是一个重要的区分：ViewModel只是状态持有者的一种实现方式，而不再是后者的定义。
官方指南进一步将状态持有者分为了两类，这反映出一种更为精确的所有权模型。ViewModel被明确界定为业务逻辑的状态持有者，其职责集中于仓库协调与业务规则。而可复用的UI组件通常应当采用普通的UI状态持有者，不再依赖ViewModel。Navigation 3也延续着完全相同的方向，导航参数归属于NavKey，UI状态则可以归于组件自身，这标志着状态归属的边界正变得前所未有的清晰。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
