安卓锁屏灭屏加载流程，听上去只是"按一下电源键，屏幕黑掉"这么简单的一件事，但真正把这条链路在代码里走一遍就会发现，它横跨输入系统、电源管理、显示管理、窗口管理、活动管理和 SystemUI 五个以上的模块，涉及三个互相独立却又必须保持同步的状态机。任何一环的时序错位，用户看到的就是"灭屏前闪了一下桌面"、"亮屏后白屏半秒"、"指纹解开了还停在锁屏"这类看起来像小毛病、排查起来却极耗时间的问题。这篇内容面向的是做系统定制、ROM 裁剪、性能优化和稳定性排查的开发者，也会尽量把原理讲得足够细，让刚接触 SystemUI 的读者能跟得下来。我不打算只列调用链，而是重点说清楚每一步为什么这么设计、哪些顺序绝对不能调换、参数在哪里改、出了问题该怎么定位。
1. 先把链路拆开：锁屏加载和灭屏到底谁先谁后
1.1 三个状态机，别把它们当成一个东西
新手最容易踩的坑，是把"屏幕黑了"和"锁屏显示了"当成同一件事，实际上它们是两套完全独立的机制。电源状态机由 PowerManagerService 维护，取值是 AWAKE、DREAMING、ASLEEP，描述的是系统整体是否处于休眠意愿；显示状态机由 DisplayPowerController 计算，取值是 ON、OFF、DOZE、DOZE_SUSPEND、ON_SUSPEND，描述的是物理屏幕和背光的实际状态；锁屏状态机由 KeyguardViewMediator 和 ActivityManagerService 里的 KeyguardController 共同维护，取值是 showing、occluded、bouncer showing、secure 与否。
这三者之所以要拆开，是因为它们的触发源完全不同。Doze 模式下电源状态是 DREAMING，显示状态可能是 DOZE 而背光是关的，但锁屏依然处于 showing；某些场景下 Activity 带 FLAG_SHOW_WHEN_LOCKED，锁屏还在只是被遮挡（occluded 为 true）；还有 AOD 熄灭后屏幕 OFF 但系统仍是 AWAKE 的短暂窗口。排查问题时如果你先入为主地认为"灭屏就等于锁屏出现"，就很容易在看 dumpsys 的时候被一堆互相矛盾的字段绕晕。
真正需要记住的交互规则只有一条：灭屏时必须先把锁屏拉到 showing，然后才允许显示状态切到 OFF。这条顺序保证了任何一刻用户看到的最后一帧都是锁屏，而不是桌面。后面所有复杂逻辑，本质上都是为这条规则服务。
1.2 关键进程与类的职责边界
下面这张表是我自己在定位问题时常用的"责任田划分表"，先把谁该负责什么弄清楚，再去抓日志就快很多。
| 层级 | 所在位置 | 关键类 | 主要职责 |
|---|---|---|---|
| 输入策略 | system_server | PhoneWindowManager | 判断电源键意图，返回休眠或唤醒标志 |
| 电源管理 | system_server | PowerManagerService / Notifier | 维护 wakefulness，分发状态变更通知 |
| 显示控制 | system_server | DisplayPowerController | 计算屏幕状态、控制背光斜率、驱动显示开关 |
| 窗口管理 | system_server | WindowManagerService / RootWindowContainer | 应用休眠令牌、隐藏 Activity、决定窗口可见性 |
| 锁屏仲裁 | system_server | KeyguardController（位于 ActivityTaskManagerService） | 记录锁屏是否显示、是否遮挡，驱动 Activity 的暂停与隐藏 |
| 锁屏呈现 | SystemUI 进程 | KeyguardViewMediator | 锁屏的总调度者，收发消息、控制显示与消失 |
| 视图实现 | SystemUI 进程 | StatusBarKeyguardViewManager / KeyguardBouncer | 创建并挂载锁屏视图、管理密码输入面板 |
| 合成上屏 | 独立进程 | SurfaceFlinger / HWC | 按窗口层级合成图层，输出到显示设备 |
这张表有个很关键的信息：锁屏的"决策"分散在两个进程里。system_server 里的 KeyguardController 决定 Activity 该不该被锁屏挡住、该不该进入停止状态；SystemUI 里的 KeyguardViewMediator 决定锁屏视图什么时候被画出来。两者之间靠 Binder 双向通信，任何一边慢一步，就会出现"决策已生效但视图还没画好"的空窗期，这也是首帧问题的根源。
1.3 为什么"先锁屏后黑屏"必须成立
有一个具体的用户场景可以说明这条约束的必要性：你正在看一张私人照片，按电源键锁屏，然后把手机递给别人。如果黑屏比锁屏快哪怕半帧，屏幕上就会残留一帧桌面内容，属于实打实的隐私泄露。系统层面为了杜绝这个，做了两件事。
第一件是在显示关闭前预留一个"准备阶段"。DisplayPowerController 在把屏幕状态从 ON 推向 OFF 的过程中，并不是直接切，而是先把亮度按斜率降到最低，再通知窗口策略层"我准备关屏了"。窗口策略层收到这个信号后，会让锁屏提前进入 showing，并把底下的 Activity 标记为不可见。这个过程是同步的，等它返回之后，显示控制才真正下发关屏指令。
第二件是 Activity 侧的配合。ActivityTaskManagerService 在收到休眠请求后会调用 RootWindowContainer 的休眠令牌逻辑，把 Activity 栈标记为休眠，触发 Activity 走 onPause / onStop。注意这里的先后关系：Activity 先被判定为不可见，锁屏视图才被真正绘制在上面，否则锁屏窗口会因为底下 Activity 还有可见性而拿不到正确的转场和层级。
注意：定制时如果为了"关屏更快"而把这两步改成异步并行，短期看灭屏确实快了十几毫秒，但一定会出现偶现的桌面残留帧，而且复现概率跟 CPU 负载强相关，非常难查。
2. 灭屏链路：按下电源键之后的那一百多毫秒
2.1 输入层到策略层的判断
电源键事件从 InputReader 读出后，经过 InputDispatcher 送到策略层，此时系统还没有做任何"休眠"的决定，只是把按键语义交给 PhoneWindowManager 判断。这里有一段容易被忽略的分支：短按电源键和长按电源键走的是不同逻辑，长按往往触发关机菜单或者语音助手，短按才是休眠。另外还有"电源键 + 音量键截屏"这类组合键，同样在这层先做拦截。
判断完之后，策略层并不自己去调电源服务，而是返回一个"请执行休眠"的标志位，由输入系统根据标志位发起实际的休眠调用，并把休眠原因（比如"电源键"、"超时"）一并带过去。带上原因非常重要，因为 PowerManagerService 后续的通知里会携带这个原因，SystemUI 会据此区分是用户主动锁屏还是超时自动锁屏，两者的动画和音效策略不同。
这一段在整个链路里耗时通常在个位数毫秒，但如果你们的方案在这层加了自定义手势识别，就可能引入十几毫秒的额外开销，值得在 trace 里确认一下。
2.2 wakefulness 的状态迁移与通知分发
电源服务收到休眠请求后，核心动作是把内部的 wakefulness 从 AWAKE 切到 ASLEEP，但这个切换不是孤立发生的。切之前要先处理一批"阻止休眠"的持有者：比如屏幕常亮标记、音频播放唤醒锁、通话中的场景。系统会遍历这些持有者，只有全部条件都不满足才真正进入休眠。这也是为什么有时你按了电源键屏幕没黑——很可能是有应用持有了唤醒锁，或者正在通话。
切换完成之后，通知会分发给所有注册的监听者，主要包括窗口策略层、Activity 管理、显示管理三大块。分发顺序在源码里是有讲究的，不同版本可能微调，但逻辑上的依赖是固定的：先让 Activity 知道自己要被挡住，再让窗口系统调整可见性，最后才让显示系统关屏。
我在实际项目中遇到过一个很典型的定制问题：某方案为了省电，把"关屏"这一步提前到了通知分发之前，结果就是灭屏瞬间锁屏根本来不及画，用户按电源键会看到一瞬间的桌面，然后才黑。改回去之后问题立刻消失。这个坑说明，通知分发的顺序不是一个可以随便优化的自由项。
2.3 显示关闭的三个阶段与背光斜率
显示关闭在 DisplayPowerController 里可以拆成三个阶段，理解这三个阶段对优化灭屏体验很有帮助。
第一阶段是背光下降。系统并不是瞬间把背光从当前值切到 0，而是按照一个斜率做渐变，默认斜率量级在每秒两千个亮度单位。举个具体的算法：如果当前背光是 150（0 到 255 的取值区间），按每秒 2000 单位下降，那么理论上只需要 75 毫秒就能降到 0。但如果当前背光是 20（夜间低亮度），同样斜率下只需要 10 毫秒，用户几乎感知不到渐变。这就是为什么夜间灭屏看起来更"干脆"。
第二阶段是显示状态切换。背光降到最低后，显示状态才从 ON 转向 OFF 或 DOZE。如果设备支持 AOD，这里会先进入 DOZE 而不是直接 OFF，AOD 内容接管显示，此时系统 wakefulness 可能仍是 ASLEEP，但显示并没有完全断电。
第三阶段是合成停止。SurfaceFlinger 收到显示状态变化后，会停止为该显示设备准备合成缓冲，硬件合成器接管最后的断电动作。这个阶段对上层基本不可见，但如果你们的方案在这里做了额外的图层清理，就可能引入掉帧。
2.4 真正的时间都花在哪
很多人以为灭屏慢是因为关屏指令慢，实测下来往往不是。我用 trace 反复看过这条链路，时间大头通常集中在两处：一是锁屏视图的首次绘制（如果 SystemUI 进程刚启动或者锁屏是第一次被创建），二是 Activity 的 onPause 里如果有应用做了耗时操作。
关于超时自动灭屏，还有一个参数链值得说清楚。用户设置的屏幕超时（默认常见值是 30 秒）并不是最终生效值，系统会取多个约束的最小值：设备管理策略可能设了更短的上限、省电模式下可能被压缩、某些场景下窗口可以临时申请更长的超时（比如看视频）。所以当你发现"明明设了 30 秒，10 秒就黑了"，先去看窗口是否申请了超时覆盖，而不是怀疑设置没生效。
另外还有一个容易被忽略的设置项：锁屏延迟锁定时间。它的含义是"灭屏之后，隔多久才真正要求密码验证"。如果设成 5 分钟，那么灭屏时锁屏会立刻显示，但此时是"可以直接滑动进入"的宽松状态，系统会用定时器在 5 分钟后把锁屏切到安全状态。这个机制在 KeyguardViewMediator 里对应一组延迟序列号，序列号的作用是防止旧的定时任务在新一轮亮灭屏之后误触发。定制时如果把这套序列号逻辑改坏了，表现就是"设了延迟锁定但立刻就要密码"，或者反过来"设了立即锁定却能直接滑进去"。
3. 锁屏加载链路：SystemUI 里的几个关键角色
3.1 KeyguardViewMediator 的消息机与状态收敛
KeyguardViewMediator 是锁屏的总调度，它的工作方式是一个典型的状态收敛器：外部各种事件（系统启动完成、屏幕状态变化、用户切换、生物识别结果、超时定时器到期）统统变成消息投进它自己的 Handler，然后在锁屏上按当前状态决定"该显示还是该隐藏"。
它内部维护的关键字段不多，但每一个都影响最终行为：是否已经完成系统启动、当前是否处于显示状态、是否被遮挡、是否正在切换用户、是否处于"退出锁屏"的动画过程中。这些字段的组合决定了收到显示请求时是立刻执行、延迟执行还是直接忽略。
新手常问的一个问题是：为什么我在代码里调了显示锁屏，但界面没反应？答案通常是这个调用被状态机吞掉了——比如当前正在退出锁屏的动画中，新的显示请求会被合并或者丢弃，等动画结束再统一收敛。这种设计是为了避免快速亮灭屏时状态抖动，但也意味着你不能假设一次调用一定对应一次界面变化，调试时应该看最终状态而不是调用次数。
3.2 视图挂载：其实没有独立的"锁屏窗口"
这一点很多人有误解，以为锁屏是一个独立的全屏窗口。实际情况是，锁屏视图挂在状态栏窗口里，那个窗口本身是常驻的、铺满屏幕的，锁屏内容只是这个窗口里的一层视图。这么设计的好处是窗口不需要反复创建销毁，亮灭屏切换时省掉了窗口添加的开销；坏处是锁屏视图的绘制会和状态栏、通知面板共享同一个渲染管线，任何一方卡住都会影响另一方。
密码输入面板（也就是通常说的 bouncer）则是另一套机制，它有自己的窗口和层级，是在需要时才添加的。这解释了为什么"锁屏本身很快，但弹出密码键盘会卡一下"——前者是已有窗口里的视图可见性变化，后者是新增窗口加视图膨胀。
视图的创建时机也有讲究。锁屏的主体视图在系统启动后就完成了初始化，但一些重资源（比如大尺寸背景图、复杂的解锁图案控件）会推迟到真正要显示时才加载。这种懒加载是性能优化的常规手段，代价是首次显示会更慢。如果你们的设备是低内存配置，进程容易被回收，那么"首次显示慢"就会变成"每次亮屏都慢"，这时候就要考虑把关键视图的初始化提前，或者提高 SystemUI 的进程优先级。
3.3 与 system_server 的握手细节
锁屏显示这件事必须让 system_server 知道，否则 Activity 不知道自己该不该被挡住。这个握手是双向的：SystemUI 告诉 KeyguardController"我要显示了"，KeyguardController 记录状态并驱动 Activity 隐藏，然后回调 SystemUI 确认。
这里有一个很关键的时序细节：Activity 的隐藏和锁屏的绘制是并行的，而不是串行的。系统的假设是锁屏视图已经提前准备好了，所以可以在 Activity 隐藏的同时把锁屏画上去。如果锁屏视图其实还没准备好（比如进程刚启动），就会出现 Activity 已经隐藏、锁屏还没画出来的空窗，用户看到的就是黑屏或者壁纸。
在解锁方向上，握手同样是双向的。用户在锁屏上验证通过后，SystemUI 通知 KeyguardController 锁屏即将消失，KeyguardController 驱动 Activity 恢复可见，窗口系统做转场动画。如果这一步的动画被打断（比如用户在动画中途又按了电源键），就需要一套完整的中断处理，这也是快速连按电源键容易出现界面异常的原因。
提示：调试这类问题时，抓 WindowManager 和 KeyguardViewMediator 两个 tag 的日志并排看，把时间戳对齐，能非常直观地看出是哪一方慢了。单看任何一方的日志都容易得出错误结论。
4. 亮屏与解锁：预加载的结果如何被复用
4.1 亮屏首帧为什么能直接看到锁屏
理解了灭屏前锁屏已经显示这件事，亮屏就很好解释了：亮屏时锁屏视图本来就在那里，只是屏幕不发光而已。所以亮屏的流程里没有"创建锁屏"这一步，只有"背光上升"和"允许合成"两个动作。这也正是为什么要坚持"先锁屏后黑屏"的第二个理由——它同时优化了亮屏体验。
亮屏链路大致是：电源键或抬腕等事件触发唤醒，电源服务把 wakefulness 切回 AWAKE，显示控制计算目标亮度并驱动背光上升，合成器恢复输出。整个过程的耗时主要取决于背光上升斜率和显示器的物理响应时间，通常比灭屏更快一些，因为不涉及 Activity 的暂停操作。
有个量级上的经验：从按键到屏幕出现内容，正常设备大概在 100 到 200 毫秒这个区间，其中背光上升占了相当比例。如果你们的方案把背光斜率调得很慢以求"柔和"，用户就会觉得"按了电源键要等一下才亮"，这是一个体验取舍，不是 bug。
4.2 生物识别解锁对灭屏路径的反向依赖
指纹和人脸解锁看起来是亮屏路径的事，实际上和灭屏路径强耦合。原因在于识别的触发时机：很多方案在灭屏状态下指纹传感器就已经开始工作（比如屏下指纹的抬手亮屏加指纹），识别成功后需要立刻点亮屏幕并跳过锁屏。
这里的问题出在时序竞争上。如果识别成功的事件比亮屏事件先到，系统会收到"解锁成功"但屏幕还没亮的请求，此时需要把这部分状态暂存，等屏幕亮起后直接进入解锁流程；如果反过来，屏幕已经亮了但识别事件还没上报，用户会看到锁屏闪一下再消失。这两种情况在代码上都要处理，处理不好就表现为"指纹解锁后锁屏卡一下"或者"要按两次"。
人脸识别的场景更复杂，因为它涉及前置摄像头的启动时间。常见做法是在亮屏的极早期就启动摄像头，同时给锁屏一个"正在验证"的状态提示，验证通过后再撤销锁屏。这条路径上任何一步的延迟，都会被用户感知为"抬起手机后要等半秒才解锁"。
注意：定制机如果修改了传感器的上电时序，一定要回归验证"灭屏直接指纹解锁"这个场景，这是最容易出问题、也最容易在内部测试中被忽略的路径。
4.3 AOD 与 Doze 的交叉场景
支持息屏显示的设备上，灭屏并不是直接进入 OFF，而是先进入 DOZE。此时锁屏状态仍然是显示中，但 AOD 内容会覆盖在上面或者替换掉部分内容。这就带来一个状态上的微妙之处：锁屏"显示中"但这个显示对用户是不可见的（背光极低或者只有局部像素点亮）。
处理这个交叉时最常出的问题是状态判断写死。如果代码里假设"锁屏显示中就意味着屏幕是亮的"，那么在 AOD 状态下就会做出错误决策，比如把某些耗电的动画继续跑着，或者把不该隐藏的视图隐藏了。稳妥的写法是分别查询电源状态和显示状态，再结合锁屏状态做综合判断，而不是用某一个状态去推断另一个。
另一个坑是 AOD 退出时的转场。从 DOZE 直接进入 ON（用户按键唤醒）和从 DOZE 进入 OFF 再进入 ON 是两条不同的路径，前者需要把 AOD 内容淡出同时锁屏恢复完整亮度，后者是完整的亮屏流程。如果转场动画没有区分这两种情况，就会出现 AOD 内容残留在锁屏上的问题。
5. 实战排查：高频问题与定位手法
5.1 先看状态，再看日志
我排查这类问题的固定套路是三步：先 dump 状态确认当前三个状态机各处于什么值，再抓一段覆盖完整操作过程的日志，最后用 trace 定量。
状态查询几条命令就够，注意不同版本的输出字段名会变，但大类是固定的：
# 电源与显示状态 adb shell dumpsys power | grep -E "mWakefulness|Display Power|mHolding" # 显示设备状态 adb shell dumpsys display | grep -E "mScreenState|DisplayDeviceInfo" # 锁屏相关状态 adb shell dumpsys window | grep -iE "keyguard|mShowingLockscreen|mDreamingLockscreen" # SystemUI 内部状态（KeyguardViewMediator 的 dump 会在这里输出） adb shell dumpsys activity service com.android.systemui/.SystemUIService最后一条命令特别有用，它会输出锁屏中介者的内部字段，包括是否显示、是否被遮挡、是否正在切换用户、当前的安全状态。很多"看起来毫无道理"的现象，在这份 dump 里都能找到答案。
日志层面关注这几个 tag：PowerManagerService、DisplayPowerController、WindowManager、KeyguardViewMediator、KeyguardStateController、KeyguardUpdateMonitor、ActivityTaskManager。用一次完整的灭屏加亮屏操作覆盖，把时间戳对齐，基本能还原出完整的执行顺序。
5.2 典型问题速查表
下面这张表是我这些年踩过的坑的浓缩，覆盖了大部分现场反馈，可以对着现象直接找方向。
| 现象 | 最可能的原因 | 优先排查点 |
|---|---|---|
| 灭屏瞬间闪一下桌面 | 锁屏显示晚于显示关闭 | 通知分发顺序、KeyguardController 与显示控制的时序 |
| 亮屏后白屏或黑屏半秒 | 锁屏视图未提前准备好 | SystemUI 进程是否被回收、懒加载视图初始化耗时 |
| 指纹解锁后仍停在锁屏 | 解锁成功事件与屏幕状态竞争 | 生物识别回调时序、KeyguardViewMediator 的退出状态 |
| 快速连按电源键界面异常 | 状态机被中断未收敛 | 退出动画的中断处理、消息合并逻辑 |
| 设了延迟锁定却立刻要密码 | 延迟序列号逻辑异常 | KeyguardViewMediator 的延迟锁定定时器 |
| AOD 内容残留在锁屏上 | DOZE 到 ON 的转场未区分路径 | 显示状态转场动画的分支处理 |
| 多用户切换后锁屏空白 | 用户切换期间的状态未刷新 | KeyguardUpdateMonitor 的用户监听、切换中标记 |
| 灭屏不生效 | 应用持有唤醒锁或常亮标记 | 唤醒锁持有列表、窗口的超时覆盖 |
5.3 用 trace 把时间量化出来
日志只能告诉你"谁在什么时候被调用"，trace 才能告诉你"每一段花了多久"。抓取建议用 Perfetto，配置里把系统调用和图形相关的分类都打开：
adb shell perfetto -o /data/misc/perfetto-traces/kguard.perfetto-trace -t 12s \ sched freq idle am wm gfx view binder_driver power res dalvik adb pull /data/misc/perfetto-traces/kguard.perfetto-trace抓的时候按固定节奏操作：亮屏状态下等两秒，按电源键灭屏，等三秒，再按电源键亮屏，等三秒，然后解锁。这样时间轴上一目了然。
打开 trace 后重点看几个东西。一是主线程上锁屏相关方法的执行块，看它是在等 Binder 返回还是在自己的代码里算；二是渲染线程的帧绘制，看首次绘制的时长以及有没有掉帧；三是合成器那一侧，看锁屏图层的第一帧是什么时候真正上屏的。把"决策时刻"和"上屏时刻"两个时间点标出来，差值就是用户感知到的延迟。
我在一个项目里就是用这个方法定位到问题的：日志显示锁屏在按键后 20 毫秒就进入了显示状态，但 trace 显示第一帧上屏在 300 毫秒之后，中间的时间全花在主线程的一个资源解码上。日志完全看不出来，因为它夹在两次状态回调之间，没有任何输出。
6. 性能与定制：把首帧时间抠出来
6.1 首帧时间到底由什么构成
把亮屏首帧拆开，大致是三段：从按键到显示状态切到 ON 的硬件准备时间、从 ON 到锁屏图层提交合成的软件时间、从提交到硬件真正点亮显示器的时间。第一段和第三段受硬件和屏幕驱动限制，改动空间有限；第二段是软件侧的主战场。
软件侧这一段的构成又可以分为消息调度延迟、状态判断耗时、绘制准备耗时。其中绘制准备最容易出问题，因为它是主线程上的同步操作，一旦涉及资源加载、文本测量、复杂布局，就会直接吃掉几十甚至上百毫秒。优化方向很明确：把这部分工作挪到不需要用户等待的时机去做。
6.2 冷启动与进程常驻的取舍
如果 SystemUI 进程被系统回收了，下次亮屏就需要完整走一遍进程启动、服务初始化、视图创建的流程。这个流程的耗时往往是几百毫秒量级，用户感知非常明显。所以低内存设备上"亮屏慢"的大部分案例，根因不在锁屏逻辑，而在进程被杀了。
处理思路有几种，各有代价。提高进程优先级最简单，但会影响整体内存回收策略；把关键视图的初始化提前到系统启动阶段，会延长开机时间；用轻量占位视图先顶上，等真实视图准备好再替换，能显著改善首帧但会带来一次内容跳变。我个人的经验是优先保进程，其次做视图分层加载，因为前者是确定性的收益，后者对实现质量要求高，容易引入新的视觉问题。
判断进程是否被回收，看日志里 SystemUI 是否有新的启动记录，或者看 trace 里有没有一长段完全没有该进程活动的空白。这个判断很重要，方向错了后面怎么优化都是白费。
6.3 定制场景下的几个硬提醒
第一，任何涉及顺序的改动都必须回归"灭屏不露桌面"和"亮屏首帧是锁屏"这两个基本场景，这是红线。
第二，改动锁屏显示逻辑时，务必把多用户、工作资料、访客模式这几个场景一起测。这些场景下锁屏状态机的分支完全不同，很多问题只在切换用户的瞬间出现。
第三，不要试图通过缩短背光渐变来"加快"灭屏。用户对灭屏速度的感知主要来自内容消失而不是背光，缩渐变只会让关屏显得突兀，收益极小。
第四，涉及生物识别的改动，一定要测试"灭屏直接解锁"和"亮屏后解锁"两条路径，它们的时序完全不同，只测一条很容易漏。
最后分享一个我自己一直在用的习惯：每次改完这条链路上的代码，不管改动多小，都用固定流程录一段 trace 存档。因为这类问题有个特点——现象是偶现的，等你收到反馈再去复现，环境早就变了。有一份改动前后的 trace 对比，你能在一分钟内判断出是自己改坏了还是别的地方引入了新开销，这比任何日志都可靠。另外，如果你在做定制机的功耗优化，注意锁屏相关的一次性初始化不要被放到亮屏路径上，我见过为了"首帧更快"把资源预加载塞进亮屏流程的方案，结果是每次亮屏都多花几十毫秒，反而更慢。
