文章目录
变体过多的缺点
为了让大家了解为何要减少变体，这里列出变体过多的缺点
- 打包时编译变体的时间增加（如果你的变体使用 unity built-in standard shader，那么可能会有几千个变体，编译单单这个 shader 也许会需要 10 分钟）
- 增加 运行时 shaderlab 内存，游戏与运行时使用的变体多，那么意味着 shader 的实例很多，每个 shader 实例都是需要占用内存的
- 增加包体大小，因为 unity shader 变体多的话 编译出来 的样本就会很多，每个样本就是一个 shader 文件（如果我们自己写引擎的话，就知道这个变体是怎么回事）
项目情况
由于项目没使用 SRP，还是 built-in 管线，那么要使用 built-in 的阴影就需要使用到 #pragma multi_compile_fwdbase
#pragma multi_compile_fwdbase 和 multi_compile_fog 生存的变体（keyword）
该内置的 pragma 会生存很多不需要的 multi_compile 的 keyword，为了定制效果，让 shader 尽可能的小，那么我们可以这么整：将 #pragma multi_compile_fwdbase 和 multi_compile_fog 编译生存的 keywrod 都手动来定义需要的
如果我们只要
- fog linear
- lighting
- shadow
的功能
生存的变体
如下图，会生存一堆不需要的 keyword
变体的数量
如下图：98 个
查看编译生存的各个变体的代码，并搜索 Global Keywords - 源码级别
选中 shader 文件，点击 Inspector 视图中的按钮：Compile and show code，如下图的：
生存的代码中搜索 Global Keywords，就可以看到各个变体的代码
查看编译生存的各个变体 - keyword 级别
以上两种方式都可以查看变体情况
如何优化
根据上面 搜索 Global Keywords 的方式，我们可以知道生存了很多不必要的变体代码
变体多的缺点 上面有提到
为了优化，可以这么做，上面也有提到，这里再次重新强调一下：#pragma multi_compile_fwdbase 和 multi_compile_fog 编译生存的 keywrod 都手动来定义需要的
将 #pragma multi_compile_fwdbase 和 multi_compile_fog 预生成项拆解为单个的手动定义项
如：
//#pragma multi_compile_fog
//#pragma multi_compile_fwdbase
#define FOG_LINEAR
#define DIRECTIONAL
#define SHADOWS_SCREEN
优化之后
变体的数量剧减，有原来的 98 个变成了 6 个（还有一些自定义的 multi_compile，不然只有3个，而这三个都是内置生成的 tier:1,2,3的，这个 tier: 1,2,3暂时不知道如何删除，不然的话，只有1个变体，那么这个 shader 文件就会小的可怜，打包速度、占用内存都会极小）
