2. 组件化原则与设计目标
SystemUI 作为 Android 系统中进程常驻、职责复合的系统级应用，长期面临模块耦合度高、单测覆盖率低、定制分支合并困难等痛点。组件化改造的第一要务不是引入框架，而是确立一组可被团队强制执行的设计原则。本章围绕 单一职责、接口隔离、依赖反转、可测试性、可替换性 五项核心原则，分析它们如何决定模块边界、系统分层、组件职责、数据流/控制流与信任链路，并给出选型权衡、风险点、落地步骤与验收标准。
2.1 五大核心原则概述
| 原则 | 核心要义 | 对 SystemUI 的价值 |
|---|---|---|
| 单一职责（SRP） | 一个模块只负责一个业务维度 | 将状态栏、导航栏、通知面板、锁屏拆分为独立组件，避免交叉修改 |
| 接口隔离（ISP） | 不强迫依赖方使用它不需要的接口 | 组件间通信契约最小化，降低耦合面，提升可替换性 |
| 依赖反转（DIP） | 抽象不依赖细节，细节依赖抽象 | 通过依赖注入容器解耦组件创建与生命周期管理 |
| 可测试性 | 设计时考虑自动化验证可行性 | 为每个组件提供模拟桩接口，使单测可脱离 SystemUI 进程运行 |
| 可替换性 | 组件可在不修改调用方的前提下被整体替换 | 支持 ODM/OEM 定制组件而不破坏框架契约 |
实践要点：这五项原则并非独立选择，而是一个递进体系——SRP 决定模块拆分粒度，ISP 决定模块间通信宽度，DIP 决定控制流方向，可测试性验证前三条是否落地，可替换性则是对整体架构弹性的最终检验。
2.2 模块边界与系统分层
单一职责原则是模块划分的第一准则。在 SystemUI 语境下，每个系统级 UI 区域应当对应一个独立组件：
- 状态栏组件（StatusBar）：负责信号图标、电池、时钟、通知图标展示，不处理导航逻辑。
- 导航栏组件（NavigationBar）：负责三键导航或手势指引条，不处理通知展开。
- 通知面板组件（NotificationPanel）：负责通知列表与快捷开关，不处理锁屏认证。
- 锁屏组件（Keyguard）：负责解锁认证与锁屏信息展示，不处理系统导航。
这些组件在物理上处于同一进程，但在逻辑上必须拥有独立的包路径、资源集、生命周期作用域与测试套件。模块边界通过 包名隔离 与 Gradle 模块拆分 强制执行：
// 组件模块划分示例（Gradle 项目结构）
SystemUI/
├── app/ # 应用壳模块
├── core/ # 核心基础设施模块
│ ├── di/ # 依赖注入容器
│ ├── eventbus/ # 事件总线
│ └── logging/ # 日志工具
├── services/ # 核心服务模块
│ ├── servicemanager/ # 系统服务代理
│ └── datamanager/ # 数据管理层
├── feature-statusbar/ # 状态栏组件模块
├── feature-navigationbar/ # 导航栏组件模块
├── feature-notificationpanel/ # 通知面板组件模块
├── feature-keyguard/ # 锁屏组件模块
└── feature-qs/ # 快捷设置组件模块系统分层则依据 依赖方向 自下而上分为四层：基础设施层 → 核心服务层 → 业务组件层 → 组合层。下层不依赖上层，上层通过抽象接口依赖下层。