1. 项目概述与核心痛点做Unity项目尤其是手游最头疼的事情之一就是包体大小。美术同学辛辛苦苦做的效果程序同学吭哧吭哧写的逻辑最后可能因为一个不起眼的“Shader变体”问题导致包体凭空多出几十甚至上百兆。更糟的是这个问题在开发阶段很难察觉往往要等到打正式包、做AssetBundle依赖分析时才会暴露出来那时候再回头去查无异于大海捞针。这个问题的核心就是Shader变体的“爆炸”。一个看似简单的Shader因为不同的渲染路径、不同的关键字Keyword组合、不同的多编译指令可以衍生出成百上千个变体。Unity在构建时会根据场景中材质球的实际使用情况将这些变体打包进最终的构建结果。如果管理不当大量从未被使用的变体Dead Variants就会被包含进去白白占用宝贵的包体空间。手动管理对于稍具规模的项目这几乎是一项不可能完成的任务。你需要检查每一个材质球每一个Shader记录下它们的关键字组合然后去构建报告里核对……效率低下且极易出错。因此一套自动化的Shader变体收集、分析与优化策略就成了中大型Unity项目工程化建设的刚需。YooAsset作为当下流行的Unity资源管理系统其强大的资源打包、依赖分析和运行时加载能力为我们解决这个问题提供了绝佳的切入点。本篇文章我将分享一套基于YooAsset的Shader变体自动化收集与优化实战方案。这套方案已经在我们多个上线项目中得到验证能够稳定地将无用的Shader变体从构建产物中剔除为包体“瘦身”立下汗马功劳。2. Shader变体问题深度解析与YooAsset的切入点2.1 Shader变体是如何“爆炸”的要解决问题首先得理解问题是怎么产生的。Shader变体的生成主要源于以下几个机制多编译指令Shader中使用#pragma multi_compile或#pragma shader_feature。例如一个处理光照的Shader可能同时编译了_MAIN_LIGHT_SHADOWS和_MAIN_LIGHT_SHADOWS_CASCADE两种阴影模式即使你的场景只用了其中一种。材质关键字材质球Material上勾选的不同选项会启用对应的Shader关键字从而激活不同的变体。比如一个Standard Shader切换不同的渲染模式Opaque, Transparent, Cutout就会生成不同的变体。全局关键字通过Shader.EnableKeyword或GraphicsSettings设置的全局渲染设置会影响所有使用相关关键字的Shader。不同的渲染管线URP/HDRP内置的Shader会根据管线设置生成大量变体更不用说项目自定义的Shader了。Unity的构建管线尤其是基于可编程构建管线的Scriptable Build Pipeline在打AssetBundle或构建Player时会执行一个“变体剥离”过程。但它的剥离策略相对保守主要依据的是当前构建场景中实际被渲染的材质所使用的关键字组合。很多潜在可能被使用、但当前场景未使用的变体或者被资源引用但未渲染的变体依然会被保留。2.2 YooAsset如何帮助我们YooAsset的核心价值在于它对资源依赖关系的精确追踪和打包控制。在打包阶段YooAsset会分析所有需要打包的资源并收集它们的依赖链。Shader作为材质球的依赖自然也在被分析之列。我们的自动化策略就构建在这个基础之上收集阶段利用YooAsset打包前的资源收集接口获取所有待打包资源及其依赖的Shader信息。分析阶段针对收集到的Shader分析项目中所有材质球包括预制体、场景中的实际使用的关键字组合构建出“真正被需要的变体”集合。剥离阶段将“真正被需要的变体”集合与Shader本身能产生的“所有可能变体”集合进行对比找出无用变体并通过Unity提供的API如IPreprocessShaders在构建时将其剔除。验证阶段构建完成后对比优化前后的包体大小与Shader变体数量确保功能无误。YooAsset提供了一个可扩展的打包流程允许我们在资源收集完成后、实际构建开始前插入自定义逻辑这正是实施自动化策略的黄金位置。3. 自动化收集系统的设计与实现3.1 系统架构设计整个系统可以分为三个核心模块收集器、分析器和剥离器。它们协同工作在YooAsset的打包流程中。[YooAsset打包流程] | v 资源收集完成 (CollectAssets) | |--- [我们的系统介入] | | | v | 1. 收集器遍历所有收集到的材质资源提取Shader和关键字信息。 | | | v | 2. 分析器分析提取的信息生成“有效变体”签名列表。 | | | v | 3. 剥离器将“有效变体”列表传递给Unity构建回调。 | v Unity执行构建 (BuildPlayer/BuildAssetBundles) | v 在构建过程中剥离器回调被触发移除无效变体。3.2 关键实现步骤3.2.1 实现自定义打包构建管线我们需要创建一个继承自IBuildTask的类并将其插入到YooAsset的构建流程中。通常我们选择在BuildAssetBundle任务之前执行。// 示例自定义构建任务 public class ShaderVariantCollectionTask : IBuildTask { public void Run(BuildContext context) { var buildParameters context.GetContextObjectBuildParameters(); var buildMapContext context.GetContextObjectBuildMapContext(); // 1. 获取所有收集到的资源 var allAssets buildMapContext.Collection; // 2. 调用我们的核心收集与分析逻辑 ShaderVariantCollector.CollectAndGenerateReport(allAssets, buildParameters); // 3. 将分析结果有效变体列表保存到构建上下文中供后续剥离器使用 var shaderVariantContext new ShaderVariantContext(); shaderVariantContext.ValidVariantSignatures ShaderVariantCollector.GetValidVariantSignatures(); context.SetContextObject(shaderVariantContext); Debug.Log(Shader变体收集与分析任务完成。); } } // 在构建流程中插入此任务 public class BuildPipeline { public static void Run() { var buildPipeline new BuildPipeline(); // ... 其他任务配置 buildPipeline.AddTaskShaderVariantCollectionTask(); // 插入我们的任务 buildPipeline.AddTaskBuildAssetBundle(); // 原有的构建任务 // ... buildPipeline.Run(); } }3.2.2 核心收集逻辑实现ShaderVariantCollector是这个系统的核心。它的任务是遍历所有资源找到材质球并分析其使用的Shader和关键字。public static class ShaderVariantCollector { // 存储有效变体的唯一签名例如ShaderNameKeywordsHash private static HashSetstring _validVariantSignatures new HashSetstring(); public static void CollectAndGenerateReport(ListReportAssetInfo allAssets, BuildParameters parameters) { _validVariantSignatures.Clear(); foreach (var assetInfo in allAssets) { // 只处理材质球和预制体因为预制体内可能包含材质 if (assetInfo.AssetType typeof(Material) || assetInfo.AssetType typeof(GameObject)) { var assetPath assetInfo.AssetPath; var mainAsset AssetDatabase.LoadMainAssetAtPath(assetPath); if (mainAsset is Material material) { ProcessMaterial(material); } else if (mainAsset is GameObject prefab) { // 递归处理预制体中的所有材质球 ProcessPrefab(prefab); } } } // 生成分析报告可选但强烈推荐 GenerateReport(parameters); } private static void ProcessMaterial(Material material) { if (material null || material.shader null) return; Shader shader material.shader; string shaderName shader.name; // 获取该材质球激活的所有本地关键字 string[] keywords material.shaderKeywords; // 对关键字进行排序并生成一个唯一的签名 Array.Sort(keywords); string keywordSignature string.Join(_, keywords); string variantSignature ${shaderName}___{keywordSignature}; lock (_validVariantSignatures) { _validVariantSignatures.Add(variantSignature); } // 特别注意还需要考虑Shader的全局多编译关键字。 // 一个材质即使没有显式启用某个multi_compile关键字该关键字对应的变体也可能因为其他材质或全局设置而被需要。 // 更完善的方案需要解析Shader源码找出所有multi_compile组合并与当前材质的关键字进行匹配生成更多潜在的有效签名。 // 这是一个进阶难点下文会详细讨论。 } public static HashSetstring GetValidVariantSignatures() { return new HashSetstring(_validVariantSignatures); } }注意这里有一个关键细节。material.shaderKeywords只包含材质球本地启用的关键字。对于#pragma multi_compile定义的、未被材质显式启用但可能被其他材质或全局设置启用的关键字我们需要更复杂的处理逻辑。一个常见的策略是解析Shader文件找出所有的multi_compile和shader_feature定义然后为每个材质生成这些关键字所有可能组合的子集基于当前已启用关键字。这能更准确地反映“潜在需要”的变体避免过度剥离导致运行时错误。3.2.3 生成变体使用报告在收集阶段生成一份详细的报告至关重要它可以帮助美术和TA同学了解项目中Shader的使用情况定位“变体大户”。private static void GenerateReport(BuildParameters parameters) { string reportPath ${parameters.OutputRoot}/ShaderVariantReport_{DateTime.Now:yyyyMMdd_HHmmss}.txt; using (StreamWriter sw new StreamWriter(reportPath)) { sw.WriteLine( Shader Variant Collection Report ); sw.WriteLine($Collection Time: {DateTime.Now}); sw.WriteLine($Total Valid Variant Signatures Found: {_validVariantSignatures.Count}); sw.WriteLine(\n--- Details ---); // 按Shader名称分组统计 var grouped _validVariantSignatures.GroupBy(sig sig.Split(new[]{___}, StringSplitOptions.None)[0]) .OrderByDescending(g g.Count()); foreach (var group in grouped) { sw.WriteLine($\nShader: {group.Key}); sw.WriteLine($ Variant Count: {group.Count()}); foreach (var sig in group.OrderBy(ss)) { string keywordsPart sig.Split(new[]{___}, StringSplitOptions.None)[1]; sw.WriteLine($ - Keywords: [{keywordsPart}]); } } } Debug.Log($Shader变体报告已生成: {reportPath}); }4. 基于IPreprocessShaders的变体剥离实战收集到“有效变体”列表后下一步就是在Unity构建时将其余变体剔除。Unity提供了IPreprocessShaders和IPreprocessComputeShaders接口允许我们在Shader被编译进构建产物之前进行拦截。4.1 实现剥离器我们需要创建一个在Editor环境下运行的类实现IPreprocessShaders接口。它的callbackOrder属性决定了执行顺序数值越小越先执行。using UnityEditor.Build; using UnityEditor.Build.Reporting; using UnityEditor.Rendering; using UnityEngine; using UnityEngine.Rendering; using System.Collections.Generic; public class ShaderVariantStripper : IPreprocessShaders { // 设置一个较低的优先级确保在其他剥离器之后执行如果需要的话 public int callbackOrder { get { return 0; } } // 这个集合将在打包前由我们的收集任务赋值 public static HashSetstring ValidVariantSignatures { get; set; } public void OnProcessShader(Shader shader, ShaderSnippetData snippet, IListShaderCompilerData data) { // 如果没有有效签名数据说明收集任务未运行或失败安全起见不进行任何剥离。 if (ValidVariantSignatures null || ValidVariantSignatures.Count 0) { Debug.LogWarning([ShaderVariantStripper] 有效变体列表为空跳过剥离。请确保ShaderVariantCollectionTask已执行。); return; } string shaderName shader.name; int originalCount data.Count; // 从后向前遍历安全移除元素 for (int i data.Count - 1; i 0; i--) { var compilerData data[i]; // 将ShaderCompilerData中的关键字转换为排序后的字符串签名 string keywordSignature GetKeywordSignature(compilerData.shaderKeywordSet); string variantSignature ${shaderName}___{keywordSignature}; // 如果这个变体签名不在我们的有效列表中则移除它 if (!ValidVariantSignatures.Contains(variantSignature)) { data.RemoveAt(i); } } if (originalCount ! data.Count) { Debug.Log($[ShaderVariantStripper] 为Shader {shaderName} 剥离了 {originalCount - data.Count} 个变体。); } } private string GetKeywordSignature(ShaderKeywordSet keywordSet) { Liststring keywords new Liststring(); // 遍历所有可能的关键字这是一个简化示例实际需要获取当前渲染管线的所有关键字 // 更稳健的做法是使用ShaderUtil.GetShaderGlobalKeywords等API获取关键字名再检查是否启用。 // 这里提供一个概念性实现 var allKeywords ShaderUtil.GetShaderGlobalKeywords(); // 需要结合Shader实例 // 由于获取所有关键字并比对在循环内效率低通常我们会将“有效签名”的生成和比对逻辑保持一致。 // 在实践中我们通常在收集阶段就模拟构建与剥离器相同的签名生成算法。 // 简化处理假设我们已经有一个从ShaderCompilerData生成签名的方法。 // 我们可以通过keywordSet.GetShaderKeywords()获取到ShaderKeyword数组再转换为字符串名。 // 注意此部分代码需要根据Unity版本和渲染管线进行调整是实践中的难点。 // 一个可行的替代方案是在收集阶段不直接存储字符串签名而是存储一个计算好的“变体ID”或“关键字掩码” // 在剥离器中进行快速的位运算比对效率更高。 // 此处为演示返回一个占位符。实际项目需要填充此逻辑。 keywords.Sort(); return string.Join(_, keywords); } }4.2 连接收集器与剥离器现在我们需要在打包构建开始前将收集器得到的ValidVariantSignatures传递给静态的ShaderVariantStripper.ValidVariantSignatures。修改我们的ShaderVariantCollectionTaskpublic class ShaderVariantCollectionTask : IBuildTask { public void Run(BuildContext context) { // ... 之前的收集和分析代码 ... // 获取有效签名 var validSignatures ShaderVariantCollector.GetValidVariantSignatures(); // 关键步骤传递给剥离器 ShaderVariantStripper.ValidVariantSignatures validSignatures; // 同时可以将签名列表写入一个临时文件作为构建的“白名单”。 // 这样即使剥离器类没有被重新加载在某些增量构建情况下也能读取到数据。 string whiteListPath ${buildParameters.OutputRoot}/ShaderWhiteList.json; File.WriteAllText(whiteListPath, JsonUtility.ToJson(new StringListWrapper(validSignatures.ToList()))); context.SetContextObject(new ShaderVariantContext { WhiteListPath whiteListPath }); Debug.Log($有效Shader变体签名已设置共 {validSignatures.Count} 个。); } } [System.Serializable] public class StringListWrapper { public Liststring list; public StringListWrapper(Liststring l) { list l; } }同时剥离器也需要增加从文件读取白名单的容错逻辑public class ShaderVariantStripper : IPreprocessShaders { private static HashSetstring _validSignatures; public static HashSetstring ValidVariantSignatures { get { if (_validSignatures null) { _validSignatures new HashSetstring(); // 尝试从已知路径读取白名单文件 string whiteListPath // ... 从构建上下文或固定路径获取; if (File.Exists(whiteListPath)) { string json File.ReadAllText(whiteListPath); var wrapper JsonUtility.FromJsonStringListWrapper(json); _validSignatures new HashSetstring(wrapper.list); Debug.Log($[ShaderVariantStripper] 从文件加载了 {_validSignatures.Count} 个有效变体签名。); } } return _validSignatures; } set { _validSignatures value; } } // ... OnProcessShader 方法 ... }5. 进阶策略处理Multi_compile与全局关键字上面的基础方案能解决由材质球本地关键字shader_feature和部分multi_compile引起的变体问题。但对于#pragma multi_compile情况更复杂。因为multi_compile定义的所有关键字变体总是会被包含在构建中除非被显式剥离。我们的目标是只保留“可能被用到”的那些。5.1 解析Shader源码构建完整变体空间我们需要解析Shader文件找出所有的multi_compile和shader_feature指令块。例如#pragma multi_compile __ _MAIN_LIGHT_SHADOWS _MAIN_LIGHT_SHADOWS_CASCADE #pragma shader_feature _ALPHATEST_ON这意味着对于这个Shader在阴影方面有3种可能无阴影、主光阴影、主光级联阴影在AlphaTest方面有2种可能关、开。理论上这个组合会产生 3 * 2 6 个变体。对于每个材质球我们知道它当前启用了_ALPHATEST_ON。但对于multi_compile的阴影关键字它可能一个都没启用对应__也可能启用了_MAIN_LIGHT_SHADOWS。我们需要为这个材质球生成所有符合其当前状态的、合理的变体组合。一个保守的策略是对于shader_feature只生成材质球当前启用状态对应的变体对于multi_compile生成其定义的所有关键字对应的变体因为任何一个都可能在其他地方被启用。但这样可能会保留过多变体。一个更激进的策略是分析整个项目记录下每个multi_compile关键字集合中实际有哪些关键字被至少一个材质球或全局设置使用过。只保留这些被使用过的关键字的组合。这需要更全面的全局分析。5.2 实现全局关键字使用情况分析我们可以在收集阶段增加一个全局扫描// 在ShaderVariantCollector中增加 private static HashSetstring _globallyUsedKeywords new HashSetstring(); public static void CollectAndGenerateReport(...) { // ... 遍历所有材质球 ... ProcessMaterial(material); // 额外扫描项目中的Render Pipeline Asset、Quality Settings等收集全局设置的关键字。 CollectGlobalKeywords(); // 在生成最终有效签名时结合材质本地关键字和全局使用的multi_compile关键字 GenerateFinalVariantSignatures(); } private static void CollectGlobalKeywords() { // 示例检查URP Asset中的阴影设置 var pipelineAsset GraphicsSettings.currentRenderPipeline as UniversalRenderPipelineAsset; if (pipelineAsset ! null) { if (pipelineAsset.supportsMainLightShadows) _globallyUsedKeywords.Add(_MAIN_LIGHT_SHADOWS); // ... 检查其他设置 } // 检查Quality Settings中可能影响的关键字 // 这里需要根据项目具体使用的Shader和管线来定制 } private static void GenerateFinalVariantSignatures() { // 对于每个收集到的材质-本地关键字组合 foreach (var materialEntry in _materialData) { Shader shader materialEntry.Shader; Liststring localKeywords materialEntry.Keywords; // 1. 解析该Shader的所有multi_compile组合 ListListstring multiCompileGroups ParseShaderMultiCompileGroups(shader); // 2. 为每个multi_compile组决定使用哪个关键字。 // - 如果该组中有关键字在localKeywords中则使用它。 // - 否则如果该组中有关键字在_globallyUsedKeywords中则使用那个全局关键字。 // - 否则对于multi_compile使用第一个选项通常是__对于shader_feature忽略。 Liststring finalKeywordsForVariant DetermineFinalKeywords(localKeywords, multiCompileGroups); // 3. 用finalKeywordsForVariant生成签名加入_validVariantSignatures // ... } // 还需要考虑一种情况一个multi_compile关键字从未被任何材质或全局设置使用 // 但它对应的变体在Shader中是存在的。为了绝对安全我们可能还是需要保留它。 // 最安全的做法是对于每个multi_compile组至少保留一个关键字组合例如全关的状态。 // 这可以通过在DetermineFinalKeywords逻辑中为每个未激活的组添加一个默认项来实现。 }这个进阶方案的实现复杂度很高需要对项目使用的Shader有深入理解并且解析Shader源码本身也是一项容易出错的工作。在实际项目中我建议采用分步走的策略第一阶段先实现基础方案仅处理材质球本地显式启用的关键字。这能解决大部分由shader_feature和错误材质设置导致的问题。第二阶段针对项目中主要的、变体数量多的自定义Shader进行手动分析和配置为它们编写专用的变体收集规则或“白名单”。第三阶段如果项目Shader数量多且复杂再考虑实现完整的、自动化的多编译关键字分析。6. 常见问题、排查技巧与实战心得6.1 运行时出现“粉色材质”Shader丢失这是最令人恐惧的问题意味着剥离过度把运行时需要的变体删除了。排查步骤检查报告首先查看打包时生成的ShaderVariantReport.txt确认你认为应该存在的变体签名是否在有效列表中。验证场景在出问题的场景中选中粉色材质的物体查看其材质球使用的Shader和启用的关键字。手动计算这个组合的签名。对比白名单在打包输出的ShaderWhiteList.json文件中搜索这个签名。如果找不到说明收集阶段就漏掉了。分析遗漏原因材质未被收集该材质是否没有被任何被打包的场景、资源目录或代码引用YooAsset的收集规则可能排除了它。检查打包设置中的资源收集路径。动态加载材质材质是否是运行时通过代码new Material(shader)创建并设置关键字的这种材质在打包时不存在因此无法被收集。对于这种情况必须在打包前预先注册这些可能的Shader和关键字组合。我们可以创建一个“Shader变体收集器”场景在这个场景中放置所有可能被运行时创建的材质或使用它们的预制体并确保这个场景被打包或至少被收集器扫描到。全局关键字未考虑材质的关键字是否由全局渲染设置如GraphicsSettings或代码Shader.EnableKeyword在运行时启用这需要我们在收集阶段分析项目设置和代码将其纳入“全局使用关键字”集合。6.2 包体瘦身效果不明显可能原因与对策分析对象错误优化主要减少的是构建结果中序列化的Shader变体数据在resources.assets或globalgamemanagers.assets等文件中对AssetBundle文件大小的直接影响可能因压缩方式而异。使用Unity的BuildReport工具查看构建后的详细报告关注“Shader”相关的尺寸变化。变体主要来自内置ShaderURP/HDRP等内置渲染管线自带大量变体且很多被Unity默认包含。我们的剥离器对内置Shader同样有效。如果效果不佳可能是内置Shader的multi_compile组合极其复杂而我们的收集策略过于保守。可以尝试在保证功能的前提下在URP Asset中关闭一些用不到的特性如某些阴影模式、雾效等从源头减少变体定义。未启用“变体剥离”确保在Player Settings或URP Asset中相关的“Shader Variant Stripping”选项是打开的。我们的自定义剥离器是在此基础上做进一步优化。6.3 打包时间变长收集和分析所有材质、解析Shader确实会增加打包时间尤其是项目资源很多的时候。优化建议缓存机制将分析结果每个Shader的有效变体签名缓存到文件中。下次打包时如果Shader和项目材质没有变化则直接读取缓存跳过分析过程。可以通过计算Shader文件和材质资源的哈希值来判断是否变化。增量分析只分析自上次打包以来发生变化的部分资源。分步执行在开发期频繁打包时可以关闭深度分析仅使用基础收集。在出正式包前再开启完整的分析流程。6.4 与Addressables等其他系统的兼容性如果项目同时使用了YooAsset和Addressables或者未来考虑迁移需要注意剥离器的生效范围。IPreprocessShaders接口对普通的Player构建和AssetBundle构建包括YooAsset和Addressables都是有效的。只要我们的收集逻辑能覆盖到所有需要打包的资源方案就是通用的。关键在于确保“资源收集”阶段能扫到所有用到的材质。实操心得从小处着手不要一开始就追求全自动、百分百准确。先为核心的自定义Shader实现保护看到收益后再逐步扩大范围。报告是你的朋友无论系统多智能一份清晰易懂的报告包括每个Shader的变体数量、具体关键字对于排查问题和与团队沟通都至关重要。在CI/CD中集成将这套流程集成到持续集成系统中。每次出包自动生成变体报告和大小对比让优化效果可视化也能及时发现问题。保持警惕任何对Shader的修改、对新渲染特性的引入都可能改变变体组合。在相关改动后要重新审视变体收集策略。这套基于YooAsset的Shader变体自动化收集与优化策略本质上是将资源管理、静态分析和构建管线深度结合的一次实践。它需要你对Unity的渲染管线、Shader编译机制以及YooAsset的工作流程都有一定的理解。虽然实现起来有门槛但一旦跑通它将成为项目包体优化中一个稳定、可靠的自动化环节把开发者从繁琐的手动检查中彻底解放出来。