一个3D项目在真机上运行时，首次进入某个场景会出现明显的卡顿，甚至黑屏数秒，而在编辑器里却一切正常。这类问题绝大多数可以追溯到着色器的运行时编译：GPU驱动需要把Shader源码翻译成当前硬件可执行的指令，而现代引擎为了让一个Shader适配不同光照、雾效、阴影等状态，会在编译时生成大量变体，数量一旦失控，编译开销就会成为性能瓶颈。本文从变体的产生机制讲起，逐步给出裁剪与预编译的完整方案。
为什么着色器编译会慢：变体爆炸的根源
着色器源文件本身只是一个模板，真正提交给GPU的是针对每一种关键字组合编译出来的产物，这就是变体。比如一个Shader里声明了MULTI_COMPILE指令的三个开关：阴影、雾效、光照贴图，理论上就会产生2的3次方即8个变体。看起来不多，但如果项目里有几十个这样的开关，再加上URP或HDRP内置的几百个关键字，单个Shader的变体数量可以轻松突破几万甚至几十万。
更麻烦的是，引擎并不知道运行时究竟会用到哪些组合，只能保守地把所有可能用到的变体都保留下来。当某个材质第一次以某种新组合渲染时，驱动层需要现场编译，这次编译通常发生在渲染线程或驱动线程上，会直接阻塞提交，表现为画面卡住几十到几百毫秒。移动平台上GPU驱动编译效率更低，卡顿尤其明显。
可以用一个简单的实验验证这个问题：在Unity中新建一个空场景，只放一个使用标准Shader的球体，用Profiler观察首帧，会发现Shader编译相关的调用占据了绝大部分时间。把这个球体提前在启动场景里渲染一帧，再切到目标场景，卡顿就消失了。这说明瓶颈不在Shader本身多复杂，而在于编译时机不对。
裁剪变体：从源头控制数量
解决编译慢的第一步不是加速编译，而是减少需要编译的东西。Strip（剥离）无用变体是收益最高的优化手段。常用的做法是实现IPreprocessShaders回调，在打包阶段检查每个Shader的关键字组合，把项目里根本不会出现的组合直接剔除掉。
using System.Collections.Generic;
using UnityEditor;
using UnityEditor.Build;
using UnityEditor.Rendering;
using UnityEngine;
using UnityEngine.Rendering;
// 打包时剥离不需要的Shader变体
public class ShaderVariantStripper : IPreprocessShaders
{
// 例如项目从不使用实时阴影的某几种组合，直接剔除
public void OnProcessShader(Shader shader, ShaderSnippetData snippet,
IList<ShaderCompilerData> data)
{
for (int i = data.Count - 1; i >= 0; i--)
{
var keywords = data[i].shaderKeywordSet.GetShaderKeywords();
foreach (var kw in keywords)
{
// 假设该项目禁用了某个特定关键字组合
if (kw.name == "DISABLED_FEATURE_ON")
{
data.RemoveAt(i);
break;
}
}
}
}
public int callbackOrder => 0;
}除了代码剥离，还要从写Shader的习惯上控制变体。能用shader_feature_local就不要用shader_feature，前者把关键字限制在本地阶段，避免全局关键字笛卡尔积式的组合膨胀。材质上没有勾选的shader_feature关键字，在打包时默认会被剥离，这一点和多compile不同——multi_compile的所有变体一定会被保留，所以非必须的功能不要用multi_compile声明。
建立变体数量的监控机制也很重要。可以在CI打包脚本里调用ShaderUtil.GetSnippetCount或读取构建日志，统计每个Shader的最终变体数，一旦某个Shader超出阈值就报错提醒。经验上，一个中等规模移动项目的总变体数控制在几千以内是比较健康的状态，超过几万通常意味着有关键字声明失控了。
预编译：把编译成本挪到不敏感的时机
裁剪之后剩下的变体依然需要在运行前编译一次才能避免卡顿，这就是预编译要解决的事。Unity提供了ShaderVariantCollection机制，它记录了一组具体的变体组合（Shader加关键字列表加通道），可以在合适的时机调用WarmUp主动触发编译。
using UnityEngine;
using UnityEngine.Rendering;
using System.Collections;
public class ShaderWarmup : MonoBehaviour
{
public ShaderVariantCollection collection;
IEnumerator Start()
{
// 方式一：同步预热，会阻塞当前帧，适合放在加载界面
// collection.WarmUp();
// 方式二：异步预热，逐个变体编译，避免长时间卡住单帧
var asyncOp = collection.WarmUpAsync();
while (!asyncOp.isDone)
{
Debug.Log($"预热进度: {asyncOp.progress:P0}");
yield return null;
}
Debug.Log("着色器预热完成");
}
}异步预热的关键在于把编译分散到多帧完成，每帧只编译一小批变体，玩家几乎感知不到。加载界面是执行预热的最佳位置：此时玩家预期有等待，画面也不需要高帧率，编译成本被完全隐藏了。
那ShaderVariantCollection里的变体从哪来？手动填写不现实，正确做法是从真实运行中收集。Unity在编辑器运行游戏时可以把实际用到的变体记录到当前ShaderVariantCollection里（Graphics设置面板中有相关开关），跑一遍所有核心场景后，就得到了一份覆盖真实路径的变体清单。这份清单还应该纳入版本管理，随代码一起迭代，避免某次改动悄悄引入了新变体却没有被预热。
注意预编译并非万能。DirectX 12和Vulkan这类现代图形API支持管线状态对象与运行时异步编译，部分平台下WarmUp的实际含义有所变化；另外预热只覆盖清单里的组合，如果游戏路径发生了变化出现了未收集的变体，卡顿依然会出现。所以预编译和上一节的变体裁剪必须配合使用：先用裁剪保证总量可控，再用预编译保证时机可控。
工程化落地：自动化收集与持续验证
变体管理如果只靠人工，很容易在迭代中退化。建议把它做成CI流程的一部分：每次打包前自动运行变体剥离脚本，导出变体统计报告并和上次对比；每日构建后自动在真机上执行一遍核心场景，用ShaderVariantCollection.WarmUpProgress配合运行时埋点检测是否存在未预热的变体编译事件，一旦发现就输出到报告里。
具体检测手段可以利用Application.stackTraceLogType结合Unity的Shader编译警告，或者在开发版本里挂一个帧率监视器，捕捉渲染线程超过一定阈值的尖峰。也可以在PC开发阶段用RenderDoc等工具抓帧，查看是否存在延迟编译导致的CPU侧等待。
团队协作层面还有一条容易被忽视的规则：Shader关键字的增删要经过评审。一个随手添加的multi_compile开关，可能让整个项目的打包体积和预热时间翻倍。把变体数量当作和内存、包体一样的性能预算来管理，才可以让着色器编译问题在项目生命周期里始终保持可控。总结来说，裁剪决定编译量的上限，预编译决定编译发生的时机，自动化流程保证这两件事长期有效，三者齐备之后，首次进入场景的黑屏和掉帧问题基本可以彻底消除。