SystemUI 整体架构：模块划分与锁屏-状态栏关系

先聊聊SystemUI的定位

SystemUI是什么？说白了，它就是Android系统里最贴近用户的那层“皮”。你每次解锁、看时间、拉通知栏、调音量、按导航键——全都在跟SystemUI打交道。我最早接触SystemUI时，真没觉得它有多复杂，不就是状态栏加锁屏嘛。直到有一次线上反馈锁屏卡顿、状态栏闪黑，我深入一看才发现，这里头的模块耦合、状态同步、生命周期管理，比想象中要深得多。

嗯，这一章我们就先把SystemUI的整体架构理清楚。把模块划分搞清楚，把锁屏和状态栏之间的关系看透，后面的优化才能动刀。

模块划分：SystemUI 到底管哪些东西？

官方把SystemUI拆成了十几个子模块，但常用的核心模块其实就这几个。我一般按职责把它们分成三类：基础UI、交互面板、系统入口。下面这张表格你可以当速查卡用：

模块	英文名称	核心职责	稳定性关注点
状态栏	StatusBar	显示信号、时间、电量、通知图标	高频率更新下的UI卡顿、图标丢失
锁屏	Keyguard	验证用户身份、显示锁屏时钟与通知	解锁动画掉帧、通知显示延迟
通知面板	NotificationPanel	展开/收起通知列表，展示快捷开关	滑动卡顿、通知删除后刷新异常
导航栏	NavigationBar	Home/Back/Recent 按键（或手势）	条切换时漏事件、手势冲突
音量面板	VolumePanel	调节音量、铃声模式切换	UI复用问题、多用户切换崩溃
最近任务	Recents	展示最近应用缩略图，支持关闭	内存泄漏、缩略图加载失败

你看，每个模块看着独立，但实际运行时它们会频繁通信。比如状态栏收到“电量变化”事件，要同时更新锁屏上的电量图标；锁屏解锁成功后又要通知状态栏显示完整内容。这就是我接下来要说的——关系图。

锁屏与状态栏：一对“既亲又疏”的兄弟

为什么说既亲又疏？因为它们共享数据（时间、通知、电量），却又独立渲染（锁屏上状态栏要隐藏很多元素）。我在项目中遇到过最典型的问题：锁屏界面下状态栏的图标还在做动画（比如充电闪动），但用户已经解锁了，动画没来得及停止，导致“穿透”到桌面层级，看着特别诡异。

要处理好这种关系，你首先得明白它们在架构层面的分与合。我习惯用一张图来概括：

这张图你仔细看：状态栏和锁屏之间有一条双向虚线箭头，表示它们持续交换数据。比如系统时钟每秒钟刷新，状态栏收到后先自己显示，再告诉锁屏更新。解锁时锁屏回调通知状态栏“恢复模式”。我在项目中见过因为数据同步顺序搞错，导致解锁后状态栏还停留在“锁屏隐藏模式”，好一段时间才恢复。后来我们加了个状态机，用onKeyguardDismissed回调强制刷新。

我眼中的关键协作机制

光看模块还不够，得知道它们怎么协作。我用一个表格把锁屏和状态栏的常见交互场景列出来：

场景	触发方	动作	可能导致的问题
通知到来	系统通知服务	状态栏显示图标，锁屏同时显示通知卡片	锁屏与状态栏通知排序不一致
解锁完成	锁屏回调	状态栏显示所有图标，隐藏锁屏层	动画时序冲突导致黑屏闪烁
电量变化	电池服务	状态栏更新电池图标，锁屏上的电池也更新	锁屏更新慢半拍，用户看到错误电量
锁屏下拉	用户手势	锁屏上弹出通知面板	面板与锁屏z-order混乱，点击穿透

稳定性优化的第一步：理解依赖边界

为什么要花这么多篇幅讲架构？因为优化之前，你总得知道“切哪里不疼”。很多时候稳定性问题都出在模块边界不清——比如状态栏的ScrimController强引用了锁屏的KeyguardUpdateMonitor，导致泄漏。

我曾经接手一个项目，锁屏解锁卡顿长达1秒。抓了systrace才发现状态栏在解锁瞬间要同时做三件事：释放锁屏资源、更新导航栏、刷新通知面板。而这些操作全堆在主线程上。后来我们把锁屏和状态栏的销毁解耦，用mHandler.post做了延迟释放，卡顿直接降到200ms以内。你看，搞定架构认知，事半功倍。

现在就动手梳理你自己的项目

如果你手头有SystemUI代码，可以试试这个快速检查清单：

1. 找到SystemUIApplication.java，查看startServicesIfNeeded()里注册了哪些核心服务。
2. 搜索KeyguardUpdateMonitor的所有引用，看哪些地方在监听锁屏状态。
3. 检查StatusBar.java里有无直接操作KeyguardViewManager的方法——如果有，那就是强耦合，建议改为接口回调。
4. 打开CommandQueue类，把锁屏相关命令（比如SET_NAVIGATION_BAR_LOCK）单独列出来，确认消息优先级。