Android SystemUI架构拆解：模块划分、启动流程与通知链路

简介：面向Android系统开发与系统UI定制方向的学习者，这份PPT围绕SystemUI架构设计展开，适合已具备一定Android基础、希望厘清系统级界面组件职责与通知链路的开发者查漏补缺。内容从SystemUI的定位、apk形态与源码目录切入，梳理状态栏、通知、锁屏、最近任务、音量与电量UI、画中画、生物识别解锁等模块划分，并延伸到整体结构图、类图、启动流程，以及通知的注册、从系统传递到SystemUI和后续处理流程，帮助读者建立模块间关系与调用脉络的整体认知。对准备阅读系统源码、定制状态栏或排查通知显示问题的开发者，目录式组织能提供较清晰的索引，降低在庞杂模块中迷失的成本。压缩包内为1个pptx文件，大小约11.64MB，页面按章节组织，便于集中浏览和按主题复盘。已有403人学习，可作为理解SystemUI模块职责、架构组成与通知机制的参考材料。

1. 系统级界面的错觉：SystemUI 其实就是一个 APK

第一次梳理 SystemUI 架构设计的人，往往会先去找它对应的系统服务，结果在frameworks/base/packages/SystemUI目录下看到的却是一个标准 APK 工程。状态栏、锁屏、导航栏、最近任务、快捷设置，这些看起来像“系统本身”的东西，实际上都是这个常驻 APK 里的若干个子模块。它和普通 App 的差别不在形态，而在权限、启动时机和与 system_server 的耦合深度。

这套梳理要解决的正是这个错位：把“看起来包罗万象”的 SystemUI，拆成可枚举的模块、可描述的架构图、可追踪的通知链路。它适合要交一份系统层架构设计的学生，也适合接手定制 ROM 里状态栏、锁屏需求、需要先摸清边界的开发者。

2. 模块划分与职责边界：九个功能模块怎么切、怎么按需启动

SystemUI 的第一层认知，不是“它有哪些界面”，而是“它有哪些子类”。这套代码的组织方式是：一个功能模块对应一个继承自SystemUI抽象类的子类，父类只定义三个约定——start()、onConfigurationChanged()、dump()。把这三个方法吃透，模块划分这件事就清楚一半了。

2.1 九个模块与它们的源码归属

按功能职责切，SystemUI 内部至少能分出九类彼此独立的模块。它们大部分互不依赖，只在少数交叉点（比如锁屏和状态栏都要处理通知）上有耦合。

这张表的用途不只是“看起来齐全”。做方案时，它对应的是一份模块责任矩阵：每一行都要能回答“这个模块由谁启动、出问题看哪条日志、改它会不会影响别人”。比如锁屏和状态栏都监听通知，但锁屏只关心“有没有通知需要隐藏敏感内容”，状态栏才负责渲染；这条边界如果没在文档里写清，后面改锁屏极容易误伤状态栏。

模块之间的通信方式也值得单独标注。SystemUI 内部大量使用LocalServices这种轻量级的进程内服务定位器：模块 A 在start()里把实例注册进去，模块 B 在需要时按 class 取。它比 Binder 轻，比静态单例干净，代价是没有生命周期管理，取到的实例可能还没初始化完。

提示：LocalServices的注册顺序就是模块初始化的隐性依赖顺序，画架构图时要把这条“看不见的线”显式画出来，否则模块图会失真。

2.2 按需启动：SystemUIApplication的加载机制

SystemUI 并不是把所有模块一次性全部拉起来的。真正决定“哪些模块被启动”的，是SystemUIApplication里的一段加载逻辑，而模块清单存放在资源配置里。

// frameworks/base/packages/SystemUI/src/com/android/systemui/SystemUIApplication.java @Override public void onCreate() { super.onCreate(); // 从 resources 里读出模块类名数组，而不是硬编码在代码中 mServices = new SystemUI[ SERVICES.length ]; // 把当前进程注册为 SystemUI 的宿主，供各模块反查 SystemServicesImpl services = new SystemServicesImpl(); startServicesIfNeeded( SERVICES ); // SERVICES 来自 R.array.config_systemUIServiceComponents } private void startServicesIfNeeded(String[] services) { for (int i = 0; i < services.length; i++) { String clsName = services[i]; // 反射创建：这一步失败通常意味着资源配置里的类名写错了 Class<?> cl = Class.forName(clsName); SystemUI svc = (SystemUI) cl.newInstance(); svc.mContext = this; svc.start(); // 各模块自己的初始化入口 mServices[i] = svc; } }

模块清单本身长这样，放在 SystemUI 的config.xml里：

