Unity渲染优化实战：从Draw Call到带宽与光照的系统性预算

1. 为什么这一章值得单独再写一篇：渲染优化从来不是改改参数那么简单

上一章我把 Unity 项目渲染优化的整体思路、Profiler 定位、批处理基础过了一遍。稿子发出去之后，陆续有朋友私信问同一类问题："我就想赶紧把 Draw Call 降下来，你告诉我改哪个开关就行，讲那么多原理干嘛？"

说实话，这种心情我特别理解。我刚入行那会儿也是这样，看见别人说 Dynamic Batching 打开能合并小物体，我项目里所有小模型全勾上，结果合并没有发生，反而多了不少警告日志。后来才明白，批处理能不能生效有一堆前置条件，材质实例化、顶点属性数量、网格层级、光照模式，随便哪一个不满足，引擎就会悄悄放弃合批。不是你开关开错了，是背后的规则你没摸清。

这一篇作为第 8 章的续篇，我会把商业项目里真正用得上、且容易踩坑的渲染优化方案拿出来拆开讲。重点不是复述官方文档，而是把我在真实项目里验证过的东西和踩过的坑整理出来。适合这几类人看：正在做移动端或者低端机适配的 Unity 开发者、被 Draw Call 和 overdraw 反复折磨的 TA 或客户端程序、还有那些觉得自己项目"优化得差不多了"但发热依然很严重的团队。

前一篇我们讲了 CPU 端的批处理和 GPU 端的资源设置，这一篇我会把注意力放在三个更具体的方向：

1. 静态场景和动态物体混在一起时，批处理为什么会失效，以及怎么用数据驱动的方式重新组织场景。
2. 纹理和 Shader 不是越大越好，也不是越省越好，关键在带宽预算和 GPU 缓存命中率。
3. 实时光照在移动端是性能杀手，但烘焙和 Light Probe 用不好，画面又会变平，这个平衡怎么把握。

我会尽量把步骤和代码写完整，顺着能直接复现，并且标注清楚哪些是我个人补充的经验，哪些是引擎的既定规则。这样不管你是刚接触渲染优化，还是已经在项目里做了几轮优化，都能从中拿到一点能落地的东西。

2. 先从 Draw Call 背后的"隐形瓶颈"说起：带宽和顶点吞吐

很多团队在优化渲染性能时，眼睛只盯着一个指标——SetPass Call 或者 Draw Call。工具里数字降下来了，就觉得自己优化成功了，真机上帧率依然不稳，发热依然严重。原因在于，Draw Call 只是 CPU 侧的指令开销，真正的压力往往隐藏在 GPU 的带宽和顶点吞吐上。这一节想把这个概念理清楚，因为后面所有优化手段都绕不开它。

2.1 GPU 做一次渲染，到底在忙什么

你可以把 GPU 渲染一帧想象成一条流水线：应用阶段准备好数据，顶点着色器处理顶点，光栅化生成像素，片元着色器计算颜色。每一步都在消费不同的资源，但大多数时候瓶颈并不在"计算"本身，而是数据从内存搬运到显存、从显存搬运到寄存器的过程。

举个例子。一个普通的 PBR 材质，如果用了 2048 x 2048 的 Albedo、2048 的法线贴图、2048 的 ORM（Occlusion-Roughness-Metallic）图，单物体光纹理数据就有 3 张、每张约 16MB（BC7 压缩后约 8MB 每张），加起来不夸张地说，一次纹理采样就要搬几十 MB 的数据。如果一帧要画几百个物体，每个物体都要采样这些大纹理，即使 Draw Call 只有几十，带宽也可能已经跑满了。

我在真机上用 Xcode 的 GPU Profiler 测过，很多项目的 Fragment Processing 时间并不高，瓶颈在 Texture Bandwidth 一项上，高分辨率纹理全屏铺开时带宽轻松占到 30% 以上。而这种问题，光看 Unity Profiler 的 Draw Call 数字是完全看不出来的。

2.2 为什么低端机总是先扛不住

中高端手机 GPU 一般有 64KB 到 128KB 的 L1 纹理缓存，还有更大一些的 L2。这些缓存的存在是为了让相邻像素采样相同 UV 区域时能命中共用数据。低端机的缓存更小，命中率更低，一旦场景里物体互相遮挡、纹理采样跨度大，缓存会被频繁刷新，带宽压力进一步放大。

