1. 系统 UI 架构演进背景
SystemUI 是 Android 系统最接近用户的图形层，承担状态栏、导航栏、通知面板、锁屏、快捷设置、屏幕截图等核心交互。在 Android 早期版本中，SystemUI 采用典型的单体架构：所有功能模块打包在一个进程中，共享全局资源与生命周期。这种方式在功能较少时尚可维持，但随着 Android 版本迭代和多设备形态（手机、平板、折叠屏、车载）出现，单体架构的瓶颈日益突出。
1.1 原生 SystemUI 痛点分析
| 维度 | 具体问题 | 对业务的影响 |
|---|---|---|
| 耦合度 | 状态栏、通知、快捷设置、锁屏等模块代码混杂在同一进程，无明确模块边界；全局变量、事件总线滥用，导致“改 A 坏 B”频发。 | 开发效率下降，回归测试成本激增；多人并行开发冲突率高。 |
| 性能 | 主线程同时处理渲染、触摸、广播、动画；通知数量多时可导致丢帧、启动黑屏。 | 用户感知掉帧、交互延迟；低端设备体验恶化。 |
| 可定制性 | OEM 定制需要修改 SystemUI 源码，无法热插拔模块，升级 AOSP 时出现大量合并冲突。 | 设备厂商维护成本高，版本升级慢。 |
| 测试与稳定性 | 无法独立测试子模块；一个模块的崩溃会导致整个 SystemUI 进程退出（黑屏或重启）。 | 稳定性指标难以提升；自动化测试覆盖率低。 |
关键风险点： 单体架构下，通知面板的泄漏或死锁会直接阻塞状态栏的触摸事件，用户可能无法下拉状态栏。此类级联故障在系统 UI 层是不可接受的。
1.2 业界模块化趋势
移动平台系统 UI 的架构演化经历了“单体 → 分层 → 微内核/插件化”三个阶段。Android 社区和头部设备厂商已普遍推动模块化拆分：
- Google: Project Mainline — 将 SystemUI 的部分子组件（如字体渲染、网络栈）转为可独立更新的 APEX 模块，降低系统升级步伐对厂商的依赖。
- 微内核思想 — 参考 Fuchsia 和 HarmonyOS 的架构，将核心交互（手势、窗口）与业务视图（状态栏、通知）隔离到不同进程或 sandbox 中，减少故障影响范围。
- 插件化/组件化 — 基于 Service + Binder 的跨进程通信，允许 OEM 像搭积木一样替换导航栏、锁屏等模块，同时保持核心框架稳定。
- 编译时模块化 — 通过 Gradle 多 module 工程分解代码，结合接口隔离（ISP）实现编译期解耦，运行时仍可在同一进程，但已具备未来分离为独立进程的基础。
选型权衡： 进程级拆分会引入 Binder 通信开销和同步复杂度，适合高稳定性、高定制性需求的模块（如锁屏、导航手势）；而编译时模块化+同进程更适合追求低延迟的模块（如状态栏图标渲染）。本课程后续章节将展示如何基于模块边界与信任链路做出折中选择。
1.3 拆分前的单体架构图
下图展示了经典 Android SystemUI 的单体架构：所有模块运行在 com.android.systemui 进程内，直接依赖框架服务（WindowManager、NotificationManager、ActivityManager 等），模块间通过内部 API、全局单例、EventBus 交互。红色虚线框内的区域即是我们将要拆分的范围。
1.4 章节小结与课程路线
本章揭示了 SystemUI 单体架构的三大核心痛点（耦合、性能、可定制性），并点明了业界向模块化/微内核演进的趋势。从下一章开始，我们将围绕以下主线展开本课程的 30 章内容：
| 章节范围 | 主题 | 重点产出 |
|---|---|---|
| 第 2–8 章 | 模块边界识别与系统分层设计 | 模块划分方案、分层架构图、接口契约 |
| 第 9–16 章 | 组件职责与数据流/控制流重构 | 每个模块的职责矩阵、跨进程 Binder 定义 |
| 第 17–22 章 | 信任链路与安全边界 | 权限模型、IPC 鉴权、崩溃隔板策略 |
| 第 23–27 章 | 选型权衡与风险应对 | 进程 vs. 同进程、同步 vs. 异步、OEM 兼容性 |
| 第 28–30 章 | 落地步骤与验收标准 | Milestone 计划、性能基线、稳定性验收用例 |