1. 问题现象与排查起点1.1 用户看到的“冻屏”到底是什么车机在 STRSuspend to RAM唤醒后出现黑屏用户第一反应通常是“死机了”或者“冻屏了”。但实际排查下来用户看到的画面往往不是系统真的挂了而是一层遮罩把真实画面盖住了。这个遮罩可能是 WindowManager 残留的 starting window也可能是某个 SurfaceFlinger 图层没有被正确移除甚至可能是 Display 驱动在 resume 阶段没有重新提交帧。我遇到过一台车机STR 唤醒后屏幕全黑但用串口连上去看 kernel log发现系统已经正常 resumeActivityManager 也在正常调度。问题出在 SurfaceFlinger 的合成路径上——某个 layer 的 buffer 状态是 stale 的合成器直接跳过了这一帧的输出。用户看到的就是“黑屏”但系统内部其实在跑。注意不要一上来就怀疑 kernel 挂死。先确认系统是否真的卡住还是只是显示通路出了问题。1.2 为什么“系统不给闪屏”这件事很关键“闪屏”在这里指的是屏幕短暂亮一下又灭或者出现花屏、撕裂等异常显示。很多车机项目在 STR 唤醒流程里会加一个“闪屏抑制”逻辑目的是避免唤醒瞬间屏幕出现不稳定的画面。但这个逻辑如果做得太粗暴就会把正常的首帧也一起抑制掉导致用户看到的是持续黑屏。系统不给闪屏从产品角度看是“体验优化”从调试角度看却是“把问题藏起来了”。因为闪屏本身是一个信号——它告诉你显示通路正在恢复。如果这个信号被强行掐掉你就失去了判断显示是否正常的依据。我在实际项目里见过两种做法一种是在 resume 阶段直接关闭背光等所有 layer 就绪后再打开另一种是让 Display 驱动在 resume 时先输出黑帧等 SurfaceFlinger 提交第一帧后再切换。两种做法各有风险前者容易导致背光开启时机不对后者容易让用户看到黑帧到正常帧之间的跳变。1.3 排查思路的起点从用户可见现象反推排查这类问题我的习惯是从用户可见现象往回推。用户看到黑屏那就要问背光有没有亮如果背光亮了但屏幕全黑说明显示通路在输出但输出的是黑帧。如果背光根本没亮那问题可能在背光控制或者 Display 电源域。再往下推如果背光亮了用示波器或者万用表量一下 MIPI 或者 LVDS 的时钟和数据线看有没有信号。如果有信号但屏幕还是黑的那可能是时序参数不对或者屏幕本身没有正确初始化。如果没有信号那问题就在 SoC 的 Display 控制器或者驱动层。这套反推逻辑听起来简单但实际做的时候很容易被各种中间层干扰。比如 Android 的 SurfaceFlinger 会做合成HWC 会做叠加Display 驱动会做时序控制每一层都有可能出问题。所以排查的时候要一层一层剥不要跳步。2. STR 唤醒流程与显示通路拆解2.1 STR 唤醒的完整链路STR 唤醒不是单一事件而是一连串硬件和软件动作的集合。从按下电源键或者 CAN 信号触发唤醒开始大致经历这几个阶段PMIC 收到唤醒信号开始给 SoC 上电恢复各路电源域。SoC 退出低功耗状态CPU 开始执行 resume 代码。Kernel 恢复各驱动状态包括 Display、Touch、Audio 等。Android 系统恢复SurfaceFlinger 重新初始化合成通路。WindowManager 恢复窗口状态Activity 重新可见。Display 驱动提交首帧背光开启用户看到画面。这条链路上任何一环出问题都可能导致黑屏。而且不同环节出问题现象还不一样。比如 PMIC 上电时序不对可能连 kernel log 都看不到Display 驱动 resume 失败可能背光亮了但没画面SurfaceFlinger 合成异常可能画面是黑的但系统在正常跑。2.2 显示通路的关键节点Android 显示通路从 App 到屏幕大致经过这几层App 层通过 Surface 提交图形缓冲。SurfaceFlinger负责合成所有 layer决定最终输出内容。HWCHardware Composer负责硬件叠加决定哪些 layer 由 GPU 合成哪些由 Display 控制器直接叠加。Display 驱动负责配置 Display 控制器提交帧到屏幕。屏幕模组负责接收信号并显示。STR 唤醒时SurfaceFlinger 需要重新建立与 HWC 的连接HWC 需要重新配置 Display 驱动Display 驱动需要重新初始化屏幕时序。这个过程中任何一层的状态没有正确恢复都会导致黑屏。我遇到过一个问题HWC 在 resume 后没有正确恢复 layer 的叠加状态导致所有 layer 都被标记为“不可见”SurfaceFlinger 合成出来就是全黑。但系统 log 里没有任何报错因为从 HWC 的角度看它只是“按照配置输出”而已。2.3 遮罩机制是怎么盖住真实画面的Android 里有一种叫“starting window”的机制用来在 App 启动时显示一个占位窗口避免用户看到白屏。这个窗口本质上是一个遮罩盖在真实内容上面。STR 唤醒时如果 WindowManager 没有正确移除这个遮罩用户就会看到黑屏——因为遮罩本身是黑的。还有一种情况是 SurfaceFlinger 的“dim layer”或者“black layer”没有被正确移除。这些 layer 通常用于息屏显示或者过渡动画如果 resume 后没有清理就会一直盖在最上面。排查这类问题的关键是用 dumpsys SurfaceFlinger 看当前有哪些 layer以及它们的可见性和 Z 序。如果发现某个 layer 的 visible 区域覆盖了全屏而且它的 buffer 是黑的那基本就是遮罩问题。实操心得在 resume 流程里加一段 log打印 SurfaceFlinger 的 layer 列表和 HWC 的叠加状态。这样出问题时可以直接看 log不用每次都连串口。3. 根因定位为什么系统不给闪屏3.1 闪屏抑制逻辑的实现方式闪屏抑制通常是在 Display 驱动或者 HWC 里做的。常见做法有几种背光延迟开启resume 后先不打开背光等 SurfaceFlinger 提交第一帧后再打开。这样用户看不到中间的异常画面。黑帧插入resume 后先输出几帧黑帧等显示通路稳定后再输出正常帧。时序调整调整 Display 控制器的时序参数让屏幕在 resume 时不会出现瞬态异常。这些做法本身没问题但如果实现有 bug就会导致黑屏。比如背光延迟开启的逻辑里如果判断“第一帧已提交”的条件写错了背光就永远不会打开。或者黑帧插入的逻辑里如果黑帧数量设得太多用户就会看到长时间黑屏。3.2 治本的两步为什么没走通“治本的两步”通常指的是修复显示通路的 resume 时序确保所有 layer 在背光开启前已经就绪。修复闪屏抑制逻辑的判断条件确保它不会误杀正常帧。这两步没走通原因往往不是技术难度大而是排查成本高。车机项目通常周期紧STR 唤醒问题又涉及多个模块很容易被当成“偶现问题”搁置。再加上闪屏抑制逻辑本身就是为了“掩盖问题”所以一旦它工作不正常反而会让问题更难定位。我在一个项目里遇到过类似情况闪屏抑制逻辑在 resume 时判断“Display 是否 ready”的条件依赖于一个 flag但这个 flag 在某个异常路径下没有被置位导致背光一直不亮。查了两天才发现是 flag 的初始化顺序有问题。3.3 从 log 里找线索排查这类问题log 是最重要的线索来源。需要关注的 log 包括Kernel log看 Display 驱动 resume 是否成功有没有报错。SurfaceFlinger log看合成通路是否正常layer 状态是否正确。WindowManager log看窗口状态是否恢复遮罩是否移除。HWC log看叠加状态是否正常有没有 layer 被错误标记。我习惯在 resume 流程的关键节点加 log比如“Display resume start”、“Display resume done”、“SurfaceFlinger ready”、“First frame committed”、“Backlight on”。这样出问题时看 log 就能知道卡在哪一步。注意加 log 的时候要注意时序不要在中断上下文里加太多打印否则会影响 resume 速度甚至导致看门狗超时。4. 实操过程从复现到定位的完整记录4.1 复现环境的搭建复现 STR 唤醒黑屏需要一套稳定的测试环境。我的做法是硬件车机主板 屏幕模组 电源模拟器 CAN 模拟器。软件用户版本固件 串口调试 adb 连接。触发方式通过 CAN 模拟器发送唤醒信号或者直接按电源键。复现的时候要注意不要只复现一次就下结论。STR 唤醒问题很多时候是概率性的可能十次里只出一次。所以要多跑几次记录每次的现象和 log。我一般会写一个脚本自动循环“进入 STR - 唤醒 - 截图 - 记录 log”跑个几十次看黑屏出现的概率和规律。4.2 关键 log 的抓取与分析抓 log 的时候要确保 log 的完整性。Kernel log 可以通过串口抓Android log 可以通过 adb logcat 抓。如果问题出现在 resume 早期可能 adb 还没起来那就只能靠串口。分析 log 的时候我习惯先看时间线从唤醒信号触发开始到背光开启为止每一步花了多长时间。如果某一步耗时异常那可能就是问题所在。比如有一次我发现从“Display resume start”到“Display resume done”花了 800ms而正常情况只需要 50ms。查下来发现是 Display 驱动在 resume 时重新初始化了屏幕时序而这个过程被一个 mutex 锁住了导致等待时间过长。4.3 定位到遮罩层与闪屏抑制的冲突最终定位到的问题是闪屏抑制逻辑在 resume 时错误地判断 Display 未 ready导致背光没有开启同时WindowManager 的 starting window 没有被正确移除盖住了真实画面。两个问题叠加用户看到的就是持续黑屏。具体来说闪屏抑制逻辑依赖一个 flag这个 flag 在 Display 驱动 resume 完成后置位。但 Display 驱动 resume 完成的条件是“收到第一帧”而第一帧的提交又依赖于 SurfaceFlinger 就绪。SurfaceFlinger 就绪的条件里又包含了“WindowManager 完成窗口恢复”。而 WindowManager 完成窗口恢复的条件里又包含了“starting window 移除”。这就形成了一个循环依赖。打破这个循环的方法是让闪屏抑制逻辑不依赖 Display 驱动的 resume 完成信号而是依赖一个更早的信号比如“Display 控制器初始化完成”。这样背光可以在 SurfaceFlinger 就绪前就打开用户至少能看到 starting window而不是黑屏。4.4 参数计算与调整过程在调整背光开启时机时需要计算几个关键参数背光开启延迟从 Display 控制器初始化完成到背光开启的时间。这个时间不能太短否则用户会看到屏幕初始化时的花屏也不能太长否则用户会看到黑屏。首帧提交超时从背光开启到 SurfaceFlinger 提交第一帧的时间。如果超过这个时间还没有首帧就需要考虑是否要强制显示 starting window。STR 唤醒总时间从唤醒信号触发到用户看到正常画面的时间。这个时间直接影响用户体验一般要求控制在 500ms 以内。我实际调整时把背光开启延迟设为 100ms首帧提交超时设为 300ms。实测下来用户看到黑屏的概率从 30% 降到了 1% 以下。5. 常见问题与排查技巧实录5.1 黑屏问题速查表现象可能原因排查方法背光不亮屏幕全黑背光控制逻辑异常量背光使能引脚看是否有电平变化背光亮屏幕全黑Display 驱动 resume 失败看 kernel log确认 Display 控制器是否初始化成功背光亮屏幕显示黑帧SurfaceFlinger 合成异常用 dumpsys SurfaceFlinger 看 layer 状态背光亮屏幕显示 starting windowWindowManager 未移除遮罩看 WindowManager log确认窗口状态唤醒后闪一下黑屏闪屏抑制逻辑误触发检查闪屏抑制的判断条件5.2 独家避坑技巧不要依赖单一信号判断 Display readyDisplay 就绪涉及多个模块单一信号很容易误判。建议用多个信号做与逻辑或者用一个超时机制兜底。在 resume 流程里加“安全网”比如设置一个定时器如果 500ms 内背光没有开启就强制开启背光。这样即使逻辑有问题用户也不会看到持续黑屏。保留闪屏抑制的开关在调试版本里保留关闭闪屏抑制的选项方便对比现象。用户版本再打开。记录每次 STR 唤醒的耗时把关键节点的耗时打到 log 里方便分析性能瓶颈。5.3 容易被忽略的细节电源域的上电顺序Display 和背光的电源域上电顺序不对可能导致屏幕初始化失败。MIPI 时钟的稳定性STR 唤醒后MIPI 时钟可能需要重新锁定如果锁定时间过长屏幕会黑屏。Touch 和 Display 的同步有些项目里 Touch 和 Display 共用电源域如果 Touch 初始化失败可能影响 Display。温度影响低温环境下屏幕初始化时间会变长可能导致黑屏。6. 经验总结与后续改进方向6.1 这次排查留下的教训这次问题的核心教训是闪屏抑制逻辑不能建立在循环依赖上。Display 就绪、SurfaceFlinger 就绪、WindowManager 就绪这三者之间的依赖关系必须理清不能互相等待。正确的做法是定义一个明确的“显示通路就绪”状态由 Display 驱动在初始化完成后置位其他模块依赖这个状态而不是反过来。另一个教训是遮罩机制要有超时清理。starting window 不能无限期存在必须设置一个超时时间超时后强制移除。这样即使 WindowManager 出问题用户也不会看到持续黑屏。6.2 后续可以怎么改进如果让我重新设计这套流程我会做这几件事定义清晰的显示状态机把 Display 的 resume 流程拆成多个状态每个状态有明确的进入和退出条件避免循环依赖。加一个独立的显示看门狗在 kernel 里加一个定时器如果 Display 在指定时间内没有完成 resume就强制重启 Display 控制器。把闪屏抑制做成可配置的不同项目对闪屏的容忍度不一样有的项目宁愿看到闪屏也不愿看到黑屏。所以闪屏抑制应该做成可配置的而不是硬编码。加强 log 的可读性在关键节点加统一的 tag方便过滤和分析。6.3 给同行的建议如果你也在做车机 STR 唤醒相关的开发我的建议是不要等到问题出现了才去查要在设计阶段就把显示通路的 resume 流程理清楚。特别是涉及多个模块协作的地方一定要画清楚依赖关系图避免循环依赖。另外多跑压力测试。STR 唤醒问题很多时候是概率性的跑个几百次才能稳定复现。所以测试环境要支持自动化循环log 要抓全方便事后分析。最后不要忽视遮罩机制的影响。很多黑屏问题看起来是 Display 的问题实际上是 WindowManager 的遮罩没有正确移除。排查的时候要一层一层剥不要跳步。