这里有一个非常反常识的现象：同屏物体多，不一定比同屏物体少更卡，关键要看它们的纹理是否相似。如果你把几十个不同材质的物体丢在一屏里，每个物体都要采样不同的纹理集，带宽再大也会打折扣。反过来，如果同屏物体共用了同一张图集或同一套纹理，即使 Draw Call 稍微多一些，帧率反而更稳。

我接到过一个项目，美术资源非常"规范"，每个角色单独一套 4096 纹理，一个场景 20 个角色就是 20 套大纹理。我把角色的纹理合并成两张 2048 图集，再把每张图集的 mipmap 开满，帧率直接提升了 15% 左右。Draw Call 因为每个角色还要单独一个材质实例，几乎没有变化，但带宽压力明显下降。这件事给我的启发是：优化不能只看一个维度的数字，带宽和缓存命中率同样重要。

2.3 顶点数据量同样是个坑

除了纹理带宽，顶点吞吐也容易成为隐形瓶颈。高模角色动辄几万面，蒙皮顶点数据还要每帧更新，CPU 要重新计算骨骼矩阵并写回顶点缓冲。如果你的角色在屏幕上只占很小一块，却被完整地送进 GPU 做顶点着色，大部分像素最后都被光栅化丢弃，这就是典型的浪费。

这类问题的通用解法是 LOD（Level of Detail）。Unity 的 LOD Group 组件可以在物体距离变远时切换到低面数模型，配合 LodBias 设置，甚至可以让低端机自动使用更低的 LOD。我在做商业项目时，通常会用下面几档：LOD0 为原始高模，LOD1 减面 50%，LOD2 减面 75%，LOD3 为极简卡片面片。距离切换的阈值不能凭感觉，要结合视角和实际机型测试，否则会出现中距离"突然跳变"的视觉穿帮。

还有一个小技巧：如果你的场景里大量使用 Grass、小石头、树叶这类小物体，可以考虑把它们进一步合并成静态网格，再配合 LOD。单个小物体的 LOD 切换意义不大，但几百个小物体合成一个批次后，LOD 的收益会被放大，因为顶点剔除可以从物体级别提前到块级别。

3. 静态批处理与动态批处理的真实边界：数据驱动重组织场景

现在聊回批处理。Unity 的静态批处理（Static Batching）适合场景中不动的物体，动态批处理（Dynamic Batching）适合小物体，但这两者在商业项目里都有不少"坑"。如果你只是把物体勾选为 Static，或者在 Player Settings 里打开 Dynamic Batching，往往达不到预期效果。这一节我会讲清楚边界，再给一个用数据驱动的方式重组静态场景的方法。

3.1 静态批处理为什么"没生效"

很多人在 Unity 里把场景里的石头、房子、路标都标记成 Static，就以为它们会被合并。实际上，静态批处理有几个前提：

• 物体不能有 Animator、Rigidbody 等动态组件，否则引擎认为它不可静止。
• 每个物体会在世界空间生成一个新的合并网格，内存占用随之上升。
• 如果不同物体用了不同的材质，或者虽然用同一 Shader 但属性不同，引擎会拆开批次。

项目里最常见的坑是第三点。美术同学给三块石头分别换了三张纹理，即使它们共享了同一个材质球，但纹理不同，Unity 在烘焙时不会帮你自动合图，所以批次还是三个。想真正合并，需要先解决纹理和材质一致性问题。

我自己的做法是：在项目早期就建立"材质池"概念，同一类物体的材质尽量复用同一个材质实例。如果纹理细节有差异，可以通过顶点色或者 Mesh 的 UV2 做微调，而不是新建材质。这个习惯写起来容易，推行起来需要美术和 TA 配合，但值得长期坚持。

另一个常见坑是"少量大物体+大量小物体"混合的场景。大物体本身顶点多，即使和一堆小物体合并，合批的收益也不明显，反而因为合并网格要包含所有顶点，内存和上传时间都会上升。遇到这种情况，我通常只把大物体单独处理，小物体单独做合并。

3.2 动态批处理的限制比你想的更多

