是否应为Activity、Broadcast Receiver与Services单独划分模块？

1. 表示层的职责边界被过度扩大 #

你把Broadcast Receiver、Service这类Android系统级组件直接放到表示层，这是典型的职责混淆。表示层的核心职责是处理UI渲染、用户交互逻辑，而Broadcast Receiver、Service属于和系统交互的基础设施组件，应该归到单独的platform或core模块里。把它们塞到表示层会导致：

• 表示层臃肿不堪，混杂了系统交互、业务逻辑、UI逻辑，后续维护成本飙升
• 组件耦合度极高，比如要修改后台任务逻辑，得动表示层代码；要复用业务逻辑到其他模块，根本抽不出来

2. Activity的逻辑承载方式错误 #

你认为Splash的授权检查、Main的路由配置不属于UI逻辑，这点没错，但这些逻辑也不该直接放在Activity里。在Jetpack Compose架构中，Activity应该是轻量的UI容器，只负责初始化Compose环境、承载NavHost这类导航容器。把授权检查、路由配置硬塞Activity会导致：

• Activity变成“上帝类”，代码混乱，比如SplashActivity里既有系统Intent处理，又有授权校验，还有导航逻辑，测试时无法单独验证某一部分
• 逻辑无法复用，比如其他页面要做授权校验，只能复制粘贴代码

3. 没抓住多模块架构的核心目标 #

多模块拆分的本质是高内聚、低耦合，按职责而非组件类型拆分。你现在把所有无UI组件都丢到表示层，等于没做真正的模块拆分——既没法隔离业务逻辑和系统逻辑，也没法实现模块间的独立编译、复用。比如后续要替换授权逻辑，你得修改表示层的Activity代码；要把业务逻辑用到其他项目，根本没法单独导出。

4. Compose架构适配的误区 #

你提到在AppTheme块里配置逻辑，这违背了Compose的UI与逻辑分离原则。AppTheme是用来统一UI样式的地方，在这里放业务/系统逻辑会让UI代码不纯，后续调试时很难区分样式问题和逻辑问题。正确的做法是：逻辑放在ViewModel或专门的用例类中，通过状态流（比如StateFlow）驱动UI，UI只负责根据状态渲染内容。

修正建议 #

• 按职责拆分模块：
  • domain层：放业务规则、用例（比如授权校验用例、路由决策用例）
  • data层：放数据处理、仓库、API调用
  • presentation层：放Compose UI、ViewModel、导航组件
  • platform层：放Activity、Service、Broadcast Receiver、系统权限处理等Android专属组件
• 瘦身Activity：SplashActivity只初始化Compose，授权逻辑交给AuthUseCase，ViewModel调用后返回状态，UI根据状态触发导航；MainActivity只负责加载NavHost，路由配置交给导航控制器和ViewModel
• 系统组件解耦：Broadcast Receiver监听系统事件后，只负责把事件传递给domain层的处理类，不直接处理业务逻辑

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