使用Jetpack Compose做单Activity应用是否可行？何时需多Activity/Fragment？

首先可以明确：仅用单个Activity托管所有@Composable页面、通过Compose Navigation完成导航的方案是完全可行的，也是当前Android官方推荐的主流生产级架构。
这套架构的优势非常明显：

• 规避了原生Activity/Fragment的生命周期、通信、状态同步等常见问题，开发成本大幅降低
• Compose Navigation已经覆盖了原有导航组件的全部核心能力：包括路由传参、转场动画、返回栈管理、深度链接适配等，完全可以满足绝大多数应用的页面导航需求
• 单Activity上下文统一，不需要处理多页面的主题适配、权限申请结果分发、全局状态同步等问题，维护成本更低

虽然单Activity架构可以覆盖绝大多数场景，但遇到以下情况时，引入多Activity或Fragment是更合理的选择：

• 完全隔离的独立入口场景：比如首次启动的隐私授权页、登录注册页、外部唤起的专属业务页，这类页面和主业务栈完全独立，不需要共享主Activity的上下文和状态，用独立Activity可以更方便地做栈管理，比如登录完成后直接销毁登录页，不需要操作主页面的返回栈。
• 系统特性强依赖场景：比如需要开启画中画模式的视频页、需要固定屏幕方向的活动页、需要配置独立沉浸式规则的全屏页，这类场景在Manifest里给独立Activity配置对应属性，比在单Activity里动态切换配置更稳定，也不会影响其他页面的展示规则。
• 混合开发兼容场景：如果应用需要接入未做Compose适配的第三方原生SDK、需要复用存量的Fragment业务组件、或者嵌入其他跨端框架页面，直接用独立Activity托管或者在Compose中通过AndroidView嵌入Fragment，是比全部重构为Compose成本低很多的方案。
• 大型应用模块化隔离场景：多团队协作的大型应用中，不同业务线需要做组件级隔离，不同业务线的页面用独立Activity托管，可以避免业务模块之间的上下文耦合，也更方便做单模块的独立调试、灰度发布。
• 高安全等级页面场景：比如支付页、身份实名认证页这类敏感页面，用独立Activity可以更方便地实现防截屏、安全键盘适配、独立内存保护等安全策略，也能避免敏感数据和主业务页面状态产生关联导致泄露。

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