Unity 动态批处理听起来很省事：只要物体满足条件，引擎会在运行时自动合批。iOS 上它要求顶点数不超过 300，Android 上更是要求 60 顶点以内。这意味着一个稍复杂的小道具模型可能就超过限制，动态批处理直接失效。

而且动态合批条件非常严格：所有要合批的物体必须使用同一个材质实例，Shader 也得相同。如果你的项目里每个对象都 new 一个 Material，那就等于关掉了动态批处理。我记得有个朋友的项目，跑起来 Draw Call 一直降不下来，排查到最后才发现是脚本里写了一句 GetComponent<Renderer>().material.color = ...，这个操作会让每个对象都自动生成材质实例，动态合批全部失效。

如果要让动态批处理真正发挥效果，我一般会：

• 确保所有动态合批候选对象共享同一个材质球。
• 将模型面数控制在 300 面以内，顶点数还要更低一点。
• 避免在运行时修改材质颜色、贴图等属性，实在要改就通过材质属性块（MaterialPropertyBlock）来做，这样能保留合批机会。

3.3 用数据驱动的方式重组静态场景

上一节说过静态批处理的前置条件很多，单纯靠美术手工摆放和勾选 Static 效率极低，而且容易漏。我这里分享一个我常用的小工具思路：通过 Editor 脚本扫描场景里所有 MeshRenderer，把符合条件的物体按"材质 ID + 网格 ID"分组，再按组生成合并网格。

思路并不复杂，核心是这几步：

1. 收集场景里所有静态物体。
2. 按网格 ID 和材质 ID 分组。
3. 对同一组的物体执行 CombineMeshes，生成合并网格，并保存为资产。
4. 用合并后的网格替换原始物体，或者做成一个预处理步骤。

实际项目中，我不会把全场景几万个小物体一股脑合并成一个，那样会导致内存爆炸。更合理的做法是按"可移动性"和"材质一致性"分块。比如一条街的路面、路灯、栏杆放在一个块里，住宅楼的墙面、门窗放在另一个块里，块与块之间不交叉。

还有一点需要留意：合并后的网格是静态的，如果你在场景里做了"动态开门""按钮可交互"之类的功能，这些物体不能合并。我通常会把所有确定静止的物体放进合并集合，其余物体保持独立。这样既能降低 Draw Call，又不会破坏场景玩法。

数据驱动的方式还有一个额外好处：它能把"合并"变成可重复的操作。每次美术修改了场景布局，你只要重新跑一遍脚本，新的合并网格就自动生成，不需要手动一个个检查 Static 标志。我在项目里把这一步挂到了构建流程中，在打包前自动执行，省了不少人工检查的力气。

4. 纹理与 Shader 的带宽预算：在画质和性能之间找平衡

上一节我们提到了带宽，这一节专门展开讲纹理和 Shader，因为它们在移动端渲染优化中占据核心位置。很多团队的优化一直不到位，问题不在于不会用工具，而在于缺少一个量化的"预算"概念——每帧到底能接受多少纹理数据、多少 Shader 指令。没有预算，优化就是凭感觉。

4.1 给每个平台定一个带宽预算上限

在项目立项或者版本验收时，我会先和 TA、主程一起定一个性能目标。以中端 Android 机为例，目标帧率 60 的情况下，单帧 GPU 时间一般不能超过 12ms 到 16ms。纹理带宽一般控制在 GPU 总时间的 20% 到 30%，超过这个比例，就要开始警惕。

具体定预算的方法很简单：用渲染性能分析工具（比如 Unity Frame Debugger、Xcode GPU Profiler、RenderDoc）抓一帧，统计阶段耗时，重点关注 Texture Bandwidth 或者类似指标。测试机型不能只用最新的旗舰机，至少准备一台性能中等的真机。

我在实际项目里做过一张预算表，类似这样：

这个表不是死的，具体项目完全不同，但有了这个表之后，美术在提资源时就有了参照物。比如你告诉美术"这个角色模型 10 万面，预算超标了，需要减到 5 万面以内"，对方就知道不是你在故意卡他，而是有一个共同目标。

4.2 纹理压缩格式和 Mipmap 的正确用法