<!-- frameworks/base/packages/SystemUI/res/values/config.xml --> <string-array name="config_systemUIServiceComponents" translatable="false"> <item>com.android.systemui.statusbar.phone.StatusBar</item> <item>com.android.systemui.keyguard.KeyguardViewMediator</item> <item>com.android.systemui.recents.Recents</item> <item>com.android.systemui.volume.VolumeUI</item> <item>com.android.systemui.power.PowerUI</item> <item>com.android.systemui.media.RingtonePlayer</item> <item>com.android.systemui.pip.PipUI</item> <item>com.android.systemui.biometrics.BiometricDialogImpl</item> </string-array>

这段代码里有两个设计点，理解了才能算懂模块划分。第一是配置驱动：模块清单可以按产品形态差异化配置，车机版可以去掉锁屏模块，电视版可以去掉最近任务模块，只要改资源数组，不用改代码。第二是顺序即优先级：for循环是串行执行的，排在数组前面的模块先完成start()，后面的模块在start()里就能通过LocalServices拿到前面模块的实例。所以状态栏通常排在靠前的位置，因为很多模块要读它的状态。

代价同样明显：onCreate()跑在主线程，任何一次start()里做重活，都会直接拖慢 SystemUI 的首帧。这也是后面排查章节里最常被拎出来的一条。

2.3 解耦：依赖注入与模块边界

模块多了以后，构造函数参数会失控，AOSP 在较新的代码里引入了 Dagger 做依赖注入。它的作用不是“让代码更时髦”，而是把“谁依赖谁”从运行时挪到编译期。

// frameworks/base/packages/SystemUI/src/com/android/systemui/Dependency.java @SysUISingleton @Component(modules = { SystemUIModule.class, ... }) public interface SystemUIRootComponent { // 各模块通过子组件拿到自己需要的那几个依赖 Dependency.DependencyInjector createDependency(); } // 模块侧：不在构造函数里 new，而是声明需要什么 public class PowerUI extends SystemUI { @Inject public PowerUI(Context context, Lazy<NotificationEntryManager> entryManager) { super(context); // 依赖在编译期被检查，缺一个模块会在编译时报错而不是开机后空指针 } }

用依赖注入改写之后，模块之间的关系从“运行时才知道”变成“编译期就确定”。好处是加了新模块，漏声明依赖会直接编译失败；坏处是这块代码的阅读门槛上升，答辩时如果只讲“用了 Dagger”而不讲“解决了什么问题”，很容易被追问到答不上来。我一般的表述方式是：依赖注入解决的是模块初始化顺序不可见的问题，把隐式依赖显式化，顺带让单例的作用域可控。

3. 架构图怎么画：结构图、类图与启动流程的三层表达

架构图不是一张图，而是三张图从粗到细的三层表达。很多方案里只画一张模块框图，读者看完还是不知道代码长什么样。合理的做法是三层递进：结构图回答“分几层”，类图回答“谁继承谁、谁持有谁”，启动流程回答“开机时按什么顺序跑起来”。

3.1 结构图：三条边界切分

结构图的画法，我建议按三条边界切：系统服务侧、SystemUI 进程内、窗口显示侧。

系统服务侧是system_server里的那几个 Manager——StatusBarManagerService、NotificationManagerService、ActivityManagerService、WindowManagerService。它们通过 Binder 把状态推给 SystemUI，或者接收 SystemUI 的请求。

SystemUI 进程内分三层：最上层是九个功能模块（SystemUI子类），中间是一批共享 Manager（通知的NotificationEntryManager、状态栏的StatusBarStateController、窗口的SysuiWindowManager），底层是基础设施（Dependency、LocalServices、SysuiStatusBarWindow这类窗口容器）。

窗口显示侧是容易被忽略的一层。SystemUI 创建的窗口类型和普通 App 完全不同，状态栏窗口、通知面板窗口、锁屏窗口、导航栏窗口都挂在WindowManagerService上，窗口类型（TYPE_STATUS_BAR、TYPE_NAVIGATION_BAR、TYPE_KEYGUARD）决定了它们的层级和输入行为。画结构图时如果不把这层标出来，后面讲“为什么下拉通知面板不会盖住状态栏”就没法解释。

3.2 类图：继承链与组合关系

类图的关键是分清两种线：继承线和组合线。

继承线是SystemUI抽象类到九个子类的那条主干。抽象类里三个方法各司其职：start()负责初始化，onConfigurationChanged()负责配置变更后的重建，dump()负责把内部状态吐给dumpsys。这条线要画全，因为它是模块划分的骨架。

组合线是模块内部的结构。以状态栏为例，StatusBar下面持有一串视图：PhoneStatusBarView（根视图）、NotificationPanelView（下拉面板）、NotificationStackScrollLayout（通知列表容器）、StatusBarWindowView（窗口根布局）。这些是组合关系，不是继承关系，画成继承线就错了。类图上这两类线的区分，直接决定了读者能不能看懂“改通知列表的边距要动哪个类”。

