在Android Composable函数间共享同一ViewModel是否存在问题？

当多个Composable共享同一个ViewModel实例时，会引发以下几类实际问题：

• 状态污染与不必要重绘：Composable会监听ViewModel中状态的变化，只要状态更新，所有依赖该状态的Composable都会触发重组。如果两个无关的Composable共享VM，其中一个修改了自身需要的状态，另一个不需要该状态的Composable也会被迫重绘，增加不必要的性能开销。比如列表页和设置页共享VM，设置页修改主题状态，列表页也会跟着重组。

• 职责边界模糊，VM逻辑臃肿：ViewModel的设计初衷是绑定特定UI组件的业务逻辑，共享VM会让它承担多个Composable的逻辑职责，违反单一职责原则。原本只负责列表数据加载的VM，可能还要处理详情页的表单提交、弹窗逻辑，代码耦合度飙升，后续维护和迭代难度极大。

• 生命周期不匹配导致的内存泄漏或状态残留：不同Composable的生命周期可能独立（比如处于导航栈的不同页面），当某个Composable被销毁（如页面退出），只要还有其他Composable持有VM引用，VM就不会被回收。这不仅可能造成内存泄漏，还会导致VM中的状态残留，当该Composable重新创建时，会显示旧的状态，不符合用户预期。比如A页面退出后，VM中保存的表单数据还在，再次进入A页面时会自动填充旧数据，引发困惑。

• 状态冲突与竞态条件：多个Composable同时操作VM中的同一状态时，容易出现逻辑冲突。比如两个Composable同时调用VM的increaseCounter()方法，若VM未做线程安全处理，会导致计数错误；或者一个Composable正在发起网络请求，另一个同时触发刷新，导致重复请求或数据覆盖。

• 测试复杂度陡增：共享VM的逻辑关联了多个Composable的行为，测试时无法单独隔离某个Composable对应的VM逻辑。比如要测试列表页的数据加载，必须同时考虑详情页对VM状态的修改逻辑，测试用例变得冗长且难以定位问题。

• 导航场景下的状态混乱：在Jetpack Navigation的多目的地场景中，共享VM会导致页面间状态传递混乱。比如从列表页选中某一项进入详情页，VM中保存了该项ID，当用户返回列表页再选中另一项进入详情页，若VM未重置状态，详情页可能显示前一项的数据，引发错误。

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