2. 系统UI分层架构总览

Android 系统 UI 的导航栈与状态栏并非孤立运行，而是依托于经典的四层软件栈。理解每层的边界、责任与信任关系，是后续联动设计的前提。本章将自上而下展开四层结构，并精确标注导航栈（Task 栈）与状态栏（SystemUI StatusBar）所在层级，给出跨层数据流与关键风险点。

四层边界与核心组件

分层职责与信任链路

• 应用层：负责 UI 渲染、动画与手势识别。状态栏的视图树（StatusBarView、NotificationPanelView）在此层构建，但状态栏的展开/折叠策略及虚拟键映射由下层服务触发。
• 框架层：提供窗口管理、输入分发与资源调度。WMS 为状态栏分配固定层级（TYPE_STATUS_BAR），并为导航栏预留专用窗口令牌（NAVIGATION_BAR）。IMS 将触摸事件先分发给 WMS，再由 WMS 决定是否路由到状态栏或当前 Activity。
• 系统服务层：维护导航栈（ActivityRecord 链表）和状态栏的显示策略。AMS 根据用户操作（Home、Recent、Back）改变栈顶 Activity，并通过回调通知 SystemUI 更新导航栏按钮状态。TaskOrganizer 在 Android 12+ 中提供更精细的 Task 栈回调。
• 内核驱动层：提供物理输入与显示基础。注意：状态栏的触摸响应延迟受限于 evdev 到 IMS 的传递路径，导航栈切换的动画帧率受限于 DRM 的 VBlank 机制。

数据流 / 控制流示例：用户点击导航栏返回键

1. 内核输入驱动采集触摸坐标 → 通过 evdev 上报给 IMS。
2. IMS 定位到点击发生在导航栏区域，将事件转发给 WMS 的输入通道（InputChannel）。
3. WMS 确定窗口为 NavigationBar（运行在 SystemUI 进程），通过 Binder 回调 SystemUI 的 onTouchEvent。
4. SystemUI 识别为返回手势，通过 INavigationBar.callback 向 AMS 发起 injectKeyEvent(KEYCODE_BACK) 或直接调用 ActivityTaskManager.finishAffinity()。
5. AMS 弹出当前 Task 栈顶 Activity，并更新栈状态，同时通过 SystemUIStatusBarManager 回调通知状态栏更新最近任务列表或返回按钮可用性。

选型权衡：为何不将导航栈逻辑上移至应用层？

当前分层将导航栈归入系统服务层，是安全与一致性的必然选择；状态栏归入应用层则是因为其 UI 复杂性需要应用级渲染管线支持。

落地步骤（分层视角）

1. 确定四层接口契约：定义 AMS→SystemUI 的回调接口（如 onStackChanged）与 SystemUI→AMS 的控制接口（如 onBackPressed），并制定 Binder 权限。
2. 在系统服务层实现导航栈状态机与回调注册机制，确保状态变更能原子化通知到框架层。
3. 在应用层实现状态栏对回调的响应逻辑，并使用 WindowInsetsController 控制导航栏手势区域。
4. 集成测试：使用 dumpsys activity activities 验证栈状态与 UI 状态的一致性。

验收标准

• 每层模块的输入/输出边界有明确文档，无跨层循环依赖。
• 在典型场景（返回、Home、Recents）下，导航栈更新到状态栏 UI 刷新的延迟 ≤ 16ms（60fps）。
• Binder 调用权限校验通过率 100%，无未授权跨层操作。
• 系统服务层宕机时，状态栏仍可显示系统级 Toast 或 Fallback UI（降级方案）。

分层架构总览图

风险总结与缓解措施