移动端纹理压缩首选 ASTC（ARM Mali 等）或者 ETC2（大部分 Android 和 iOS 都支持）。老项目里经常看到 RGBA32 的纹理没有压缩，这是最浪费带宽的做法。Unity 里可以通过 Texture Import Settings 把 Android 平台格式设为 ASTC 6x6 或 8x8，iOS 通常也是 ASTC。压缩之后画质会有一点损失，但在移动端屏幕上看基本感知不到，性能收益非常明显。

还有 Mipmap。很多美术觉得 Mipmap 会多占 33% 的显存，于是不勾选。这个想法在移动端需要修正：Mipmap 不光是为了防止远处物体闪烁，更是为了减少缓存压力和带宽。当物体远离相机时，GPU 会采样低精度的 Mip 层级，如果只有最大分辨率那一级，GPU 必须每次都用最高精度的纹素覆盖远处的像素，带宽浪费极其严重。

我的建议是：

• 场景里所有"会缩放到不同距离"的物体，一律开启 Mipmap。
• UI 纹理可以不开 Mipmap，因为 UI 一般不会缩放，开反而浪费。
• 开 Mipmap 后要检查 Streaming Mipmap 选项，如果场景非常大，可以考虑用 Texture Streaming，按需加载。

4.3 Shader 复杂度和指令预算

Shader 是渲染优化的另一个大头。PBR 材质虽然有很好的视觉效果，但计算量大。在移动端，每个像素都要跑一遍漫反射、高光、阴影、环境光等计算，如果还有多个光源，指令数会迅速膨胀。

我用的思路是"分档 Shader"——不是全项目所有物体都用同一套 PBR Shader，而是根据物体用途和视觉重要程度分为三档：

• 高配：场景主角、重要交互物体，用完整 PBR + 法线 + 阴影。
• 中配：普通场景物件，用简化 PBR，去掉全局光照细节，法线可保留但降低精度。
• 低配：远景、小道具、纯色物体，用内置的 Unlit/Simple Lit 或者自定义的移动端 Shader，完全不计算全局光照。

有人担心"分档 Shader"会增加维护成本，我的体验是：只要美术出资源时按规范命名和整理，维护成本完全可以接受。关键在于不要等到优化阶段再做档位拆分，最好在资源创建初就定义好规则，否则后期拆起来相当痛苦。

在 Shader 内部，还有很多可以压榨的地方。比如精度选择上，移动端尽量用 mediump 代替 highp，特别是在片元着色器里。highp 在部分 GPU 上会成倍增加计算开销。又比如，能提前放在顶点着色器里的计算就放顶点，不要放到片元里，因为顶点数远小于像素数，单位计算成本差很多。

4.4 材质属性块和动态合批的配合

回到第 3 节提到的动态合批问题。有时候动态合批失效，不是模型超面数，而是代码里用了 material 属性创建了材质实例。解决这个问题最简单的方式是改用 MaterialPropertyBlock。

举个例子，如果你的游戏里有一堆同材质的柱子，但每根柱子需要不同的颜色或浮点参数（比如生长动画的进度），你可以这样处理：

csharp复制MaterialPropertyBlock block = new MaterialPropertyBlock();
foreach (var renderer in allPillarRenderers)
{
    renderer.GetPropertyBlock(block);
    block.SetColor("_BaseColor", RandomColor());
    block.SetFloat("_Progress", RandomProgress());
    renderer.SetPropertyBlock(block);
}

这样每个 Renderer 虽然有自己的属性值，但不会创建新的材质实例，动态合批依然有机会生效。这是我项目里用的标准做法，比直接改 material 安全得多。

5. 光照模式的选择：实时光照和烘焙的平衡，及 Light Probe 的作用

渲染优化做到最后，光照往往是天花板级别的瓶颈。实时光照在移动端非常昂贵，因为每多一盏实时光，场景中所有受影响的物体都要额外跑一次光照计算。而烘焙光照贴图虽然便宜，却只能处理静态物体，动态物体要在烘焙场景中保持正确光照，离不开 Light Probe。

5.1 什么时候用实时光照，什么时候用烘焙

商业项目里，我的选择标准很简单：

