简介：围绕 Android 系统级 UI 框架的架构梳理课件，面向从事 ROM 定制、系统应用开发与 Framework 层学习的初中级工程师，帮助理清 SystemUI 的功能边界与模块协作关系。内容从 SystemUI 的定义和源码位置 frameworks/base/package/SystemUI 讲起，逐项拆解状态栏、通知、锁屏、最近任务、音量 UI、电量 UI、铃声播放、画中画与生物识别等子模块的职责，并配以结构图、类图和启动流程，最后落到通知从注册、系统下发到在 SystemUI 内部处理的全链路。整包仅有 1 个 pptx 文件，约 11.64MB，以图示与纲目为主，便于直接用于团队内部分享或自学对照；已有 403 人学习。读者可借此建立清晰的模块地图，在排查状态栏、通知、锁屏等问题时快速定位所属组件，并理解各功能独立按需启动的设计取舍。

1. SystemUI 架构设计：从一块常驻 APK 说起

做 Android 系统层开发的同学，早晚会碰到一个问题：为什么一个“界面”要拆成通知、状态栏、锁屏、导航栏、最近任务、快捷设置这么多相互独立的部分？我在带课程设计时见过不少同学把 SystemUI 当成普通 App 来写，结果一加功能就全崩。SystemUI 本质是系统级的 UI 组件集合，源码位置固定在frameworks/base/packages/SystemUI，以 APK 形式常驻，但每个子模块按需启动、生命周期互不干扰。这份架构设计方案要解决的，就是把“系统信息显示与交互”这件事拆成可独立开发、可独立调试的模块，适合做 Android 系统方向毕设、课设，或要从零梳理系统 UI 链路的从业者。

2. 模块划分与启动方式：九个功能子类各自负责什么

SystemUI 的模块划分不是按界面上看到了什么来切的，而是按“谁持有窗口、谁响应系统服务回调”来切的。每个功能模块通常对应一个继承自SystemUI的子类，由SystemUIApplication在进程启动时统一拉起。理解这条主线，后面的架构图和通知流程才站得住。

2.1 九个核心子类的职责边界

按原料给出的划分，主要模块与职责如下：

这张表的价值在于：它把“我改哪个功能该动哪个类”这件事固定了下来。改状态栏图标逻辑不要碰 Keyguard，改锁屏不要动 NotificationChannels；跨模块的事情走系统服务，不直接互相调用。我一般会要求学生先把这张表抄进设计文档，作为模块边界的约定。

2.2 启动流程与按需加载

SystemUI 进程起来后并不是所有模块都立刻创建视图。它的启动大致分三段：SystemUIApplication.onCreate读取配置数组，按顺序实例化各模块；模块在start()里注册系统服务监听与广播接收器；真正需要显示时才通过WindowManager添加窗口。核心逻辑可以简化成这样：

// SystemUIApplication 中按配置顺序启动各模块 public void startServicesIfNeeded() { for (String clsName : mServices) { // mServices 来自 config 数组 SystemUI svc = mComponents.get(clsName); if (svc == null) { svc = (SystemUI) Class.forName(clsName).newInstance(); svc.mContext = this; mComponents.put(clsName, svc); } svc.start(); // 此处只注册监听，不建视图 } }

这里有两个设计点值得说清。第一，mServices是配置驱动的，新增模块只改数组和对应类，不动启动框架，这是“按需启动”能成立的前提。第二，start()里只做监听注册与状态初始化，窗口创建延后到onStart或系统回调触发，避免开机阶段多个窗口抢占。参数上，模块数组的顺序会影响依赖关系，需要先于他人注册监听的模块要排在前面；如果某个模块启动时报NullPointerException，八成是它依赖的服务还没 ready，检查顺序而不是加判空糊过去。

2.3 架构图与类图该怎么画

方案文档里的架构图不建议画成一张大杂烩。我的做法是分三层画：最上层是系统服务（NotificationManagerService、ActivityManagerService、WindowManager 等），中间层是 SystemUI 内的模块类，最下层是各类窗口与视图。层与层之间只画调用方向和回调，不画具体方法名，这样图在模块增减后依然成立。类图则聚焦继承关系：SystemUI作为基类，各功能子类继承它，SystemUIApplication持有所有组件实例。画图时容易忽略的一点是要标注窗口类型，比如状态栏用TYPE_STATUS_BAR，锁屏用TYPE_KEYGUARD，导航栏用TYPE_NAVIGATION_BAR，这些类型直接决定窗口层级和谁能盖住谁，答辩时被问到“为什么通知能盖在锁屏上”这类问题，答案就在窗口类型里。

3. 通知链路实现：从注册到 SystemUI 呈现

通知是 SystemUI 里最典型的一条跨进程链路，也是设计文档里最容易写虚的部分。只写“应用发通知，SystemUI 显示”没有交付价值，得把位置、注册、发送、处理四段拆开，每一段说清谁调谁。

3.1 通知的三段位置关系

通知数据不在 SystemUI 里，而在系统服务侧。应用通过NotificationManager.notify()把通知交给NotificationManagerService，服务端完成排序、分组、限流后，才通过回调推给 SystemUI 的 NotificationChannels 模块，模块再把数据交给状态栏的通知面板渲染。三者的关系是：应用是生产者，系统服务是仓库与调度中心，SystemUI 是展示方。这个位置关系决定了通知样式改在 SystemUI，通知策略（限流、渠道、重要性）改在服务侧，排错时先判断是“没发出来”还是“发出来了没画出来”。