3.3 启动流程：从 SystemServer 到第一个窗口

启动流程要从system_server那一头写起，因为 SystemUI 的第一个窗口是被它拉起来的。

// frameworks/base/services/java/com/android/server/SystemServer.java // AMS 进入 systemReady 阶段后，在同一个流程里把 SystemUI 拉起来 static final void startSystemUi(Context context, WindowManagerService windowManager) { Intent intent = new Intent(); // 直接指定组件名，属于系统内部的显式启动，不走隐式解析 intent.setComponent(new ComponentName( "com.android.systemui", "com.android.systemui.SystemUIService")); // 以 SYSTEM 用户身份启动，保证锁屏、状态栏只出现在系统用户下 context.startServiceAsUser(intent, UserHandle.SYSTEM); }

这段之后，执行流进入SystemUIService，它会调用SystemUIApplication的创建流程，接着走 2.2 里那段串行startServicesIfNeeded()。

排查启动问题时，命令行比看图快：

# 看 SystemUI 进程是否存活、启动耗时落在哪个阶段 adb shell ps -A | grep systemui # 过滤 SystemUI 全量日志，定位第一个窗口何时可见 adb logcat -s SystemUI StatusBar KeyguardViewMediator # 把各模块的内部状态一次性 dump 出来，比翻日志快 adb shell dumpsys activity service com.android.systemui/.SystemUIService

这三条命令分别对应三个问题：进程活没活、流程卡在哪、内部状态对不对。方案文档里把这组命令写进“启动流程”那一节，比单纯画一张时序图有用得多。

4. 通知链路：从notify()到通知栏的一次完整搬运

通知是 SystemUI 里唯一一条贯穿“系统服务—跨进程—进程内多模块—最终渲染”的完整链路，讲清楚它，架构图上的大部分边界就都被验证过一遍了。

4.1 通知在哪里：视图层级与数据归属

先分清楚两件事：通知的数据在哪，通知的视图在哪。

数据层面，通知的权威来源是NotificationManagerService，SystemUI 手里拿的是它推过来的一份快照加上RankingMap（排序信息）。视图层面，通知列表嵌在下拉面板里，层级大致是StatusBarWindow→PhoneStatusBarView→NotificationPanelView→NotificationStackScrollLayout→ 若干ExpandableNotificationRow。每一行通知对应一个 Row，分组通知则是一棵 Row 树。

这个层级关系的意义在于：改通知的视觉效果，要动的是 Row；改通知的排序与分组，要动的是 Manager 层；改通知面板的手势，动的是 PanelView。三层职责不混，代码就不会牵连过多。

4.2 注册流程：SystemUI 如何成为监听者

SystemUI 拿通知靠的是NotificationListenerService，这是 Android 给第三方 App 的公开接口，SystemUI 用它但给了系统级权限。

<!-- AndroidManifest.xml：声明一个通知监听服务 --> <service android:name=".NotificationListenerWithPlugins" android:exported="false" android:permission="android.permission.BIND_NOTIFICATION_LISTENER_SERVICE"> <intent-filter> <!-- 这个 action 决定了 NMS 会把它拉进监听者列表 --> <action android:name="android.service.notification.NotificationListenerService" /> </intent-filter> </service>

注册发生在服务被bind的那一刻，NotificationListenerService的父类会在内部向 NMS 发起 Binder 调用完成登记。SystemUI 侧的实现额外套了一层插件机制，允许按产品形态替换通知的过滤逻辑，这是定制 ROM 里很常见的一个扩展点。

4.3 投递与渲染：从notify()到一行通知

调用方执行notify()之后，链路大致是这样走的：NotificationManager通过 Binder 进入NotificationManagerService，NMS 完成校验、限流、记录，然后把通知推给所有已注册的监听者。SystemUI 在回调里拿到StatusBarNotification，交给进程内的 Manager 层做过滤、去重、分组，最后驱动视图更新。

// SystemUI 侧：通知到达后的处理入口（简化） @Override public void onNotificationPosted(StatusBarNotification sbn, RankingMap rankingMap) { // 1. 交给 EntryManager：这里做去重、时间戳更新、是否需要提醒的判断 mEntryManager.onNotificationPosted(sbn, rankingMap); // 2. 分组信息由 GroupManager 单独维护，视图只读它的结果 mGroupManager.onNotificationRankingUpdate(rankingMap); // 3. 只触发增量重排，不要在这里全量重建视图 mStackScrollLayout.updateNotificationViews(); } @Override public void onNotificationRankingUpdate(RankingMap rankingMap) { // 排序变化比新增通知更频繁，必须走轻量路径 mEntryManager.updateNotificationRanking(rankingMap); }

