Android开发中无Fragment与单Fragment Activity的选型疑问

不存在被官方或者全行业普遍认可的强制规则要求所有Activity必须承载Fragment，你和身边同行默认遵循的是特定技术演进阶段形成的团队开发范式，不是普适性的硬性编码标准。

薄Activity + 单Fragment模式的实际优势 #

很多人对这个模式的认知只停留在“未来加新Fragment扩展方便”，实际上它的价值不止这一点：

• 生命周期与业务逻辑解耦：业务逻辑下沉到Fragment后，不会和Activity的窗口级生命周期强绑定。不管后续是做折叠屏适配、平板分栏、车机/大屏适配，还是需要把这个页面复用到其他页面容器里，都可以直接复用整个Fragment，不用花时间把散落在Activity各个生命周期回调里的业务逻辑剥离出来。很多时候开发者判断“永远不会有这类需求”，只是基于当前手机单端的开发场景做的判断，Android系统的落地形态一直在扩展，这类预判往往不准。
• 降低测试成本：Fragment可以通过FragmentScenario实现隔离测试，不需要依赖Activity的完整窗口环境，测试用例运行速度更快，覆盖业务逻辑时也不用关心Activity层面的窗口属性设置、ActionBar配置、全局权限回调这类和业务无关的逻辑。
• 统一导航逻辑：如果团队统一用Fragment作为业务页面载体，配合Navigation组件管理跳转，所有页面的转场动画、参数传递、返回栈逻辑、路由拦截（比如登录态校验、权限校验）都可以走同一套逻辑，不会出现Activity跳转、Fragment跳转两套逻辑并存带来的维护割裂问题。

不需要强行套Fragment的场景 #

如果同时满足以下几个条件，直接把业务逻辑写在Activity里完全是合理实现，不算代码问题：

• 页面本身极轻量，比如启动页、单一权限申请引导页、弹窗式的确认页，总代码量不超过百行，没有复杂的状态流转和交互逻辑
• 项目本身没有统一的Fragment导航规范，存量代码里大量存在直接在Activity中实现业务的写法，不需要为了单个页面强行统一范式
• 明确这个页面不存在复用、跨容器适配的可能性，也不需要做独立的隔离单元测试

同行评审的处理建议 #

不要把「必须嵌套Fragment」作为阻塞同事代码合入的卡点，除非这条规则明确写在团队共同认可的成文编码规范里。如果没有成文约定，可以把单Fragment模式的长期收益作为优化建议提出来，但不要把小圈子默认的开发习惯当成必须遵守的铁则——Android原生API从一开始就支持直接在Activity中实现布局和业务逻辑，不存在“写法错误”，只有是否适配当前项目维护需求的区别。

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