• 静态场景，例如地板、墙壁、石头、建筑，尽量用烘焙。
• 会动态移动或者旋转的物体，例如角色、载具、可交互物品，用 Light Probe 或者实时光照，但数量必须严控。
• 只有极少数情况下，比如"动态天气变化""手电筒"这类需求，才考虑实时光源。

烘焙的优点是计算一次，运行期零开销，缺点是光照不能变化，需要花时间调参数。烘焙的分辨率也要注意，以 2048 光照贴图为例，如果场景里覆盖范围很大，细节会丢失，最好的做法是按区域拆多张，保证每个区域都有足够像素密度。

5.2 光照贴图参数：让画质和内存兼顾

Unity 的 Lighting Settings 里，烘培相关的参数包括：间接光强度、光照贴图分辨率、压缩、采样数等。我常用的移动端配置大概是：

• 光照贴图分辨率：每物体 512 或 1024，场景特别大时用 2048 并分块。
• 压缩格式：优先用 ASTC 或 ETC2 压缩。
• 实时 GI：一般关闭，除非项目明确需要动态全局光。
• 光反弹次数：2 到 3 次，太高会影响烘焙时间且收益很小。

有人会把光照贴图弄成 4096 甚至 8192，追求极致细节。结果真机上光这个项目就要吃掉几十上百 MB 内存，加上纹理，很容易爆内存。我认为移动端合理的做法是，把光照贴图当成和纹理一样的资源来管理，有预算上限，超过就要拆区域或者降分辨率。

5.3 Light Probe：让动态物体"融入"烘焙场景

动态物体不能接收烘焙光照贴图，所以常用 Light Probe 来采样环境光。Unity 里 Light Probe Group 可以放置在场景需要精细光照的位置，运行时，物体的光照值会由周围的探针插值计算出来。

探针的放置是有讲究的，不能随便摆几个。位置过于稀疏，动态物体会出现"飘色"现象——从一个探针过渡到另一个探针时颜色跳变。位置过于密集，存储和插值开销上升，也不划算。我的点位策略是：在玩家活动密集的区域加密放置，比如主要路径、战斗区域、交互点附近；在人迹罕至的地方稀疏一些；在有明显明暗交界的地方，探针间距要更小。

动态物体使用 Light Probe 之后，还需要配合 Shader 里的特效支持。如果你的自定义 Shader 没有声明 UNITY_LIGHT_PROBE_PROXY_VOLUME 或者相关宏，探针很可能不生效。这一点在自写 Shader 时尤其容易踩坑，官方内置 Shader 基本都处理好了，但项目里如果复制了 Shader 自己改，很容易把相关 block 删掉。

5.4 阴影策略：阴影大小和级联层数的选择

光照相关还有一个容易忽略的地方：阴影。实时光阴影在移动端非常吃性能。默认的 Shadow Cascade 是 4 级，PC 上很常见，但移动端最好降到 2 级或者 1 级，因为每增加一级阴影级联，阴影贴图的采样次数和处理量都会上升。

如果场景很大，但只有主角附近需要清晰阴影，我会把 Shadow Distance 调小，比如 15 米到 30 米。超出这个范围的物体就不投射实时阴影，转而使用烘焙阴影。烘焙阴影只需要在光照贴图里保存 AO 和阴影信息，运行期零开销，效果也足够。

我还建议在项目里做一个"阴影预算表"：

5.5 一个实际案例：把"看着还行"的场景优化到稳定 60 帧

最后分享一个真实的优化案例。项目是一个开放街区场景，PC 上跑得很流畅，到了中端 Android 上掉到 30 帧。我接手后，按上一节的思路做了一轮处理：

• 把街道的静态物体重新分组，用合并网格把同材质石头、路灯、长椅合并成 3 个大网格，Draw Call 从 600 多降到了 120 左右。
• 所有角色材质改成三档 Shader 里的中配版本，法线贴图保留，全局光计算去掉。
• 纹理全部转成 ASTC 6x6，开启 Mipmap。
• 光照改成全烘焙，实时光只保留主角头顶的一盏和交互时的一盏补光。
• Shadow Distance 调到 20 米，级联降到 2 级。
• Light Probe 按玩家路径加密放置。

优化后，中端机型稳定 60 帧，不再发热严重，画面观感在高画质模式下差别不大。这次优化最大收获不是学会了某个 API，而是让我意识到：渲染优化必须有个系统性的预算观念，每一项资源都该有上限。

