花屏与尺寸、裁剪、缓冲区异常怎样区分？

标准回答

花屏不能一开始就归因显卡或驱动。我会先区分具体表现：是内容拉伸、裁剪错位、颜色异常，还是随机像素与局部撕裂；再看它影响单个窗口、某类内容，还是整个显示目标。

跨屏场景先检查应用布局尺寸、Surface 尺寸、显示密度以及裁剪和变换是否一致。它们可能在不同时间更新，例如内容已经按新屏尺寸绘制，但裁剪仍沿用旧值，用户就会看到异常画面。这与缓冲区越界造成的随机数据错误不是同一类问题。

如果涉及视频、相机或 native 内容生产者，再进一步检查像素格式、步长、缓冲区复用和同步时机。普通 View 的布局问题没有证据时，不应该直接跳到这些更底层的原因。

我会用同一目标窗口的内容、图层和时间信息确认异常第一次出现的位置，再由对应责任层修复。回归时重点覆盖尺寸变化、屏幕切换和生命周期。只有证据真的落到驱动或 buffer，才会把它描述成底层缺陷；参与花屏专项本身不能证明修改过这些代码。

假设跨屏后裁剪仍沿用旧尺寸，画面可能被错误截取；这种情况与内存越界导致的随机像素异常，定位与修复完全不同。

核心是比较生产出来的内容与后续展示之间的差异。如果应用输出本身已经错误，就先追布局或内容生产；如果输出符合预期，但图层变换或最终展示异常，就继续向窗口与显示侧收敛。不同观察方式也可能改变时序，所以不能只靠一张截图定责，要结合实际 Surface、图层与操作时间。

尺寸只是一个维度。内容还受裁剪、变换、像素格式、步长、资源生命周期和读写同步影响。例如宽高正确，但生产者和消费者对格式理解不一致，仍会显示异常。不过具体检查顺序要服从现象和证据，不能把所有底层概念都列出来后就声称定位完成。

不能因为发生花屏就声称修复过 GPU 驱动、Fence 或 buffer 越界；这些属于需要独立证据的结论。