4. 状态栏核心组件与职责
状态栏是用户与系统交互最频繁的区域之一，其设计质量直接影响可用性和稳定性。本章聚焦SystemUI进程内部各核心组件的职责划分与严格边界，包括SystemUI进程本身、StatusBar、NotificationPanel、Keyguard以及QuickSettings、BatteryController等辅助模块。通过清晰的边界定义，避免组件间过度耦合、职责混淆和通信混乱。
4.1 核心组件一览
| 组件 | 进程位置 | 核心职责 | 边界控制要点 |
|---|---|---|---|
| SystemUI 进程 | 独立进程（Android系统服务） | 负责所有系统UI图层的生命周期、窗口管理、事件分发；作为各子模块的宿主 | 不能直接持有Activity或Fragment；通过Binder/Intent与SystemServer通信 |
| StatusBar | SystemUI进程内 | 显示状态图标（信号、电量、时间）、通知图标；处理轻触与滑动操作入口 | 不直接控制面板内容；只决定“显示/隐藏”状态栏自身 |
| NotificationPanel | SystemUI进程内 | 管理通知列表的展开/收起、分组、交互（滑动清除、快速回复等） | 不持有状态栏视图；只处理面板内部UI逻辑 |
| Keyguard | SystemUI进程内 | 锁屏界面控制、安全认证、显示解锁提示；拦截所有触摸事件直至认证通过 | 不能影响状态栏数据模型；权限检查由TrustManager等独立模块负责 |
| QuickSettings | SystemUI进程内 | 快捷开关面板的渲染与交互（Wifi、蓝牙、亮度等） | 不直接读写系统设置；通过SettingsProvider回调 |
| BatteryController | SystemUI进程内 | 监听电池状态并更新图标/百分比；提供充电状态事件 | 只广播不控制UI渲染；UI层订阅状态变化 |
4.2 分层与边界模型
SystemUI内部采用三层边界模型：
- 进程边界：SystemUI进程与SystemServer、Launcher、App进程之间通过Binder或Intent交互。关键约束：SystemUI不能持有SystemServer内部锁；异步回调需保证跨进程生命周期安全。
- 组件边界：每个核心模块（StatusBar、NotificationPanel、Keyguard）拥有独立的ViewModel和UI容器。组件之间通过事件总线（EventBus/LiveData/Flow）传递信号，禁止直接调用对方的View对象。
- 数据边界：状态数据（通知列表、锁屏状态、电池值）集中存放在SystemUI的共享数据仓库（DataRepository）中，各组件只读写仓库的公开字段，不持有对方私有状态。
核心原则：任何跨越组件边界的调用必须经过事件总线或数据仓库；如果发现某组件直接操作另一个组件的内部视图或私有变量，视为架构违规。
4.3 数据流与控制流
以“锁屏状态下收到通知并下拉展开”场景为例，说明组件间数据流与控制流的边界：
- 通知到达：SystemUI进程内的NotificationListenerService接收系统通知，写入DataRepository。
- StatusBar：监听DataRepository中的未读通知数量变化，更新状态栏图标（例如显示小圆点）。不查看通知具体内容。
- Keyguard：监听DataRepository中的安全状态（是否已解锁），若未解锁，则接管触摸事件；下拉手势被Keyguard拦截，不允许展开NotificationPanel。
- 用户解锁后：Keyguard释放触摸控制权，事件回到StatusBar；StatusBar将手势转发给NotificationPanel去展开。
- NotificationPanel：从DataRepository获取通知列表并渲染；展开时通知StatusBar更新自身状态（如隐藏一些图标）。
信任链路：StatusBar信任DataRepository提供的数据一致性，但不信任Keyguard是否会提前释放控制权；关键状态变更必须通过状态机驱动，防止并发状态跳转。
4.4 组件边界架构图（SVG）
4.5 选型权衡
| 决策点 | 方案A（集中式） | 方案B（分布式） | 推荐 |
|---|---|---|---|
| 状态存储 | 单例DataRepository | 每个组件独立ViewModel | 混合：全局状态集中+局部状态独立；通知列表全局，面板滚动位置局部 |
| 事件通信 | 统一事件总线（如LiveData） | 接口回调（Listener模式） | 事件总线避免接口爆炸，但需注意生命周期泄漏（推荐使用SharedFlow） |
| 触摸拦截 | Keyguard全盘接管Window | 分层委托（StatusBar先过滤再转交） | 方案B更灵活，防止Keyguard卡死后无法退出 |
| 模块可测试性 | 需要Mock整个仓库 | 可单独Mock依赖接口 | 方案B略优，但方案A通过接口抽象也能实现 |
4.6 风险点
- 进程死亡重启状态丢失：SystemUI进程如果被kill，DataRepository重置，可能导致Keyguard与StatusBar状态不一致（例如用户已经解锁但状态栏仍显示锁定图标）。
缓解：持久化关键状态（如解锁标志）到SystemServer，进程重启后同步。 - 事件总线死锁：多个组件在同一线程中互相发送事件导致循环依赖。
缓解：所有事件处理必须异步（使用Dispatchers.Default或IO），且禁止在事件回调中发送回同一个事件。 - 跨边界视图访问：开发中容易绕过边界，直接通过
getFragmentManager()获取其他组件的View。
缓解：在Code Review中强制检查：任何findViewById跨模块使用都需架构负责人审批。
常见陷阱：在NotificationPanel中直接访问StatusBar的
mStatusBarWindow来调整高度，会导致组件间强依赖，提高修改成本。必须通过事件总线传递“面板高度”数据。
4.7 落地步骤
- 第一步（1-2天）：定义DataRepository接口和数据模型（通知项、锁屏状态枚举、电池数据类）；所有数据变化使用Kotlin Flow暴露。
- 第二步（2-3天）：将现有StatusBar、NotificationPanel、Keyguard的视图逻辑分离，每个模块创建独立的ViewModel和UI子包；移除直接View引用的代码。
- 第三步（1-2天）：引入事件总线（推荐SharedFlow或Channel），定义事件类型（如
LockStateChanged、NotificationCountUpdated）。 - 第四步（2-3天）：重构触摸事件分发逻辑：StatusBar收到触摸事件后，查询DataRepository中的锁屏状态；若锁定则转发给Keyguard，否则直接处理或传给NotificationPanel。
- 第五步（1天）：编写单元测试覆盖每个组件与DataRepository的交互；编写集成测试验证锁屏→解锁→下拉面板的完整流程。
4.8 验收标准
| 验收项 | 预期结果 | 验证方法 |
|---|---|---|
| 组件间零直接View引用 | 代码扫描未发现跨模块的import com.android.systemui.statusbar.StatusBar |
通过Lint规则或架构测试（Android Architecture Test） |
| 数据仓库读写一致性 | 所有数据变更由DataRepository触达订阅者，无遗漏 | 模拟通知插入后，StatusBar、NotificationPanel、Keyguard都能收到事件回调 |
| 锁屏状态下不可展开面板 | 下拉手势被Keyguard截获，面板不响应 | 通过UI自动化测试：锁定手机，模拟下拉操作，断言面板未出现 |
| 进程重启后状态恢复 | 重启后锁屏状态正确（未解锁时显示锁屏界面） | kill SystemUI进程，观察锁屏界面是否自动显示 |