除State hoisting外，Jetpack Compose还有哪些可用的状态管理方案？

Jetpack Compose 常用状态管理方案 #

除了状态提升之外，Compose生态有多种成熟的跨组件共享状态方案，可以解决多层级透传回调的维护问题，对应你熟悉的Flutter Provider + ChangeNotifier 场景的替代方案也非常丰富：

官方原生方案 #

• CompositionLocal：Compose 框架原生提供的跨组件树传递数据的能力，定位和Flutter的Provider几乎完全一致。你可以在组件树的上层通过CompositionLocalProvider提供状态实例，下游任意层级的Composable都可以直接获取到对应的值，不需要逐层传递。如果配合可观察类型（比如MutableState、StateFlow）使用，状态变化时也会自动触发关联的下游组件重编，非常适合共享主题配置、局部通用状态这类场景。
• ViewModel + StateFlow/LiveData：Android官方推荐的架构层状态管理方案，ViewModel的生命周期和宿主（Activity、Fragment、导航目的地）绑定，不会随Composable的重编意外销毁。你可以把状态存放在ViewModel的StateFlow或者MutableState属性中，修改状态的逻辑也全部封装在ViewModel内部，需要访问状态的Composable只要通过viewModel()、hiltViewModel()等扩展方法向上查找获取ViewModel实例即可，既不需要透传ViewModel，也不需要传递任何回调方法。

第三方拓展方案 #

• Hilt 作用域绑定：如果使用Google官方的依赖注入框架Hilt，可以把自定义的状态类绑定到指定作用域（比如Application全局作用域、Activity作用域、导航图作用域），需要使用状态的组件直接注入对应实例即可，自动匹配生命周期，适合需要全局共享、或者特定页面范围共享的状态场景。
• 其他社区方案：还可以根据开发习惯选择MVI架构类的Orbit、Mavericks，或者响应式类的RxJava、MobX等方案，都可以和Compose做适配。

选型推荐 #

• 中小规模应用优先选择 ViewModel + StateFlow + Hilt 组合：这是Android官方主推的方案，生态完善、学习成本低，和现有Android开发体系适配性最好，可以覆盖90%以上的业务场景，完全解决多层级透传回调的痛点。
• 如果是需要在组件树内部共享局部状态、不需要和架构层逻辑联动的场景，优先选择CompositionLocal，使用习惯和Flutter的Provider高度一致，上手成本极低。
• 不建议中小项目为了状态管理额外引入Redux、自定义MVI这类复杂度较高的第三方库，会增加不必要的学习和维护成本。

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