跨平台图形移植开发短记：日常巡检少走弯路

图形移植的异常往往不是一眼可见的崩溃：同一场景在某个平台颜色偏暗、透明 UI 出现边缘，或阴影在特定机型上闪烁。日常巡检的价值是把这类差异固定到一套场景和检查顺序里，不靠开发者记忆“上次是怎么修好的”。

维护一组跨平台基准场景

基准场景不需要覆盖完整玩法，但要稳定包含不透明和透明物体、阴影、后处理、UI 混合、法线贴图和低画质降级。每次构建在目标平台打开同一场景，保存截图和 Frame Debugger 记录的引用。比较时优先看颜色空间、深度范围、纹理方向和混合顺序，而不是只凭肉眼判断“差不多”。

场景应注明图形 API、质量等级、分辨率和动态分辨率状态。若移动端使用了不同的纹理压缩格式，也把格式和 fallback 资源写进清单。这样发现异常后，能够判断它来自内容资源、平台 capability 还是某个构建配置。

平台差异放在明确的边界

公共渲染代码只表达意图，例如需要深度纹理或某种采样方式；平台层根据能力映射到实现。shader 中明确精度、坐标系、深度范围和采样限制，不把驱动的默认行为当作协议。遇到不支持的格式或特性时，返回可见的降级结果，比如关闭某个后处理或使用替代材质，而不是悄悄换成未知格式。

构建前检查 shader variant 和资源变体是否覆盖目标平台。编辑器中能显示并不代表构建包包含同样的 variant；构建日志和运行时关键字列表应能对应起来。若缺失，先修正裁剪配置，再讨论材质或代码逻辑。

巡检后的处理顺序

发现差异时先记录设备、系统版本、图形 API、场景与配置版本。用同一版本在另一台同类设备复现，再缩小到颜色、深度、纹理或 shader 编译中的一项。修复后回到所有基准场景跑一次，确认降级路径也仍可用。

这套巡检不会替代真实机型测试，但能把多数平台差异提前暴露，并让每一次修复留下下一次可复用的条件和证据。

巡检清单随渲染管线和设备范围变化更新；新增平台前先补齐该平台的基准截图和降级预期，再把它加入日常构建验证。