第2章 Android模块现状分析：模块耦合模式、常见职责混叠案例、重构代价
当前Android项目在模块划分上普遍缺乏明确的边界定义，分层模型模糊、组件职责交错，导致数据流与控制流混乱、信任链路不透明。本章从实际项目痛点出发，系统梳理三种典型耦合模式、两个高频职责混叠场景，并量化重构代价，为后续引入单一职责原则提供现状基线。
2.1 模块边界定义的缺失
模块边界是职责隔离的基础。但在大多数Android工程中，模块间的划分仅以功能命名（如network、ui），而没有严格定义以下边界要素：
- 依赖方向：跨模块引用无约束，业务层直接依赖数据层实现类。
- 暴露接口：模块内部类被随意
public，外部可绕过API直接访问。 - 资源隔离：资源文件（layout、drawable、string）被所有模块共享，修改影响范围不可控。
- 数据契约：模块间传递的数据模型使用同一实体类，导致底层变更波及上层。
风险提示：缺乏边界定义时，任何模块的内部重构都可能引发连锁崩塌，开发人员不得不记住大量隐性约定，新人上手成本陡增。
2.2 分层模型的缺失与模块耦合模式
理想的分层模型应遵循“依赖倒置”原则，但现状中常见三种耦合模式，直接破坏了层间信任链路：
| 耦合模式 | 表现形式 | 典型代码特征 |
|---|---|---|
| 共享资源耦合 | 多个模块直接引用同一资源文件或数据库表 | |
| 跨模块直接引用 | A模块中直接new B模块的实现类 | |
| 隐式依赖耦合 | 通过全局静态变量、SharedPreferences或EventBus传递状态 | |
数据流/控制流现状：隐式依赖导致信任链路断裂——上层无法确认底层数据是否已被篡改，控制流被EventBus的广播打散，单元测试需模拟全局环境。
2.3 常见职责混叠案例
职责混叠是耦合模式的直接后果。以下两个案例在Android项目中反复出现：
| 案例 | 混合职责 | 业务影响 |
|---|---|---|
| 网络层同时承担数据缓存 | Retrofit接口中直接调用Room保存响应，或使用Interceptor做磁盘缓存 |
网络切换时缓存策略无法独立变更；离线模式需要同时修改网络库和数据库代码 |
| UI层携带复杂业务逻辑 | Activity/Fragment中直接处理数据校验、状态机切换、日志上报 | UI重绘与业务逻辑耦合，导致测试覆盖率低；替换UI框架需重写全部业务代码 |
识别方法：如果一个类或模块的注释中出现“并且”“同时”等词汇（如“网络请求并且缓存结果”），或方法签名参数超过3个，通常就是职责混叠的信号。
2.4 重构代价分析与量化
重构代价不仅指代码修改量，更包括测试回归、团队协作与部署风险。基于多项目经验总结如下：
- 代码修改规模：平均每个接口耦合点需修改3～5个文件，全局耦合链可达20+文件。
- 测试回归成本：耦合模块的单元测试覆盖率通常低于20%，手动回归需2～3人天。
- 发布风险：修改一个共享资源可能导致其他模块在线上出现资源未找到异常（
Resources$NotFoundException）。 - 团队协作阻滞：团队成员修改同一模块文件时，合并冲突率提升40%。
风险点：大部分团队在重构初期会低估耦合深度，导致拆分解耦时出现“拆不动”或“拆一个模块崩一片”的局面。因此，现状分析必须量化耦合度（如通过
gradle dependencies输出依赖图，统计循环引用数）。
2.5 现状小结与落地第一步
通过上述分析，我们可以为后续章节的单一职责落地建立基线：
- 边界定义：现状是无边界的，需在下一章给出
ModuleContract定义模板。 - 分层模型：当前无强制分层，需引入
Data → Domain → Presentation三层隔离。 - 组件职责：每个模块应只负责一个业务维度或基础设施能力。
- 数据流/控制流：必须用单向数据流（如UDF）替换隐式事件。
- 信任链路：通过接口而非实现类建立依赖，上层只信任暴露的API。
验收标准（本章对应）：团队能够用一张现状图（如上SVG）识别出当前项目中最严重的3个耦合点，并依据“修改范围/测试成本/风险等级”为每个点打分，形成重构优先级列表。这是第3章开始重构的前置条件。