6. 别忘了 Frame Debugger 和真机测试：这些工具能帮你验证优化效果

优化做完不等于结束，验证和回归同样重要。工具用得顺手，能在几分钟内定位到问题，否则就会陷入"改一个参数—跑一下—再改"的循环，效率极低。这一节我会列出我实际最常用的几个工具，以及它们各自适合解决什么问题。

6.1 Unity Frame Debugger：看 Draw Call 的拆分逻辑

Frame Debugger 是 Unity 内置的调试工具，Window 菜单下可以打开。它能列出这一帧所有 Render Pass 和 Draw Call，并查看每个 Draw Call 使用了哪些网格、材质、Shader。对于判断"静态批处理和动态批处理为什么没生效"非常有用。

使用步骤是：

1. 打开 Frame Debugger，点击 Enable。
2. 选择一帧，逐步查看 Draw Call。
3. 比较相邻两个 Draw Call，看是否因为材质不同被拆开，或者因为网格不同被拆开。
4. 如果出现大量"重复网格"的 Draw Call，说明合并条件没满足，需要检查材质实例数量或者网格 LOD 设置。

Frame Debugger 还有一个好处是能直接看到 Mesh 的顶点数、三角形数、使用的 SubMesh，帮助你判断是否该继续减面。

6.2 Xcode GPU Profiler 和 Android GPU Inspector

真机上的性能问题，Editor 里往往看不出来。移动端最常用的两个工具是 Xcode 的 GPU Profiler（通过 Metal 调试）和 Android GPU Inspector（AGI）。它们可以看到更详细的 GPU 阶段耗时，比如顶点处理、片元处理、纹理带宽、渲染通道切换等。

我调试带宽问题时，最常看的是 Texture Bandwidth。如果这个指标高，我会去排查哪些纹理采样频繁、Mipmap 是否开启、压缩格式是否合理。如果 Fragment Processing 高，我会考虑 Shader 复杂度和 overdraw。

用 AGI 时，我一般按这几个步骤：

1. 在真机上部署项目，打开 AGI。
2. 抓取一帧或者连续帧。
3. 查看各个 Render Pass 的时间。
4. 结合 Frame Debugger 中的 Draw Call 列表，定位耗时大的 Pass。

6.3 真机性能测试的几项注意点

真机测试不能只跑一次就不管了。不同机器、不同驱动版本、不同系统负载下，表现会差很多。我一般会固定测试场景和测试路径，做三轮对比：

• 冷启动场景，看加载和首帧耗时。
• 长时间运行场景，看发热和掉帧情况。
• 战斗或特效密集场景，看瞬时卡顿。

测试时最好开启 Airplane Mode 或者关闭推送，避免网络请求带来的额外开销干扰测试结果。还有，一定要用 Release 包，不要用 Development Build，因为后者默认会开启很多调试功能，性能影响不可忽略。

6.4 性能回归自动化：把基线当成代码库一部分

优化最怕回退。一次优化后提升了 30% 帧率，过了两周，美术加了一批新资源，性能又掉回去了。为了应对这种情况，项目里可以建立一个简单的性能基线测试流程。做法是：在 CI 或者本地构建流程里，自动跑一个标准场景，记录关键指标，比如平均帧率、Draw Call 数、内存占用，并和上一次基线对比。如果指标明显恶化，就自动报警。

这个流程不需要很复杂，哪怕只是用脚本记录数字，也比"每次靠人工感觉"强得多。我用 Unity Test Framework 写过最简单的性能回归用例，场景加载后用 Profiler 采集数据，写入 CSV 文件。这样每次跑一次，就能自动生成对比报表。

7. 一些补充：Shader 变体管理和 URP 设置，属于容易忽视的深水区

这一节算是一些补充经验。很多项目的渲染优化做得差不多了，却在 Shader 变体和渲染管线上栽了跟头。我见过一个项目，Shader 文件里只写了一个关键字，结果因为材质球里各种组合没控制好，编译出了上百个变体，安装包体积和加载时间都翻了几倍。

7.1 Shader 变体膨胀是怎么发生的

