Jetpack Compose实验性API在生产环境中的稳定性及应用建议

首先明确结论：不建议在核心业务流程中使用pullRefresh、ModalBottomSheet这类实验性API，但如果是非核心的边缘功能，可以谨慎尝试，前提是做好风险预案。

为什么不推荐核心场景用？ #

实验性API的本质是Google还在迭代打磨的功能，存在几个明确风险：

• 稳定性不足：可能隐藏未被发现的bug，比如下拉刷新的状态异常、底部弹窗的动画卡顿或布局错位，这些问题在生产环境会直接影响用户体验。
• 行为易变更：后续版本可能调整API参数、回调逻辑甚至整体实现，比如之前部分实验API的状态管理方式就发生过大幅改动，升级后可能导致功能直接失效。
• 存在废弃风险：Google有权直接废弃实验性API，没有强制兼容承诺，到时候你要么停留在旧版本（错过其他稳定功能的更新），要么花大量时间重构代码。

如果已经用了或者一定要用，怎么应对后续风险？ #

• 封装隔离实验代码：把实验性API的使用包裹在自定义组件或模块里，用抽象层对外提供功能。比如写一个CustomPullRefresh组件，内部调用官方的pullRefresh，外部业务代码只和CustomPullRefresh交互。一旦官方API变更或废弃，只需要修改这个组件的实现，不用动整个业务逻辑。
• 跟踪官方更新动态：定期查看Compose的版本更新日志、官方文档，关注这些实验API的状态变化——比如是否标记为“即将稳定”，或者有没有推出替代的稳定API。
• 提前准备降级方案：针对使用实验API的功能，提前备好替代实现。比如ModalBottomSheet可以提前写一个基于传统View或自定义Compose组件的版本，pullRefresh可以准备基于SwipeRefreshLayout的封装，一旦实验API不能用，能快速切换到稳定方案。
• 限制使用范围：只在非核心功能里用，比如应用的帮助页、设置页的下拉刷新，或者次要功能的底部弹窗，就算出问题，也不会影响用户的核心操作流程。

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