3.2 注册流程与监听器绑定

NotificationChannels 模块启动时，需要向系统服务注册一个监听器，把后续的通知变化接回来。简化后的注册代码如下：

// NotificationChannels.start() 中向系统服务注册监听 public void start() { mBarService = INotificationManager.Stub.asInterface( ServiceManager.getService(Context.NOTIFICATION_SERVICE)); mListener = new NotificationListener(); // 实现回调接口 mBarService.registerListener(mListener); // 跨进程绑定，服务端持有引用 }

registerListener是关键一步。它是跨进程调用，服务端保存引用后，通知的增删改都会回调到NotificationListener的对应方法。这里最典型的翻车点是监听器注册时机太早或太晚：太早，系统服务还没就绪，绑定失败且不报错；太晚，开机阶段的通知就丢了。通常的做法是在模块start()中注册，并在onDestroy或进程退出时反注册，防止泄漏。参数上，注册时可携带过滤条件，只订阅需要的通知类型，减少跨进程回调频率。

3.3 从服务端推送到面板渲染

服务端推送过来的是通知数据集合，SystemUI 侧要做三件事：转换成内部展示模型、按分组与优先级排序、绑定到面板视图。转换环节要处理渠道信息、大图、快捷回复动作这些字段；排序环节要兼顾时间与重要性，不能简单按时间倒序，否则重要通知会被聊天消息淹没；绑定环节要考虑复用，通知面板是列表结构，频繁重建视图会卡。写实现时，我会把“数据转换”和“视图绑定”分成两层，中间留一层状态缓存，这样通知频繁更新时只需要重算变化的部分，不用整表刷新。排错方向也很明确：通知不显示先看监听器是否绑定成功，显示了但样式错看转换层，滑动卡顿看绑定层的复用逻辑。

4. 架构设计避坑：五处最容易翻车的地方

这一章是血泪经验汇总。SystemUI 这类系统级组件，问题往往不表现为崩溃，而是表现为“偶尔不对”，排查成本极高，所以设计阶段就该把这几条写进规范。

4.1 窗口层级乱序导致遮挡

现象是锁屏被通知盖住，或者导航栏跑到了状态栏上面。原因是添加窗口时用了不合适的窗口类型或 flags，系统按类型排层级，不是按添加顺序。解决方式是严格对照窗口类型表，锁屏、状态栏、导航栏各用各的类型，需要覆盖关系时用 flags 显式声明，而不是靠调整添加顺序碰运气。

4.2 模块间直接调用形成耦合

现象是改 A 模块导致 B 模块编译失败或运行异常。原因是为了图省事，在状态栏代码里直接 new 了锁屏的对象。解决方式是模块之间只通过系统服务和广播通信，跨模块数据走统一的状态源，禁止持有其他模块的视图引用。

4.3 监听器不反注册造成泄漏

现象是长时间运行后内存上涨，或者退出某个场景后仍收到回调。原因是注册了系统服务监听却没有在对应生命周期反注册。解决方式是注册与反注册成对出现，模块销毁时统一清理，用清单把每个模块注册过的监听列出来核对。

4.4 开机阶段服务未就绪

现象是开机后状态栏图标空白，过几秒才恢复。原因是模块启动时直接读取系统服务状态，此时服务尚未 ready。解决方式是把首次读取延后到服务回调或收到对应广播之后，初始化阶段只建立监听，不假设数据已可用。

4.5 通知频繁更新引发卡顿

现象是聊天类应用消息密集时通知面板滑动掉帧。原因是每次更新都触发整表重绘。解决方式是在转换层做差量比对，只更新变化的条目，视图层做复用，并对高频更新做合并节流。

5. 验收与答辩：怎么证明这套架构站得住

方案交上去，评审最想看的不是你画了多少图，而是你能不能把“模块边界”和“一条完整链路”讲清楚。我的验收做法分三步，每步都对应一个可检查的产出物。

第一步是模块边界核对。拿第 2 章那张职责表，逐个模块问三个问题：它注册了哪些系统服务监听、它持有哪个窗口、它和别的模块有没有直接引用。三个问题答不上来的模块，说明边界没划清，要回去改设计而不是补注释。第二步是走通一条链路。选通知这条链路最合适，因为它跨了应用、系统服务、SystemUI 三层，能覆盖注册、回调、渲染完整流程。验收时让同学从notify()调用开始，一路讲到面板上出现那一行，中间每一跳说清谁调谁、传了什么数据、失败会怎样。讲不通的地方就是设计漏洞。第三步是故障注入。人为制造三种情况：服务未就绪、监听器重复注册、通知高频更新，看系统的表现是否符合预期，以及日志能不能定位问题。

答辩时有个技巧值得单独说：准备一张“问题定位路径表”，把常见现象和排查入口对应起来。

这张表比任何架构图都更能说明你真的动过手。我一般还会要求把每次排查的过程记一行日志，写清“现象、怀疑点、验证结果”，攒够十几条之后，这套系统的黑匣子就基本建起来了。从那以后我每次带人做系统 UI 相关的方案，都强制先走一遍“边界核对 + 单链路走通 + 故障注入”这三步，跳过任何一步，后面都得返工。希望帮到你。

本文还有配套的精品资源，点击获取