第2章 模块拆分核心原则：高内聚低耦合、单一职责、接口隔离、依赖反转原则在拆分中的应用

SystemUI作为Android系统最复杂的系统级应用之一，在拆分前是一个包含通知面板、快速设置、导航栏、锁屏、状态栏、音量面板、输入法切换等数十个功能模块的“巨型单体”。本章围绕四项核心设计原则，阐述如何将这一单体拆分为边界清晰、职责独立、可独立编译测试的子系统。每一项原则都会直接映射到模块边界定义、系统分层策略、组件职责分配、数据流/控制流设计以及最终的验收标准上。

2.1 模块边界：四原则联合驱动的分界方法

模块边界不是随意划分的目录结构，而是由四项原则交叉约束的结果。以下表格展示了每个原则在SystemUI拆分中的具体作用域和判断依据：

原则	在SystemUI拆分中的核心作用	边界判断依据	违反时的典型症状
高内聚	同一模块内的类/方法应当紧密协作完成一个逻辑任务	模块内部调用频率远高于跨模块调用	一个功能修改需要同时改动3个以上模块
低耦合	模块之间通过最小化接口通信，不依赖内部实现	一个模块替换实现类时，其他模块无需修改	修改单模块需回归所有依赖方
单一职责	每个模块只承担一类系统能力	模块描述能用一个“动词+名词”短语概括	模块同时处理UI渲染、数据存储和网络请求
接口隔离	模块对外暴露的接口应细粒度、按调用方定制	接口方法数量≤5且均为该调用方所需	一个接口被多个不相关调用方依赖
依赖反转	高层模块不依赖低层模块的具体实现，双方依赖抽象	模块间依赖方向指向抽象层而非具体类	核心模块直接引用第三方库或硬件抽象层

2.2 系统分层：四项原则如何构建分层模型

在SystemUI模块拆分中，四项原则驱动了典型的三层架构——展示层（UI）、业务逻辑层（ViewModel/Controller）、数据层（Repository/Provider）。每层内部的模块必须满足高内聚，层与层之间通过接口隔离和依赖反转实现低耦合。

2.3 组件职责分配：四原则下的具体实践

在SystemUI中，每个模块的职责必须被精确描述。以下表格展示了四个典型模块如何依据四项原则分配职责：

模块	核心职责	违反原则的常见错误	正确实践
NotificationPanel	渲染通知列表、处理触摸事件、管理展开/折叠动画	在面板类中直接解析通知数据（违反单一职责）	将数据解析委托给NotificationController，Panel只负责UI
QuickSettingsController	管理磁贴状态、处理点击逻辑、维护磁贴列表	直接持有WifiManager实例（违反依赖反转）	通过WifiStateInterface抽象间接操作
NavBarModule	渲染三键/手势导航区域、处理按键事件分发	将返回键逻辑写在NavBar内部（违反高内聚+单一职责）	按键事件分发至NavigationController统一处理
VolumePanelRepository	提供音量流数据、缓存中继从AudioService获取的音量值	暴露getAudioService()方法给UI层（违反接口隔离）	仅暴露getVolume(int streamType)等细粒度方法

2.4 数据流/控制流与信任链路设计

基于四原则拆分后，SystemUI的数据流和控制流应呈现清晰的单向依赖：

• 数据流：Repository（数据源）→ Controller（业务组装）→ UI Panel（展示）。数据始终从下层向上层流动，不反向。
• 控制流：UI Panel（用户操作）→ Controller（业务决策）→ Repository（写/读）。用户操作通过Controller间接访问数据层。
• 信任链路：每个层级的模块只信任直接相邻的抽象接口。UI Panel不信任数据层的具体实现类，只信任Controller提供的接口；Controller不信任Repository的具体实现，只信任Repository接口。

2.5 选型权衡与风险点分析

权衡维度	严格遵循四原则的优势	可能引入的代价	缓解策略
接口数量	每个模块接口小而精，调用方明确	接口类数量增多，初学者理解成本上升	为每个模块编写接口文档和UML关系图
抽象层深度	依赖反转让高层代码稳定，低层可替换	多一层抽象可能带来轻微性能开销	在关键路径（如通知滑动）使用接口缓存或内联
模块体积	高内聚保证模块内的代码聚焦，易维护	支持跨模块公共代码抽取为shared库	提取common-ui、common-utils等共享模块
团队协作	单一职责让各团队边界清晰，避免冲突	跨模块需求需要协商接口定义	采用接口先行（Interface-First）的协作流程

2.6 落地步骤：从原则到可执行计划

1. 原则对齐会：架构师带领SystemUI核心开发同学，针对当前15+功能模块逐一分析违反四项原则的严重程度，输出《违反原则清单》。
2. 边界裁定：依据高内聚和单一职责原则，绘制“模块-职责”二维矩阵，合并或拆分当前子模块。例如将“锁屏媒体控制”从LockScreen中抽出为独立模块。
3. 接口设计：对每个模块执行接口隔离审查，确保对外暴露的方法不超过5个，且方法名不暴露实现细节。
4. 依赖反转重构：在核心模块（如NotificationController）中，将所有直接依赖第三方库或系统服务的地方替换为抽象接口，并将具体实现通过依赖注入框架传入。
5. 编译隔离验证：为每个模块建立独立的Android.bp / BUILD文件，确保模块内代码不产生跨模块直接编译依赖。

典型的Android.bp片段示例，展示模块如何通过静态库实现编译隔离：

// NotificationPanel模块
android_library {
    name: "SystemUI-NotificationPanel",
    srcs: ["src/**/*.kt"],
    static_libs: [
        "SystemUI-NotificationController-interface"  // 只依赖接口，不依赖实现
    ],
    manifest: "AndroidManifest.xml",
}

2.7 验收标准：如何衡量四原则的落地程度

验收维度	验收标准	测量方法
高内聚验证	每个模块内的类调用内聚度≥80%（内部调用占比）	使用静态代码分析工具统计调用关系
低耦合验证	模块间依赖数量≤模块数×1.5	导出依赖矩阵，计算非零依赖项
单一职责验证	每个模块的类名与模块描述完全一致（如NotificationPanel只包含Panel相关类）	检视模块内所有类的命名和包结构
接口隔离验证	每个模块对外接口方法数≤5，且每个接口被使用的类不超过3个	通过接口搜索和使用链分析
依赖反转验证	高层模块不出现直接import低层具体实现类（如直接引用WifiManager）	执行编译期依赖检查脚本