1. 项目缘起与核心问题拆解做过游戏开发或者实时渲染项目的朋友大概率都经历过这样一个场景项目迭代到中后期工程目录里的shader文件越堆越多几百个文件躺在那里真正还在被材质引用的可能只有一半。美术同学换了一版效果旧的shader没人删程序同学做实验性功能留下的变体功能下线了文件还在外包交接过来的资源包里夹着一堆用不上的着色器。这些东西平时不显山不露水但一到打包出包的时候就开始咬人——包体膨胀、加载变慢、内存占用升高甚至在某些平台上因为shader编译数量超标直接导致启动崩溃。“清理未使用的shader”这件事说白了就是给项目的着色器资源做一次彻底的断舍离。它的核心目标很明确找出那些没有被任何材质、任何渲染管线、任何运行时代码引用的shader文件确认安全之后将其移除从而缩减包体、降低编译开销、减少内存驻留。这件事听起来像是简单的文件删除但实际操作起来远没有那么轻松因为shader的引用关系往往藏在材质文件、预制体、场景文件、代码字符串甚至动态加载路径里稍有不慎就会删掉正在用的东西导致运行时报错或者画面异常。这篇文章适合三类人参考一是负责项目优化的客户端开发同学二是需要管理大量着色器资源的技术美术三是独立开发者或者小团队里什么都得管的全栈选手。不管你现在用的是Unity、Unreal还是自研引擎清理思路是相通的我会尽量把方法论和实操细节都讲透让你看完就能在自己项目里动手。2. 清理前的整体设计与思路拆解2.1 为什么不能直接按文件名删很多人第一反应是打开工程目录按修改时间排序把几个月没动过的shader删掉。这个做法极其危险。shader文件的引用关系不是靠“最近有没有打开”来判断的一个两年前写的水面反射shader可能至今仍被某个场景里的材质引用着只是你从来没点开过它。反过来一个昨天刚创建的测试shader可能已经废弃了但因为它太新按时间排序反而会被保留。正确的思路是建立一套“引用追踪”机制从真正使用shader的入口反向查找而不是从shader文件本身正向猜测。入口有哪些材质文件Material、预制体Prefab、场景文件Scene、渲染管线配置RenderPipelineAsset、代码中的动态加载路径、以及引擎内置的fallback引用。只有把这些入口全部扫一遍才能得到一份可靠的“在用shader清单”剩下的就是候选清理对象。2.2 静态扫描与动态验证双轨并行光靠静态扫描文件引用是不够的。有些shader是通过代码在运行时动态加载的比如Shader.Find(Custom/Water)这种写法静态扫描资源文件根本找不到引用关系但运行时确实在用。还有些shader是通过Addressables或者AssetBundle在特定条件下才加载的平时不出现一到特定关卡就冒出来。所以我的做法是静态扫描加动态验证两条腿走路。静态扫描负责快速圈定大部分引用关系动态验证负责兜底那些隐藏的动态加载。动态验证的具体做法是在运行时hook住shader加载接口记录所有被实际加载过的shader跑一遍完整的游戏流程或者自动化测试用例把运行时真正用到的shader也纳入白名单。两边的并集才是最终的安全清单。2.3 分阶段清理降低风险一次性删几百个文件万一出问题回滚成本太高。我习惯把清理分成三个阶段第一阶段只做扫描和报告不动任何文件先看看候选清单有多长、都是些什么东西第二阶段把候选shader移到一个临时目录而不是直接删除打一个完整包跑一遍回归测试第三阶段确认没问题后再真正删除并且提交一次干净的版本记录。这样即使中间发现问题回滚也只是把文件移回来那么简单。注意千万不要在版本控制未提交的状态下做批量删除操作。清理前务必确保当前工作区是干净的所有改动都已提交这样出问题才能一键回退。3. 核心细节解析与实操要点3.1 静态引用扫描的关键入口静态扫描的核心是遍历所有可能引用shader的资源文件提取其中的GUID或者路径引用。以Unity为例材质文件.mat里会通过GUID引用shader预制体和场景文件里会引用材质材质再引用shader形成一条链。你需要写一个编辑器脚本用AssetDatabase.GetDependencies接口从所有材质出发反向收集所有被依赖的shader。但这里有个坑GetDependencies默认只返回直接依赖如果材质被预制体引用、预制体被场景引用你需要递归遍历整个依赖树。更稳妥的做法是从所有场景和预制体出发用AssetDatabase.GetDependencies(scenePath, true)拿到完整依赖列表然后过滤出所有类型为Shader的资源。这样得到的清单覆盖面最广。代码层面的引用则需要单独处理。用正则表达式扫描所有C#脚本匹配Shader.Find、Resources.LoadShader、AssetDatabase.LoadAssetAtPathShader等常见加载模式把字符串参数提取出来再转换成对应的资源路径。这一步容易漏因为字符串可能是拼接出来的所以正则匹配只能作为辅助手段不能完全依赖。3.2 运行时加载追踪的实现方式运行时追踪需要在引擎的shader加载接口上打点。Unity里可以通过Shader.Find的调用记录来追踪但更彻底的方式是hook住底层的shader加载函数。如果不想改引擎源码可以在项目里封装一层shader加载管理器所有动态加载都走这个管理器管理器负责记录每次加载的shader名称和时间戳。跑测试的时候我会开一个完整的游戏流程从主菜单进到每一个关卡触发所有可能的特效和场景切换最后导出这份运行时加载记录。这份记录和静态扫描的结果取并集就是最终的白名单。实测下来动态加载的shader通常占总量的百分之五到百分之十数量不多但漏掉一个就可能导致线上事故所以这一步绝对不能省。3.3 变体收集与平台差异处理Shader变体是另一个容易被忽略的维度。一个shader文件可能生成了几十个变体其中大部分变体在实际运行中从未被使用。清理未使用shader的时候如果能把未使用的变体也一并清理掉收益会更大。Unity提供了ShaderVariantCollection来记录实际使用的变体组合你可以在运行时通过ShaderVariantCollection的API来收集当前平台实际编译的变体。平台差异也需要特别注意。在编辑器里跑得好好的shader打包到移动平台可能因为精度问题或者特性不支持而被剔除。反过来某些shader只在特定平台上被引用比如主机平台特有的后处理效果。所以清理的时候要分平台做扫描不能拿一个平台的结果去套所有平台。扫描维度工具/接口覆盖范围注意事项资源依赖AssetDatabase.GetDependencies材质、预制体、场景需递归遍历注意循环依赖代码引用正则匹配 字符串提取C#脚本中的动态加载拼接字符串容易漏运行时加载加载管理器打点实际运行流程需覆盖所有关卡和分支变体使用ShaderVariantCollection实际编译的变体分平台收集3.4 清理过程中的安全校验在真正删除之前我通常会做一轮安全校验。具体做法是把候选清理的shader移到一个单独的目录然后打一个开发包跑一遍自动化冒烟测试。测试用例要覆盖所有主要功能模块特别是渲染相关的部分。如果测试通过再人工抽查几个关键场景的画面表现确认没有出现材质丢失导致的粉红错误或者渲染异常。还有一个细节有些shader虽然当前没有被引用但可能是作为fallback存在的。比如某个shader在低端设备上会fallback到一个简化版本这个简化版本平时不出现但低端设备上必须要有。这类shader不能删需要在扫描阶段就把fallback链路上的所有shader标记为保护对象。4. 实操过程与核心环节实现4.1 编写扫描脚本的完整流程第一步是创建一个编辑器脚本放在Editor目录下。脚本的核心逻辑分四块收集所有场景和预制体的依赖、收集代码中的动态引用、合并运行时加载记录、输出候选清单。// 伪代码示例展示核心逻辑 public class ShaderUsageScanner { public static void Scan() { // 1. 收集所有场景和预制体的依赖 var allAssets AssetDatabase.FindAssets(t:Scene t:Prefab); var usedShaders new HashSetstring(); foreach (var guid in allAssets) { var path AssetDatabase.GUIDToAssetPath(guid); var deps AssetDatabase.GetDependencies(path, true); foreach (var dep in deps) { if (dep.EndsWith(.shader) || dep.EndsWith(.shadergraph)) { usedShaders.Add(dep); } } } // 2. 扫描代码中的Shader.Find引用 var codeRefs ScanCodeReferences(); usedShaders.UnionWith(codeRefs); // 3. 合并运行时加载记录 var runtimeRefs LoadRuntimeLog(); usedShaders.UnionWith(runtimeRefs); // 4. 输出候选清单 var allShaders AssetDatabase.FindAssets(t:Shader); var candidates new Liststring(); foreach (var guid in allShaders) { var path AssetDatabase.GUIDToAssetPath(guid); if (!usedShaders.Contains(path)) { candidates.Add(path); } } // 写入报告文件 File.WriteAllLines(ShaderCleanupReport.txt, candidates); } }这段代码的关键点在于GetDependencies的第二个参数要传true表示递归获取所有依赖。另外FindAssets的过滤条件要写对t:Shader能匹配到所有shader资源包括表面着色器和计算着色器。4.2 运行时日志的采集与合并运行时日志的采集需要在游戏启动时初始化一个记录器hook住所有shader加载调用。如果项目里有统一的资源加载模块直接在加载模块里加一行记录代码就行。如果没有可以临时在Shader.Find的调用处加日志或者用引擎提供的Profiler接口来抓取。采集到的日志格式建议用JSON或者CSV包含shader名称、加载时间、调用堆栈。合并的时候把日志里的shader名称转换成资源路径然后和静态扫描的结果做并集。这里要注意名称到路径的转换可能有歧义比如两个不同目录下有同名shader所以最好在记录的时候就带上完整路径。4.3 分阶段清理的具体操作第一阶段只生成报告不删任何文件。把候选清单导出成文本人工过一遍看看有没有明显不该删的。比如引擎内置的shader、第三方插件自带的shader这些通常有特殊的引用方式静态扫描可能扫不到需要手动加入白名单。第二阶段把候选shader移动到Assets/_ToDelete/目录下注意移动的时候要连同.meta文件一起移否则GUID会变。移动完成后重新打一个开发包跑自动化测试和人工抽查。这个阶段大概需要半天到一天的时间取决于项目规模和测试覆盖度。第三阶段确认无误后删除_ToDelete目录提交版本记录。提交信息里写清楚删除了多少个shader、释放了多少空间、测试通过的情况。这样以后如果有人发现画面异常可以快速定位到这次提交。4.4 清理效果的量化评估清理完成后我会从几个维度来评估效果。包体大小是最直观的用打包工具对比清理前后的包体差异通常能减少百分之五到百分之十五的体积具体取决于项目里冗余shader的比例。加载时间方面用Profiler抓一下场景加载的耗时shader编译时间通常会明显下降。内存占用方面运行时监控shader内存的峰值清理后一般能降低几十兆。评估维度测量工具预期收益注意事项包体大小打包工具统计减少5%-15%分平台对比加载时间Profiler编译耗时下降关注首次加载内存占用内存分析器降低几十兆关注峰值编译变体数变体统计工具减少冗余变体分平台统计5. 常见问题与排查技巧实录5.1 删完之后画面变粉红怎么办画面变粉红是shader丢失的典型表现说明某个材质引用的shader被删掉了。这时候不要慌先看控制台报错通常会提示哪个材质找不到shader。然后从版本记录里把对应的shader恢复回来重新加入白名单。排查的时候重点检查那些通过代码动态加载的shader以及通过AssetBundle加载的资源这些是最容易漏的。5.2 静态扫描扫不到某些shader有些shader是通过字符串拼接的方式加载的比如Shader.Find(Custom/ effectName)这种静态扫描根本扫不到。解决办法是在代码规范里禁止这种写法所有shader加载必须走统一的配置表或者常量定义。如果历史代码已经这么写了那就只能靠运行时追踪来兜底。5.3 不同平台清理结果不一致移动平台和主机平台的shader使用情况可能完全不同。移动平台可能不支持某些高级特性对应的shader变体不会被编译主机平台可能有一些特有的后处理shader。所以清理的时候要分平台做扫描不能拿一个平台的结果去套所有平台。建议在CI流程里加入分平台的shader扫描步骤每次打包前自动生成报告。5.4 第三方插件的shader怎么处理第三方插件自带的shader通常有特殊的引用方式比如通过插件自己的资源管理模块加载静态扫描可能扫不到。对于这类shader我的建议是默认保留除非你确定插件已经完全移除。如果插件确实不再使用了那连同插件一起删掉不要单独删shader。提示清理前建议先备份一份完整的工程或者确保版本控制里所有内容都已提交。批量删除操作一旦执行恢复起来很麻烦。5.5 清理后变体数量没有明显下降有时候shader文件删了不少但变体数量没怎么降。这通常是因为剩下的shader里还有大量未使用的变体。这时候需要进一步做变体清理用ShaderVariantCollection记录实际使用的变体然后在打包设置里只保留这些变体。变体清理的收益有时候比删shader文件还大特别是对于那些变体爆炸的复杂shader。5.6 如何避免清理后再次堆积清理是一次性的但shader堆积是持续性的。要避免这个问题需要在流程上做约束。比如在CI里加入shader使用率检查每次提交如果新增了未被引用的shader就报警或者定期比如每个版本周期跑一次清理扫描把候选清单发给相关同学确认。养成习惯之后shader目录就不会再变成垃圾场了。常见问题排查思路解决方案画面变粉红看控制台报错定位材质恢复shader并加入白名单静态扫描漏扫检查代码中的字符串拼接统一加载接口或运行时追踪平台结果不一致分平台扫描CI加入分平台检查插件shader误删确认插件是否还在用默认保留或连同插件一起删变体没下降检查剩余shader的变体用ShaderVariantCollection清理再次堆积缺乏流程约束CI检查定期扫描6. 工具选型与自动化集成建议6.1 自研脚本还是现成工具市面上有一些现成的shader清理工具但大多数只能做基础的引用扫描对于动态加载和变体的处理不够细致。我的建议是核心扫描逻辑自己写因为每个项目的资源管理方式都不一样通用工具很难覆盖所有情况。自研脚本虽然前期投入大一点但后续可以根据项目需求灵活调整长期来看更划算。6.2 集成到CI流程的具体做法把shader扫描集成到CI里每次打包前自动跑一遍生成报告并归档。如果发现新增了未引用的shader可以在CI里设置一个阈值超过阈值就报警或者阻断打包。具体实现可以用命令行调用编辑器脚本Unity支持-executeMethod参数来运行指定的静态方法。# CI中调用扫描脚本的示例命令 unity -batchmode -quit -projectPath /path/to/project -executeMethod ShaderUsageScanner.Scan -logFile scan.log跑完之后解析生成的报告文件统计候选清理的shader数量和总大小输出到CI的构建报告里。这样每次打包都能看到shader的使用情况趋势一目了然。6.3 团队协作中的沟通要点清理shader不是一个人闷头干的事需要和美术、策划、测试都打好招呼。美术同学可能知道某些shader是给未来功能预留的策划可能知道某些特效只在特定活动里出现。清理前把候选清单发到群里让大家确认一遍比事后出问题再回滚要高效得多。测试同学也需要知道这次清理的范围以便在回归测试中重点关注渲染相关的用例。7. 个人实操心得与后续扩展我在多个项目里做过shader清理踩过的坑不算少。最大的体会是不要相信任何自动扫描的结果一定要用运行时数据做交叉验证。静态扫描能覆盖百分之九十以上的情况但剩下的百分之十往往是最致命的。有一次我删了一个看起来完全没被引用的shader结果上线后才发现某个低端机型上会fallback到它导致那批用户画面全黑。从那以后我再也不敢跳过运行时验证这一步。另一个心得是清理的时机很重要。最好选在版本迭代的间隙不要赶在发版前一周做这种事。清理本身不复杂但验证需要时间万一出问题回滚也需要时间。留足缓冲期心里才不慌。后续如果想进一步优化可以往两个方向扩展。一是自动化变体清理把变体收集和打包设置打通实现变体的自动裁剪二是建立shader使用率的长效监控每个版本自动生成趋势报告让团队对shader资源的增长有直观感知。这两件事做完shader管理基本就进入良性循环了。最后分享一个小技巧在扫描脚本里加一个“最后修改时间”的过滤条件把最近一个月内修改过的shader自动加入保护名单。因为最近改过的shader很可能是正在开发中的功能即使当前没有被引用也不应该被清理。这个简单的规则能避免很多误删实测非常有效。 
长河君 · 2026/10/16 0:04:53 · 阅读 1.2k 游戏项目Shader清理实战：静态扫描与动态验证双轨并行
1. 项目缘起与核心问题拆解做过游戏开发或者实时渲染项目的朋友大概率都经历过这样一个场景项目迭代到中后期工程目录里的shader文件越堆越多几百个文件躺在那里真正还在被材质引用的可能只有一半。美术同学换了一版效果旧的shader没人删程序同学做实验性功能留下的变体功能下线了文件还在外包交接过来的资源包里夹着一堆用不上的着色器。这些东西平时不显山不露水但一到打包出包的时候就开始咬人——包体膨胀、加载变慢、内存占用升高甚至在某些平台上因为shader编译数量超标直接导致启动崩溃。“清理未使用的shader”这件事说白了就是给项目的着色器资源做一次彻底的断舍离。它的核心目标很明确找出那些没有被任何材质、任何渲染管线、任何运行时代码引用的shader文件确认安全之后将其移除从而缩减包体、降低编译开销、减少内存驻留。这件事听起来像是简单的文件删除但实际操作起来远没有那么轻松因为shader的引用关系往往藏在材质文件、预制体、场景文件、代码字符串甚至动态加载路径里稍有不慎就会删掉正在用的东西导致运行时报错或者画面异常。这篇文章适合三类人参考一是负责项目优化的客户端开发同学二是需要管理大量着色器资源的技术美术三是独立开发者或者小团队里什么都得管的全栈选手。不管你现在用的是Unity、Unreal还是自研引擎清理思路是相通的我会尽量把方法论和实操细节都讲透让你看完就能在自己项目里动手。2. 清理前的整体设计与思路拆解2.1 为什么不能直接按文件名删很多人第一反应是打开工程目录按修改时间排序把几个月没动过的shader删掉。这个做法极其危险。shader文件的引用关系不是靠“最近有没有打开”来判断的一个两年前写的水面反射shader可能至今仍被某个场景里的材质引用着只是你从来没点开过它。反过来一个昨天刚创建的测试shader可能已经废弃了但因为它太新按时间排序反而会被保留。正确的思路是建立一套“引用追踪”机制从真正使用shader的入口反向查找而不是从shader文件本身正向猜测。入口有哪些材质文件Material、预制体Prefab、场景文件Scene、渲染管线配置RenderPipelineAsset、代码中的动态加载路径、以及引擎内置的fallback引用。只有把这些入口全部扫一遍才能得到一份可靠的“在用shader清单”剩下的就是候选清理对象。2.2 静态扫描与动态验证双轨并行光靠静态扫描文件引用是不够的。有些shader是通过代码在运行时动态加载的比如Shader.Find(Custom/Water)这种写法静态扫描资源文件根本找不到引用关系但运行时确实在用。还有些shader是通过Addressables或者AssetBundle在特定条件下才加载的平时不出现一到特定关卡就冒出来。所以我的做法是静态扫描加动态验证两条腿走路。静态扫描负责快速圈定大部分引用关系动态验证负责兜底那些隐藏的动态加载。动态验证的具体做法是在运行时hook住shader加载接口记录所有被实际加载过的shader跑一遍完整的游戏流程或者自动化测试用例把运行时真正用到的shader也纳入白名单。两边的并集才是最终的安全清单。2.3 分阶段清理降低风险一次性删几百个文件万一出问题回滚成本太高。我习惯把清理分成三个阶段第一阶段只做扫描和报告不动任何文件先看看候选清单有多长、都是些什么东西第二阶段把候选shader移到一个临时目录而不是直接删除打一个完整包跑一遍回归测试第三阶段确认没问题后再真正删除并且提交一次干净的版本记录。这样即使中间发现问题回滚也只是把文件移回来那么简单。注意千万不要在版本控制未提交的状态下做批量删除操作。清理前务必确保当前工作区是干净的所有改动都已提交这样出问题才能一键回退。3. 核心细节解析与实操要点3.1 静态引用扫描的关键入口静态扫描的核心是遍历所有可能引用shader的资源文件提取其中的GUID或者路径引用。以Unity为例材质文件.mat里会通过GUID引用shader预制体和场景文件里会引用材质材质再引用shader形成一条链。你需要写一个编辑器脚本用AssetDatabase.GetDependencies接口从所有材质出发反向收集所有被依赖的shader。但这里有个坑GetDependencies默认只返回直接依赖如果材质被预制体引用、预制体被场景引用你需要递归遍历整个依赖树。更稳妥的做法是从所有场景和预制体出发用AssetDatabase.GetDependencies(scenePath, true)拿到完整依赖列表然后过滤出所有类型为Shader的资源。这样得到的清单覆盖面最广。代码层面的引用则需要单独处理。用正则表达式扫描所有C#脚本匹配Shader.Find、Resources.LoadShader、AssetDatabase.LoadAssetAtPathShader等常见加载模式把字符串参数提取出来再转换成对应的资源路径。这一步容易漏因为字符串可能是拼接出来的所以正则匹配只能作为辅助手段不能完全依赖。3.2 运行时加载追踪的实现方式运行时追踪需要在引擎的shader加载接口上打点。Unity里可以通过Shader.Find的调用记录来追踪但更彻底的方式是hook住底层的shader加载函数。如果不想改引擎源码可以在项目里封装一层shader加载管理器所有动态加载都走这个管理器管理器负责记录每次加载的shader名称和时间戳。跑测试的时候我会开一个完整的游戏流程从主菜单进到每一个关卡触发所有可能的特效和场景切换最后导出这份运行时加载记录。这份记录和静态扫描的结果取并集就是最终的白名单。实测下来动态加载的shader通常占总量的百分之五到百分之十数量不多但漏掉一个就可能导致线上事故所以这一步绝对不能省。3.3 变体收集与平台差异处理Shader变体是另一个容易被忽略的维度。一个shader文件可能生成了几十个变体其中大部分变体在实际运行中从未被使用。清理未使用shader的时候如果能把未使用的变体也一并清理掉收益会更大。Unity提供了ShaderVariantCollection来记录实际使用的变体组合你可以在运行时通过ShaderVariantCollection的API来收集当前平台实际编译的变体。平台差异也需要特别注意。在编辑器里跑得好好的shader打包到移动平台可能因为精度问题或者特性不支持而被剔除。反过来某些shader只在特定平台上被引用比如主机平台特有的后处理效果。所以清理的时候要分平台做扫描不能拿一个平台的结果去套所有平台。扫描维度工具/接口覆盖范围注意事项资源依赖AssetDatabase.GetDependencies材质、预制体、场景需递归遍历注意循环依赖代码引用正则匹配 字符串提取C#脚本中的动态加载拼接字符串容易漏运行时加载加载管理器打点实际运行流程需覆盖所有关卡和分支变体使用ShaderVariantCollection实际编译的变体分平台收集3.4 清理过程中的安全校验在真正删除之前我通常会做一轮安全校验。具体做法是把候选清理的shader移到一个单独的目录然后打一个开发包跑一遍自动化冒烟测试。测试用例要覆盖所有主要功能模块特别是渲染相关的部分。如果测试通过再人工抽查几个关键场景的画面表现确认没有出现材质丢失导致的粉红错误或者渲染异常。还有一个细节有些shader虽然当前没有被引用但可能是作为fallback存在的。比如某个shader在低端设备上会fallback到一个简化版本这个简化版本平时不出现但低端设备上必须要有。这类shader不能删需要在扫描阶段就把fallback链路上的所有shader标记为保护对象。4. 实操过程与核心环节实现4.1 编写扫描脚本的完整流程第一步是创建一个编辑器脚本放在Editor目录下。脚本的核心逻辑分四块收集所有场景和预制体的依赖、收集代码中的动态引用、合并运行时加载记录、输出候选清单。// 伪代码示例展示核心逻辑 public class ShaderUsageScanner { public static void Scan() { // 1. 收集所有场景和预制体的依赖 var allAssets AssetDatabase.FindAssets(t:Scene t:Prefab); var usedShaders new HashSetstring(); foreach (var guid in allAssets) { var path AssetDatabase.GUIDToAssetPath(guid); var deps AssetDatabase.GetDependencies(path, true); foreach (var dep in deps) { if (dep.EndsWith(.shader) || dep.EndsWith(.shadergraph)) { usedShaders.Add(dep); } } } // 2. 扫描代码中的Shader.Find引用 var codeRefs ScanCodeReferences(); usedShaders.UnionWith(codeRefs); // 3. 合并运行时加载记录 var runtimeRefs LoadRuntimeLog(); usedShaders.UnionWith(runtimeRefs); // 4. 输出候选清单 var allShaders AssetDatabase.FindAssets(t:Shader); var candidates new Liststring(); foreach (var guid in allShaders) { var path AssetDatabase.GUIDToAssetPath(guid); if (!usedShaders.Contains(path)) { candidates.Add(path); } } // 写入报告文件 File.WriteAllLines(ShaderCleanupReport.txt, candidates); } }这段代码的关键点在于GetDependencies的第二个参数要传true表示递归获取所有依赖。另外FindAssets的过滤条件要写对t:Shader能匹配到所有shader资源包括表面着色器和计算着色器。4.2 运行时日志的采集与合并运行时日志的采集需要在游戏启动时初始化一个记录器hook住所有shader加载调用。如果项目里有统一的资源加载模块直接在加载模块里加一行记录代码就行。如果没有可以临时在Shader.Find的调用处加日志或者用引擎提供的Profiler接口来抓取。采集到的日志格式建议用JSON或者CSV包含shader名称、加载时间、调用堆栈。合并的时候把日志里的shader名称转换成资源路径然后和静态扫描的结果做并集。这里要注意名称到路径的转换可能有歧义比如两个不同目录下有同名shader所以最好在记录的时候就带上完整路径。4.3 分阶段清理的具体操作第一阶段只生成报告不删任何文件。把候选清单导出成文本人工过一遍看看有没有明显不该删的。比如引擎内置的shader、第三方插件自带的shader这些通常有特殊的引用方式静态扫描可能扫不到需要手动加入白名单。第二阶段把候选shader移动到Assets/_ToDelete/目录下注意移动的时候要连同.meta文件一起移否则GUID会变。移动完成后重新打一个开发包跑自动化测试和人工抽查。这个阶段大概需要半天到一天的时间取决于项目规模和测试覆盖度。第三阶段确认无误后删除_ToDelete目录提交版本记录。提交信息里写清楚删除了多少个shader、释放了多少空间、测试通过的情况。这样以后如果有人发现画面异常可以快速定位到这次提交。4.4 清理效果的量化评估清理完成后我会从几个维度来评估效果。包体大小是最直观的用打包工具对比清理前后的包体差异通常能减少百分之五到百分之十五的体积具体取决于项目里冗余shader的比例。加载时间方面用Profiler抓一下场景加载的耗时shader编译时间通常会明显下降。内存占用方面运行时监控shader内存的峰值清理后一般能降低几十兆。评估维度测量工具预期收益注意事项包体大小打包工具统计减少5%-15%分平台对比加载时间Profiler编译耗时下降关注首次加载内存占用内存分析器降低几十兆关注峰值编译变体数变体统计工具减少冗余变体分平台统计5. 常见问题与排查技巧实录5.1 删完之后画面变粉红怎么办画面变粉红是shader丢失的典型表现说明某个材质引用的shader被删掉了。这时候不要慌先看控制台报错通常会提示哪个材质找不到shader。然后从版本记录里把对应的shader恢复回来重新加入白名单。排查的时候重点检查那些通过代码动态加载的shader以及通过AssetBundle加载的资源这些是最容易漏的。5.2 静态扫描扫不到某些shader有些shader是通过字符串拼接的方式加载的比如Shader.Find(Custom/ effectName)这种静态扫描根本扫不到。解决办法是在代码规范里禁止这种写法所有shader加载必须走统一的配置表或者常量定义。如果历史代码已经这么写了那就只能靠运行时追踪来兜底。5.3 不同平台清理结果不一致移动平台和主机平台的shader使用情况可能完全不同。移动平台可能不支持某些高级特性对应的shader变体不会被编译主机平台可能有一些特有的后处理shader。所以清理的时候要分平台做扫描不能拿一个平台的结果去套所有平台。建议在CI流程里加入分平台的shader扫描步骤每次打包前自动生成报告。5.4 第三方插件的shader怎么处理第三方插件自带的shader通常有特殊的引用方式比如通过插件自己的资源管理模块加载静态扫描可能扫不到。对于这类shader我的建议是默认保留除非你确定插件已经完全移除。如果插件确实不再使用了那连同插件一起删掉不要单独删shader。提示清理前建议先备份一份完整的工程或者确保版本控制里所有内容都已提交。批量删除操作一旦执行恢复起来很麻烦。5.5 清理后变体数量没有明显下降有时候shader文件删了不少但变体数量没怎么降。这通常是因为剩下的shader里还有大量未使用的变体。这时候需要进一步做变体清理用ShaderVariantCollection记录实际使用的变体然后在打包设置里只保留这些变体。变体清理的收益有时候比删shader文件还大特别是对于那些变体爆炸的复杂shader。5.6 如何避免清理后再次堆积清理是一次性的但shader堆积是持续性的。要避免这个问题需要在流程上做约束。比如在CI里加入shader使用率检查每次提交如果新增了未被引用的shader就报警或者定期比如每个版本周期跑一次清理扫描把候选清单发给相关同学确认。养成习惯之后shader目录就不会再变成垃圾场了。常见问题排查思路解决方案画面变粉红看控制台报错定位材质恢复shader并加入白名单静态扫描漏扫检查代码中的字符串拼接统一加载接口或运行时追踪平台结果不一致分平台扫描CI加入分平台检查插件shader误删确认插件是否还在用默认保留或连同插件一起删变体没下降检查剩余shader的变体用ShaderVariantCollection清理再次堆积缺乏流程约束CI检查定期扫描6. 工具选型与自动化集成建议6.1 自研脚本还是现成工具市面上有一些现成的shader清理工具但大多数只能做基础的引用扫描对于动态加载和变体的处理不够细致。我的建议是核心扫描逻辑自己写因为每个项目的资源管理方式都不一样通用工具很难覆盖所有情况。自研脚本虽然前期投入大一点但后续可以根据项目需求灵活调整长期来看更划算。6.2 集成到CI流程的具体做法把shader扫描集成到CI里每次打包前自动跑一遍生成报告并归档。如果发现新增了未引用的shader可以在CI里设置一个阈值超过阈值就报警或者阻断打包。具体实现可以用命令行调用编辑器脚本Unity支持-executeMethod参数来运行指定的静态方法。# CI中调用扫描脚本的示例命令 unity -batchmode -quit -projectPath /path/to/project -executeMethod ShaderUsageScanner.Scan -logFile scan.log跑完之后解析生成的报告文件统计候选清理的shader数量和总大小输出到CI的构建报告里。这样每次打包都能看到shader的使用情况趋势一目了然。6.3 团队协作中的沟通要点清理shader不是一个人闷头干的事需要和美术、策划、测试都打好招呼。美术同学可能知道某些shader是给未来功能预留的策划可能知道某些特效只在特定活动里出现。清理前把候选清单发到群里让大家确认一遍比事后出问题再回滚要高效得多。测试同学也需要知道这次清理的范围以便在回归测试中重点关注渲染相关的用例。7. 个人实操心得与后续扩展我在多个项目里做过shader清理踩过的坑不算少。最大的体会是不要相信任何自动扫描的结果一定要用运行时数据做交叉验证。静态扫描能覆盖百分之九十以上的情况但剩下的百分之十往往是最致命的。有一次我删了一个看起来完全没被引用的shader结果上线后才发现某个低端机型上会fallback到它导致那批用户画面全黑。从那以后我再也不敢跳过运行时验证这一步。另一个心得是清理的时机很重要。最好选在版本迭代的间隙不要赶在发版前一周做这种事。清理本身不复杂但验证需要时间万一出问题回滚也需要时间。留足缓冲期心里才不慌。后续如果想进一步优化可以往两个方向扩展。一是自动化变体清理把变体收集和打包设置打通实现变体的自动裁剪二是建立shader使用率的长效监控每个版本自动生成趋势报告让团队对shader资源的增长有直观感知。这两件事做完shader管理基本就进入良性循环了。最后分享一个小技巧在扫描脚本里加一个“最后修改时间”的过滤条件把最近一个月内修改过的shader自动加入保护名单。因为最近改过的shader很可能是正在开发中的功能即使当前没有被引用也不应该被清理。这个简单的规则能避免很多误删实测非常有效。