三个回调里最关键的一条是“增量更新”。通知列表最怕的就是每来一条通知就把整个列表removeAllViews()再重建一遍，那样在通知密集的场景下必然卡顿。正确的做法是复用 Row、只更新变化的那几行，排序变化单独走一条轻量路径。这个取舍在方案里必须写出来，因为它是通知模块性能好坏的分水岭。

5. 避坑与排查：五个最容易翻车的点

系统层代码的特点是出错现象离原因很远，一个模块挂掉，表现可能是整机黑屏。下面五条是这类项目里最高频的翻车点，每条都按“现象—原因—解决”写。

5.1 启动相关：模块加了却没跑起来

现象：新写的SystemUI子类代码编译通过，装进机器后完全没被调用，日志里连打印都没有。

原因：只写了类，没把类名加进config_systemUIServiceComponents资源数组。startServicesIfNeeded()是按资源配置反射创建模块的，数组里没有的类永远不会被实例化。

解决：模块新增动作固定成“三步走”——写子类、加资源数组、加日志验证。验证方式是在start()里打一行 tag 固定的日志，用adb logcat -s过滤确认，而不是靠肉眼看界面有没有变化。

5.2 启动相关：开机后状态栏延迟出现

现象：开机动画结束后，状态栏要过好几秒才出来，锁屏也可能晚一步。

原因：SystemUIApplication.onCreate()在主线程串行跑所有模块的start()，某个模块在start()里做了重活，比如读大量配置、初始化数据库、等别的系统服务回调，后面的模块全被堵住。

解决：start()里只做“注册 + 轻量初始化”，重活挪到onBootCompleted之后或者丢到单独的线程。判断标准很朴素：start()里不允许出现耗时超过一帧的操作，写代码时就得守住这条线。

5.3 通知相关：通知列表越用越卡

现象：通知积累到十几条以后，下拉面板明显掉帧，滑动发涩，新通知进来时闪一下。

原因：onNotificationPosted里做了全量重建，或者每来一条通知都触发一次完整的分组重算，视图反复 measure/layout。

解决：把“数据更新”和“视图更新”拆开，数据层只标记变化项，视图层按变化项增量刷新；排序更新走独立回调，不与新增通知共用重路径。压测方式也很直接：写一个脚本连续发 50 条通知，用adb shell dumpsys gfxinfo com.android.systemui看掉帧情况。

5.4 配置变更：转屏或切换深色模式后界面错位

现象：横竖屏切换、语言切换、深色模式切换之后，状态栏或通知面板的位置、文字、边距不对，重启才恢复正常。

原因：模块在start()时缓存了一份Configuration或Resources，配置变化后没有刷新；或者自定义 View 里持有旧的Context，读到的还是旧资源。

解决：所有模块统一在onConfigurationChanged()里走重新读取资源的路径，禁止在 View 构造完成后长期持有旧的Resources引用。这类问题最不容易靠日志发现，验收时必须把“转屏 + 深色模式 + 语言切换”做成一组固定动作跑一遍。

5.5 排查手段：问题复现不了，现场什么都没留下

现象：用户或测试反馈的问题，拿回来复现不了，日志里也没关键信息，只能靠猜。

原因：模块没有实现dump()，内部状态全靠日志拼，日志级别又不敢常开，最后什么都抓不到。

解决：每个模块都实现dump()，把关键状态（当前是否可见、当前用户、最近一次通知数量、锁屏状态）打出来，用adb shell dumpsys activity service com.android.systemui/.SystemUIService一次性取全。这个习惯在真机上救命，因为很多现场只有一条 dumpsys 能带回来。

6. 验收与答辩：怎么证明这套架构设计是通的

架构设计这类方案，最怕讲完一堆图，评委问一句“你怎么知道它是对的”。我的做法是把验收做成一张可执行的清单，每一条都对应一个能当场演示或能贴出输出的动作。

答辩环节的技巧，不在于把图讲得多复杂，而在于主动交代边界。讲到通知链路时，我会明确说“这一层我只做到渲染，业务侧的分发不在 SystemUI 里”；讲到模块划分时，我会指出“锁屏和状态栏在通知上有交叉，这里的耦合是设计取舍，不是遗漏”。评委追问时，能说清“哪里没做、为什么不做”的人，比把所有东西都说得完美的人可信得多。

还有一个具体技巧：把架构图打印成一张 A3，讲到哪一层就用手指着说，不要来回切幻灯片。系统层的图信息密度高，切页会打断听众的空间感，一张图讲到底反而清楚。

从那次被追问“你这个模块图里LocalServices那条线怎么没画”之后，我每次画架构图都会先把初始化顺序列一遍，再决定哪些线必须显式画出来——图上少一条线，答辩时就多一个问题。希望这套拆法能帮到你，需要完整方案的话可以直接取用。

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