Unity 的 Shader 会根据材质球上选中的关键字和功能组合，生成多个变体。比如一个 PBR Shader，同时支持 "_NORMALMAP" "_ALPHATEST_ON" "_EMISSION" "_RECEIVE_SHADOWS_OFF" 等关键字，每种组合都会编译出一个变体。如果工程里材质有很多种关键词组合，变体数量会指数级增长。

控制变体数量的方法有几种：

• 在 Shader 里用 #pragma multi_compile 和 #pragma shader_feature 时，尽量用 shader_feature_local，避免所有变体进入全局关键字集合。
• 在 Graphics Settings 的 Shader Stripping 中，去掉项目里用不到的内置变体。
• 用 IVariantStripper 或者 GitHub 上的一些开源工具，在构建阶段自动剥离无用变体。

我自己在商业项目里最常用的做法是：维护一个"关键字白名单"，构建脚本扫描所有材质，检查它们用到的关键字，然后把未使用的关键字对应的 Shader 变体删掉。这样做对安装包体积和加载时间都有明显改善。

7.2 URP 下的优化差异

现在新项目用 URP（Universal Render Pipeline）的越来越多，移动端尤其如此。URP 本身对移动端友好，支持单 Pass 的前向渲染，还内置了 SRP Batcher，这比传统的内置渲染管线更容易获得合批效果。

使用 URP 时，有几个地方要注意：

• 尽量使用 URP 内置的 Lit Shader，而不是自己写复杂 Shader。URP 的 Lit Shader 已经做了很多移动端优化。
• 打开 SRP Batcher，它会在没有材质实例化的前提下，把不同网格、相同 Shader 的物体一次性渲染。前提同样是不要用 material 创建实例。
• URP 的 Shadow Setting 里，可以根据需要调整 Shadow Resolution 和 Cascade Count。移动端建议 2 级。

URP 的 Renderer Features 也很有用。比如你可以添加一个 Renderer Feature 做自定义的后处理特效，但要注意后处理在低端机上成本很高，若项目不需要全屏特效，尽量关闭不必要的 Blit Pass。

7.3 关于 Overdraw 和半透明物体

最后简单说下 Overdraw。半透明物体会渲染多次像素，如果特效层数很多，GPU 的片元着色器负担会骤增。移动端上常见的 overdraw 来源是粒子特效、体积光、全屏渐变等。优化手法是：尽量减少大范围半透明特效叠加，用不透明或近半透明替代。粒子系统里，降低粒子数量和屏幕覆盖面积往往比改 Shader 更有效。

Unity 的 Diagnostics 面板或者 Frame Debugger 里的 Overdraw 可视化可以帮助定位。我在项目里会设计一个"特效预算"，比如同一屏粒子数量不超过 500 个，全屏特效不超过 1 个，这样能避免极端情况下的 overdraw。

8. 最后说点大实话：渲染优化的核心是系统性预算和回归

这一篇写到这里，没有像很多教程那样在最后做个"总结"，但我想把最重要的一个理念再重复一遍：渲染优化的核心不是某个惊艳的开关技巧，而是系统性的预算管理。

你要对项目的 Draw Call、顶点数、纹理带宽、材质实例数、实时光源数、阴影级联数、Shader 变体数都有一个明确的预算。每个预算都对应一个可接受的上限。没有预算，优化就变成了一锤子买卖，今天改这里，明天改那里，过段时间又乱了。

我的实际操作习惯是，在项目的开发规范文档里写一页《渲染性能预算（移动端）》，里面列出各平台的目标帧率、同屏 Draw Call 上限、顶点数上限、纹理总大小上限、实时光源和阴影设置等。每次新功能开发或者资源提交，都对照这张表检查。这样做虽然前期麻烦，但后期节省的调试时间远远超过投入。

另外，渲染优化一定要配合真机测试和性能回归。编辑器里的表现好不代表真机好，真机测一次好不代表长期稳定。把性能基线当成代码库的一部分，自动化地检测回退，才能让你的辛苦优化不被无意识的新增资源悄悄抵消。

如果这一篇里的某个小节对你手头项目有帮助，那我的经验就没有白写。如果你在实际操作中遇到其他怪问题，欢迎在评论里抛出来，我看到的都会尽量回复。