着色器编译

每次构建项目时，Unity 编辑器都会编译构建所需的所有着色器：针对每个所需的图形 API 编译每个所需的着色器变体。

当在 Unity 编辑器中工作时，编辑器不会提前编译所有内容。这是因为为每个图形 API 编译每个变体可能需要很长时间。

相反，Unity 编辑器会这样做：

• 当导入一个着色器资源时，会执行一些最小的处理（例如表面着色器生成）。
• 当需要显示着色器变体时，它会检查 Library/ShaderCache 文件夹。
• 如果找到使用相同源代码的先前编译的着色器变体，则会使用该着色器变体。
• 如果没有找到匹配项，则编译所需的着色器变体并将结果保存到缓存中。
  • 注意：如果启用了异步着色器编译，它会在后台执行此操作并同时显示占位着色器。

着色器编译执行时使用名为 UnityShaderCompiler 的进程。可启动多个 UnityShaderCompiler 进程（通常在机器中每个 CPU 核心对应一个进程），这样在播放器构建时就可以并行完成着色器编译。当编辑器不编译着色器时，编译器进程不执行任何操作，也不消耗计算机资源。

如果有许多经常更改的着色器，着色器缓存文件夹可能会变得非常大。删除此文件夹是安全的；只会导致 Unity 重新编译着色器变体。

在播放器构建时，所有“尚未编译”的着色器变体都将被编译，因此即使编辑器不会使用这些着色器变体，它们也会存在于游戏数据中。

不同的着色器编译器

不同平台使用不同的着色器编译器来编译着色器程序，如下所示：

• 使用 DirectX 的平台会使用 Microsoft 的 FXC HLSL 编译器。
• 使用 OpenGL (Core & ES) 的平台会使用 Microsoft 的 FXC HLSL 编译器，然后使用 HLSLcc 将字节代码转换为 GLSL。
• 使用 Metal 的平台会使用 Microsoft 的 FXC HLSL 编译器，然后使用 HLSLcc 将字节代码转换为 Metal。
• 使用 Vulkan 的平台会使用 Microsoft 的 FXC HLSL 编译器，然后使用 HLSLcc 将字节代码转换为 SPIR-V。
• 其他平台（如游戏主机平台）使用其各自的编译器。
• 表面着色器使用 HLSL 和 MojoShader 来完成代码生成分析步骤。

使用 pragma 指令可以配置各种着色器编译器设置。

缓存着色器预处理器

着色器编译涉及几个步骤。首先，需要进行预处理。在此步骤中，一个名为预处理器的程序为编译器准备着色器源代码。

在 Unity 的早期版本中，编辑器使用了当前平台着色器编译器提供的预处理器。现在，Unity 使用自己的预处理器，也称为缓存着色器预处理器。

缓存着色器预处理器是为快速导入和编译着色器而优化的着色器预处理。它缓存中间预处理数据，因此编辑器只需要在内容更改时解析 include 文件，这样就能更高效地编译同一着色器的多个变体。

有关缓存着色器预处理器和以前行为之间差异的详细信息，请参阅 Unity 论坛：新的着色器预处理器。

构建时剥离

在构建游戏时，Unity 可能检测到游戏不使用某些内部着色器变体，并从构建数据中排除（“剥离”）它们。有关更多信息，请参阅着色器变体。