Compose中Screen级Composable传入完整ViewModel是否为合理方案？

1. 全屏Composable直接传入完整ViewModel是否合理？ #

对于ScreenA这类路由级的纯业务全屏页面，直接传入完整ViewModel是合理且业内通用的方案。这类页面本身和业务逻辑强绑定，没有复用需求，直接持有ViewModel可以避免大量参数透传，也不用频繁修改函数签名。如果该Composable后续有复用需求（比如要嵌入其他页面、做成通用组件），则不要传完整ViewModel，仅传入必要数据和回调即可。 #

2. 同类数据需要在多个页面访问的处理方式 #

• 如果是全局共享数据（比如用户登录态、APP全局配置），可以使用Application级作用域的单例ViewModel，通过依赖注入框架统一注入到各页面的ViewModel中，避免重复请求和数据不一致
• 如果是多个相邻流程页共享的数据（比如多步注册流程的填写信息），可以给这组页面绑定同一个父导航图作用域的ViewModel，多个页面都能拿到同一个实例，无需跨页面透传参数

3. Composable内部初始化ViewModel能否拿到和其他部分一致的实例？ #

可以。使用官方提供的viewModel()方法（Hilt场景下用hiltViewModel()）初始化时，只要指定的ViewModel作用域一致，就能拿到同一个实例：

• 不指定作用域时默认绑定当前导航目的地的作用域，每个页面拿到独立的ViewModel实例
• 指定父导航图作为作用域所有者，就能拿到对应父图范围下的共享ViewModel实例
• 全局单例ViewModel可以通过依赖注入的@Singleton注解实现，任何位置初始化都是同一个实例

4. 仅传参数的方案适用场景 #

仅传参数的方案不是不可行，是适用场景不同。如果是可复用的子组件、通用业务模块，必须用仅传参数+回调的方案，保证组件无状态、可复用。但路由级全屏页面本身不需要复用，没必要硬套该规则，否则确实会出现参数越来越多、每加一个状态就要修改整条参数传递链路的问题，维护成本极高。 #

5. ViewModel Factory是否为可行解决方案？ #

是。Factory本身就是官方提供的、用于处理ViewModel带参初始化的标准方案。如果需要给ViewModel传入构造参数（比如页面跳转携带的ID、初始配置），用Factory可以合法完成ViewModel的带参实例化，不需要在ViewModel内部写额外的初始化方法。如果使用Hilt这类依赖注入框架，Factory的实现逻辑会被框架自动处理，不需要手动编写Factory代码。 #

内容的提问来源于stack exchange，提问作者Richard Onslow Roper