黑屏、花屏、闪屏、冻屏怎样区分与展开？

标准回答

我参与过座舱黑花闪冻专项，主要围绕应用、窗口显示和跨屏流转链路，结合系统日志与 Perfetto 做联合定位。项目中月均闭环疑难问题 10 多个，这是联合工作的成果，不代表每个问题都由我独立修改。

这几类名称首先描述的是现象：黑屏是预期内容没显示，花屏是内容异常，闪屏是画面短暂不连续，冻屏是画面或交互不再按预期推进。同一个根因可能造成不同现象，同一种现象也可能来自不同链路，所以不能看到“冻屏”就直接判断主线程卡死。

我会先固定触发动作、版本和目标屏幕，把录屏、日志和 Trace 对齐。然后沿输入、业务状态、窗口与渲染逐段确认：事件有没有到，状态有没有变，应用有没有产出新帧，最终展示的是哪个图层。哪个环节前后第一次不一致，就优先缩小到哪个边界。

我实际遇到的方向包括冻屏或手势卡住。对这类问题，最有价值的是区分“操作没被处理”和“操作已经生效但画面没更新”。前者重点看回调线程、锁、IO 或同步调用；后者继续追 Surface、图层和帧展示。修复应针对证据确认的环节，再用相同触发条件和连续操作回归，不能只看偶然一次没有复现。

同样被描述为“卡住”，可能是手势事件未到，也可能是操作已生效但画面未更新。先分开验证，就能避免直接去改动画。

我会用相邻环节的输入输出对齐责任边界。例如应用已经更新到预期状态，并提交了目标窗口的新内容，但显示侧仍展示旧图层，这才有理由继续沿窗口或合成链路查。反过来，如果应用根本没产出新内容，就不能直接归因系统。主线程空闲、日志没有报错，都只能排除部分可能性，不能单独作为定责证据。

我的参与范围是多屏模块相关的应用、窗口和流转链路联合定位，而不是负责整个显示栈。个人贡献应对应到我补充的观测、排除的分支、收敛的时序问题，以及我负责的修改或回归。月均闭环数量说明专项规模；对于由其他模块完成的修复，我会明确说明协作边界，不把联合结果全部算成个人代码成果。

目前没有具体事件的完整根因与补丁。后面的单类页面是定位推演，不是已确认的个人故障记录。