MVVM架构下Android与iOS项目导航的正确实现方案

很多团队落地MVVM时最容易在导航实现上踩分层的坑，判断实现是否合理的核心标准永远是不打破层间职责边界：既不能把平台依赖漏到业务层，也不能把业务判断逻辑塞回视图层，三个可选方案的实际适配性可以逐一拆解： #

各方案的问题与适配性分析 #

• 方案1：ViewModel决定导航的触发时机以及目标目的地
  这是很多开发者落地MVVM时最容易踩的坑：为了图方便把Navigator、路由跳转的平台API（比如Android的Intent、Fragment事务，iOS的ViewController跳转方法）直接注入ViewModel。这种实现的硬伤非常明显：
  1. 业务层直接耦合了移动端平台API，ViewModel的可测试性彻底丧失——跑单元测试时必须依赖模拟器/真机环境，没法做纯JVM/纯Swift的逻辑测试；
  2. View层完全失去了导航的适配灵活性：ViewModel根本感知不到当前是手机还是平板、是单窗口还是分屏模式、是冷启动进入还是深度链接唤起，只能硬写跳转逻辑，很难适配多设备的差异化导航需求。
• 方案3：View决定导航的触发时机以及目标目的地
  这种实现本质是把MVVM退化成了老式MVC：所有和业务绑定的导航判断（比如“登录接口返回成功才能跳首页”“订单提交成功且用户是会员才跳会员权益页”）都被塞回了Activity/ViewController的视图代码里，ViewModel退化成了只存数据的空壳，完全失去了拆分业务逻辑、复用逻辑的价值。
• 方案2：ViewModel决定导航的触发时机，由View决定目标目的地
  这是完全匹配MVVM分层原则的正确实现方式，核心是把导航拆成两个彻底解耦的环节：
  1. 触发时机的决定权归ViewModel：ViewModel只负责基于业务逻辑判断“现在应该发一个语义化的导航事件”，比如发LoginSuccess、OrderSubmitted(orderId: "xxx")、UserProfileRequested这类完全和平台无关的纯语义事件，通过单向可观察的数据流（比如Android的SharedFlow、Swift的AsyncStream）推送给View层，全程不持有任何平台相关的导航引用；
  2. 目标目的地的决定权归View：View层拿到这些语义化事件后，再结合当前的导航栈状态、设备屏幕规格、全局路由配置，决定具体要跳转到哪个页面、用什么转场动画、需要携带什么参数。比如同样是收到LoginSuccess事件，手机端可以跳转到独立的首页Activity，平板端可以直接在分屏的右侧区域加载首页内容，完全不需要ViewModel做任何修改。

这种实现方式既保留了ViewModel的可测试性（测试时只需要验证对应业务场景下是否触发了正确的语义事件即可，完全不需要启动移动端运行环境），也保证了视图层对导航逻辑的全量控制权，不会因为业务逻辑和导航逻辑的耦合导致后续维护成本飙升。全局导航拦截、跳转埋点、深度链接路由匹配这类通用逻辑，都可以集中在View层的路由模块统一维护，完全不需要改动ViewModel里的业务代码。

落地时需要注意一个细节：不要把目的地信息绑定到ViewModel发出的导航事件里，比如不要把“要跳转到HomeActivity”的参数塞进事件对象，否则会直接退回到方案1的耦合问题。

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