3. 模块边界定义方法
模块边界定义是 SystemUI 拆分最关键的环节——边界划得过粗则拆分无意义，划得过细则引入大量跨模块通信开销。本章围绕三种互补的边界定义方法展开：功能域分析（回答“有哪些候选模块”）、职责矩阵（回答“每个模块该做什么”）、模块边界划分决策树（回答“最终边界划在哪里”）。三者形成一条从识别到分配再到裁决的完整决策链路。
3.1 功能域分析
功能域分析从系统用例与功能需求出发，将 SystemUI 分解为若干高内聚、低耦合的功能集合。分析过程分为三个步骤：
- 系统功能分解——将 SystemUI 按用户场景和系统事件拆解为独立功能单元，例如「锁屏管理」「通知聚合」「快速设置」「导航栏交互」「壁纸引擎」。
- 依赖关系识别——绘制功能单元之间的调用、数据、事件依赖图，标记强依赖（必须同步调用）、弱依赖（可异步或延迟）和无依赖。
- 内聚性评估——对每个候选功能集合计算功能相似度与变更关联度，若内部功能经常因同一需求同时修改，则表明内聚性高，适合划入同一模块。
实践要点：功能域分析不应只看当前代码的物理位置（package/class），而要基于逻辑职责重新组织。例如 StatusBar 既包含通知图标又包含系统状态图标，分析后应识别为两个不同的功能域，因为它们的变更频率和数据来源差异很大。
3.2 职责矩阵
职责矩阵将功能域分析得出的候选模块与系统职责进行交叉映射，发现职责重叠、遗漏或不合理分配。矩阵的行是模块/组件，列是职责/功能点，单元格标记关系强度：● 主责、○ 参与、- 无关。
| 模块 \ 职责 | 锁屏解锁 | 通知管理 | 快速设置 | 导航手势 | 壁纸渲染 |
|---|---|---|---|---|---|
| LockScreenManager | ● 主责 | - | - | - | ○ 参与 |
| NotificationController | - | ● 主责 | ○ 参与 | - | - |
| QuickSettingsPanel | - | ○ 参与 | ● 主责 | - | - |
| NavigationHandler | - | - | - | ● 主责 | - |
| WallpaperEngine | - | - | - | - | ● 主责 |
通过职责矩阵可以快速发现两种典型问题：
- 职责重叠：两个模块同时对同一职责标记「主责」，说明边界模糊，需要合并或明确分层。
- 职责缺失：某系统级职责在矩阵中无任何模块标记「主责」，说明当前设计遗漏了该能力。
3.3 模块边界划分决策树
职责矩阵输出候选职责分配后，最终边界划分需要通过决策树进行结构化裁决。决策树从四个维度对每个候选边界进行评分：
- 变更频率：两个功能域的变更触发条件是否独立？若经常一起变更，倾向于合并；若独立变更，倾向于拆分。
- 复用价值：该功能域是否会被其他模块或外部系统复用？高复用价值应独立成模块。
- 技术独立性：功能域是否依赖特定的硬件、系统服务或第三方库？强技术绑定可作为一个独立的安全边界。
- 团队协作：功能域是否由不同团队维护？团队边界应尽量与模块边界对齐，减少跨团队协调成本。
常见陷阱：决策树不是简单的“多数决”投票。当变更频率和技术独立性冲突时（例如某功能域变更频繁但深度绑定系统内核），应优先保障技术独立性，将内核接口封装为抽象层，再考虑拆分。盲目追求“按变更频率拆分”会导致模块间接口膨胀，最终得不偿失。
3.4 三种方法的协同关系
功能域分析、职责矩阵、决策树在模块边界定义中并非串行执行一次即可，而是形成迭代收敛的反馈回路。下图展示了三者如何协同输出明确的模块边界：
3.5 落地步骤与验收标准
将上述三种方法落地到 SystemUI 拆分项目中，建议按以下步骤执行：
- 功能域分析工作坊（2–3 天）：召集架构师、开发负责人、产品经理，基于系统用例完成功能分解与依赖关系识别，输出候选模块列表及其依赖图。
- 职责矩阵编制（1–2 天）：将候选模块与 SystemUI 全部职责填入矩阵，标记关系强度，识别重叠与缺失，调整模块清单。
- 决策树评审（半天）：针对每对存在边界争议的模块，运行决策树打分，记录各维度的得分与最终裁决理由。
- 边界定义确认：输出最终模块边界文档，包含模块名称、职责描述、依赖接口、团队归属。
验收标准：
• 每个模块的职责在矩阵中有且仅有一个「主责」标记，无重叠。
• 所有系统级职责在矩阵中至少被一个模块覆盖，无遗漏。
• 决策树打分记录完整，争议边界有明确的权衡说明。
• 模块间依赖形成有向无环图（DAG），消除循环依赖。
• 每个模块的职责在矩阵中有且仅有一个「主责」标记，无重叠。
• 所有系统级职责在矩阵中至少被一个模块覆盖，无遗漏。
• 决策树打分记录完整，争议边界有明确的权衡说明。
• 模块间依赖形成有向无环图（DAG），消除循环依赖。
3.6 风险点与权衡
在模块边界定义阶段，常见以下风险点需要提前应对：
- 过度拆分的风险：决策树若只关注「复用价值」而忽略「变更频率」，可能导致模块粒度极细，接口数量膨胀。建议对每个拆分决策额外评估接口调用链长度，若超过 3 层则考虑合并。
- 职责矩阵的“假精确”：矩阵中的「主责」标记可能因信息不足而误判。在首次编制后，应通过代码审查和运行 trace 验证标记的准确性。
- 团队边界绑架技术边界：当团队架构与功能域不一致时，容易为迁就团队而做出次优的边界划分。建议先按技术最优划分，再通过模块封装层适配团队分工。
通过功能域分析、职责矩阵、决策树三者的迭代配合，SystemUI 的模块边界可以从模糊的直觉判断升级为可追溯、可验证、可调整的结构化决策过程，为后续的组件拆分与演进奠定坚实基础。