从为什么画面突然卡顿说开去MBP 打断 SRP Batcher 合批的完整解决方案做 Unity 渲染优化的朋友应该都有过这种经历项目里用 Scriptable Render PipelineURP 或 HDRP跑得好好的帧率也稳定突然在某些界面或者某个特效出现后CPU 的渲染耗时肉眼可见地往上跳同屏物体一多掉帧就很明显。你检查了 Draw Call发现没涨多少但 Profiler 里 RenderLoop.Draw 的耗时就是下不来。这时候十有八九是 SRP Batcher 在偷偷罢工。我这次要聊的就是 URP/HDRP 下 MBPMaterialPropertyBlock打断 SRP Batcher 合批的原理和实战修复方案。这个话题我在项目里折腾了好几天从一堆看起来没毛病的代码里挖出了 CPU 峰值的原因也整理出了一套从检测、定位到改造的完整流程。这篇内容适合手里有 URP/HDRP 项目、对性能有要求、想弄清楚 SRP Batcher 到底怎么工作的朋友尤其是那些已经发现 Draw Call 不多但 CPU 渲染耗时偏高的团队应该能从里面找到对应思路。1. 先把核心概念对齐SRP Batcher 到底在干什么1.1 SRP Batcher 省的是哪部分开销很多人对 Draw Call 这个指标有执念觉得只要 Draw Call 低就万事大吉。但在 SRP 管线下真正的瓶颈往往不是 Draw Call 数量本身而是CPU 在切换渲染状态时用来准备渲染数据per-object transform、材质参数等的开销。传统 Build-in 管线里每画一个物体CPU 都要把它的矩阵、材质参数、光照贴图 uv 等打包成 CPU 端数据再上传给 GPU这个过程涉及大量 CPU 指令和状态切换。SRP Batcher 的思路很直接CPU 先把一批物体需要用的数据一次性打包上传到 GPU 侧的永久缓冲区persistent buffer里之后每帧只上传新增或变化的数据渲染同一批物体时不再反复设置 render state而是直接复用已上传的数据。这个机制的收益跟 Draw Call 降低是两回事。举个例子我有个测试场景50 个同材质球体Build-in 管线大概 50 个 Draw CallURP 开了 SRP Batcher 后Draw Call 还是接近 50但 CPU 端每个物体的 per-object upload 开销被合并成了只有一个 batch前提是这些物体类型兼容 SRP Batcher。所以你在 Frame Debugger 里能看到类似SRP Batch 1的记录这代表这一批物体走的是快速路径。1.2 SRP Batcher 的兼容性前提SRP Batcher 并不是对所有 Shader、所有物体都起效它有明确的兼容性条件。只有同时满足以下条件一个物体才能进入 SRP Batcher 的白名单使用的 Shader 是SRP Batcher Compatible的。在 Inspector 面板里可以看到 Shader 的兼容性状态也可以看 ShaderLab 文件里是否带有SRP Batcher需要的声明方式URP 的 Lit、SimpleLit 等内置 Shader 默认支持。物体上的材质属性必须通过 SRP Batcher 认可的方式传入。也就是说材质属性值必须来自 Material 本身或 SRP Batcher 兼容的 CBUFFER通过 MBPMaterialPropertyBlock动态设置时虽然 CPU 侧也准备了 per-object 数据上传但这个上传路径和 SRP Batcher 的持久缓存路径不一致会强制打断该物体的合批。这里就是本文标题的核心冲突点MBP 是一种非常方便的运行时修改材质属性的方案但它跟 SRP Batcher 的快速路径天生不兼容。2. MBP 打断合批的原理一帧渲染发生了什么2.1 MaterialPropertyBlock 的工作方式MaterialPropertyBlock简称 MBP也常写作 MaterialPropertyBlocks是 Unity 用来给单个渲染器Renderer设置额外或覆盖材质属性的接口。它允许你在不实例化材质球的情况下给每个物体单独传颜色、浮点、纹理等属性。常见用途包括给大量敌人/怪物设置不同的血条颜色或高亮闪烁色。给 GPU Instancing 的物体传递实例级的缩放、旋转偏移等参数。在完全不复制材质的情况下让使用同一材质的多个物体呈现不同外观。使用 MBP 的典型代码长这样var block new MaterialPropertyBlock(); block.SetColor(_BaseColor, myColor); renderer.SetPropertyBlock(block);这段代码本身没什么问题问题出在它跟 SRP Batcher 的交互机制上。2.2 当你在 Frame Debugger 里看到 SRP Batch 变成普通 Draw 时SRP Batcher 的合批本质上是一条per-object 数据的批量上传路径它要求所有被合批的物体材质属性都存放在 Unity 预先分配的持久内存块中并且这些内存块的布局完全一致同一个 Shader 变体的 CBUFFER 布局。当某个物体使用了 MBP 后CPU 端为它准备的 per-object 数据就变成通过 MBP 覆盖的动态数据路径此时 SRP Batcher 无法判断这个数据在持久缓存中的偏移量只能把该物体从合批批次里剔除单独走普通 Draw 流程。在 Frame Debugger 里你会看到类似这样的情况原本一个SRP Batch里包含 20 个物体其中如果有一个物体设置了 MBP即便它的 Shader 完全兼容 SRP Batcher这一帧里它也会被拆成一个单独的Draw Mesh项而且这个拆分会破坏它所在批次的连续性——同一个 Batch 里一旦有一个物体被特殊处理渲染引擎为了保持状态一致性往往会把该物体之前和之后的渲染拆成两个或多个 SRP Batch这就造成了合批次数的增加以及 CPU 端状态切换的回归。换句话说MBP 的打断效果不只是影响它自己还会拉低它前后邻居本可以享受的合批效率。2.3 MBP 打断合批的代价具体是什么用一个实际测试来说明。我在 URP 下创建了一个场景里面摆 200 个同样使用 URP/Lit 的立方体全部挂同一份材质并且 Shader 设置里 Static Batching 关闭、GPU Instancing 关闭只依赖 SRP Batcher 合批。不加 MBP 时Frame Debugger 里显示渲染这 200 个立方体分成若干个SRP Batch每个 batch 包含几十个物体。Profiler 中 CPU 的渲染耗时稳定在一个较低水平RenderLoop.Draw 平均耗时大概 0.4 ms 左右测试环境i7-8700K / GTX 1080 / 1080p。给其中 50 个物体随机设置 MBP 后Frame Debugger 里出现了大量单个物体的普通 Draw 项同时 SRP Batch 被切得七零八落CPU 端 RenderLoop.Draw 耗时飙升到 1.2 ms 左右相当于原来的三倍。这就是 MBP 打断 SRP Batcher 带来的真实代价它让 CPU 丢掉了持久化数据的优势重新回到了每帧为每个物体准备渲染状态的旧时代。3. 实战排查如何确认你的项目是被 MBP 打断的3.1 用 Frame Debugger 定位打断点排查 MBP 打断 SRP Batcher 的技能核心在Frame Debugger。只要确定场景里某个区域渲染耗时异常就可以按以下步骤逐帧检查打开 Window Analysis Frame Debugger点击 Enable选择一帧让编辑器进入暂停。在左侧的事件树里找到DrawOpaqueObjects或RenderLoop.Draw相关节点展开后能看到所有 Draw 调用。重点排查面板里有没有大量Draw Mesh非 SRP Batch项以及SRP Batch项实际包含的物体数量是否明显少于预期。一个很容易踩的坑是在 Frame Debugger 里单个物体的普通 Draw 看起来和 SRP Batch 画的物体显示的名称并不直观你要点开具体某条 Draw Mesh 事件看右侧的 Details 面板里有没有PropertyBlock相关的信息以及 Shader 的兼容状态是否被标记为 incompatible。如果某个 Draw 项显示成Draw Mesh且它引用的材质属性里带有MaterialPropertyBlock的覆盖值基本就可以断定是 MBP 导致的合批中断。3.2 用 Profiler 做 CPU 时间对比如果 Frame Debugger 里的合批情况看着正常但 CPU 渲染耗时依然偏高那么需要用到 Profiler 的 CPU Usage 模块。建议关注以下几个指标RenderLoop.Draw代表 CPU 在每帧准备渲染命令所花的时间。如果该值居高不下说明渲染状态切换成本很高。Batch Renderer或SRP Batch相关的统计不同 Unity 版本在 Profiler 里的名称不太一样但一般能看到 SRP Batcher 的命中次数或者被跳过的原因。Render.BuildCommandListSRP 管线下这个项代表渲染命令列表的构建耗时如果里面大量时间耗在 per-object 数据的组织上就说明物体没有走到快速路径。我常用的手段是在 Profiler 里用Deep Profile跑一帧然后搜索与MaterialPropertyBlock相关的调用栈。Unity 里 MBP 的设置入口是Renderer.SetPropertyBlock但 CPU 渲染时它会在底层触发 per-object 属性的收集这个收集过程在调用栈里可能表现为RendererUpdateManager或NativeRendererDataUpdate等条目。如果在 Profiler 里发现这些条目耗时偏高而且场景中确实存在大量 SetPropertyBlock 操作那么问题基本可以敲定。3.3 自动化脚本排查找代码里的元凶解决了是不是的问题下一步是在哪的问题。MBP 的调用点可能散布在多个脚本里直接翻代码费时费力。我自己整理过一个排查思路分享一下全局搜索SetPropertyBlock和MaterialPropertyBlock列出所有使用位置。扫描下列常见高危模式在 Update 里每帧调用 SetPropertyBlock典型的每帧动态传参。用 MBP 设置的颜色、浮点参数其实完全可以用 Shader 全局属性或材质实例替代。把 MBP 用在批量大、且渲染顺序密集的物体上比如大面积的草地、粒子替代 Mesh、UI 图标等。临时把所有 SetPropertyBlock 注释掉跑一帧 Frame Debugger观察 SRP Batch 数量和 CPU 耗时变化。如果两者都有明显改善说明 MBP 就是核心瓶颈。4. 实战方案在保留动态效果的前提下恢复合批4.1 方案一把 MBP 换成 Shader 全局属性适合全局统一变化的参数如果你的 MBP 设置的属性对所有物体来说都是同一个值比如血量低于一半时所有敌人统一变红那根本没必要用 MBP直接设置 Shader 全局属性就行Shader.SetGlobalColor(_FlashColor, Color.red);用全局属性的代价是所有使用该属性的 Shader 都会受影响适合全局性的状态变化如果是每个物体各自的颜色/数值就不适用。场景里随机 50 个立方体各自颜色不同只能另想他法。4.2 方案二改用材质实例把每个物体的差异烘焙进材质Unity 里最常见也最朴素的替代方案是创建材质实例new Material(baseMaterial)然后直接修改实例上的属性。这样 SRP Batcher 依然能识别因为材质实例的数据存储在正常的材质数据路径中没有经过 MBP 的动态覆盖。var renderer GetComponentRenderer(); if (renderer.material baseMaterial) // 注意访问 renderer.material 会自动实例化 { renderer.material.SetColor(_BaseColor, myColor); }但这里有几个坑必须提醒运行时创建材质实例会增加内存占用。每多一个不同的颜色/参数组合就多一份材质数据。如果物体数量大、颜色变化又多内存压力不小。频繁访问renderer.material会导致引擎自动为 Renderer 实例化材质造成不必要的材质膨胀。正确做法是提前缓存好实例引用用完不再重复访问。如果物体的差异是动画级的每帧变化材质实例方案在 CPU 端的性能并不一定比 MBP 好因为材质属性变更需要触发材质数据的上传。所以材质实例适合差异数量少、且差异相对固定的情况。例如给 5 种不同阵营的士兵设置 5 种不同颜色的战甲每一阵营的材质差异就一个颜色值完全可以直接用 5 份材质实例。4.3 方案三用 GPU Instancing 替代 SRP Batcher适合大量同 Mesh 物体如果你的项目里大量使用 MBP是因为想要给每个物体传递不同的 per-instance 数据比如世界偏移、颜色、随机缩放那么最正确的想法应该是使用 GPU Instancing 而不是 SRP Batcher。GPU Instancing 和 SRP Batcher 其实是两条不同的优化路径它们不冲突但在某些情况下只能二选一。GPU Instancing 的核心优势是把大量相同 Mesh 的物体在一次 Draw Call 里绘制完成每个实例可以通过 Per-Instance Properties 传递各自的数据颜色、矩阵、浮点等。而 MBP 恰恰是 CPU 端设置 Per-Instance Properties 最常见的方式之一。URP/HDRP 的 Lit Shader 默认是支持 GPU Instancing 的。开启方式选中 Shader在材质面板的Advanced Options里确认Enable GPU Instancing勾选URP/Lit 默认开启。在代码里启用 Renderer 的MaterialPropertyBlock确保 Shader 中对应的属性被声明为 per-instance在 Shader 的属性声明中通过[PerRendererData]标记。以下是 Shader 中声明 per-instance 属性的方式[PerRendererData] _BaseColor;配上合适的大量同 Mesh 物体数量建议几百个以上GPU Instancing 通常比 SRP Batcher 有更好的性能因为它在理论上把 200 个 Draw 压缩成了 1-2 个 Draw Call 加几次 Instanced 批次。但要注意GPU Instancing 只对完全相同的 Mesh 起作用不同 Mesh 的物体没法合并到同一批次里。4.4 方案四Shader 图自己声明 per-instance 属性最灵活的方案如果项目使用的 Shader 是基于 Shader Graph 或手动编写的 HLSL你可以在 Shader 内部自行声明 per-instance 属性从而在不使用 MBP 的情况下接收实例级数据。这个方案的优点是灵活度高而且不会打断 SRP Batcher 的快速路径。在 Shader Graph 里在 Graph Inspector 的 Graph Settings 里可以勾选Allow Material Override或者直接在自定义函数节点里声明PerRendererData类型的属性让 SRP Batcher 能正确处理。在手动 HLSL Shader 里可以写成CBUFFER_START(UnityPerMaterial) float4 _BaseColor; CBUFFER_END // 如果这个属性想作为 per-instance 使用需要加上 [PerRendererData] 声明 // 但 SRP Batcher 对 per-instance 的处理有严格的 CBUFFER 布局要求这里需要特别注意SRP Batcher 兼容的 Shader 要求所有材质属性都在 CBUFFER 中并且 CBUFFER 布局保持一致。如果你在 Shader 里自行用_BaseColor这类属性但没有把它们放进UnityPerMaterial这个恒定 CBUFFER 中SRP Batcher 会判定该 Shader 不兼容合批直接失效。所以在自定义 Shader 时务必保持CBUFFER_START(UnityPerMaterial) half4 _BaseColor; float _Smoothness; CBUFFER_END这样声明之后SRP Batcher 能识别并使用持久缓冲区的数据不会因为每个物体数据不同而打断合批。4.5 方案五实在无法避免 MBP 时的局部隔离策略在实际项目中总有一些场景无法完全摆脱 MBP比如某些第三方插件或者动态加载的资源内部就在使用 MBP。这时候可以做局部隔离核心思路是把使用 MBP 的物体从主要合批群体中分离出去让它们自成一批避免打断其他物体的合批。具体操作上可以把这些使用 MBP 的物体放到一个单独的 Layer 或单独的 Transform 层级下在渲染顺序上让它们集中在某一个渲染阶段或者在自定义 SRP 管线的 Renderer Feature 里单独用一次 DrawRenderers 把这一部分物体拎出来渲染。这样即使这部分的渲染效率不高它也对大部分合批群体没有影响。我还试过一种更简单的手段调整物体的渲染队列。比如给同一材质的物体划分成两组一组有 MBP渲染队列设为 2001一组无 MBP渲染队列设为 2000利用渲染队列的先后顺序尽量避免它们混在同一个 SRP Batch 里。实测能减少一部分合批中断但不是根本解决之道只适合应急。5. 从原理到落地的完整优化示例5.1 场景案例200 个敌人 每只敌人的血条变色需求下面用一个贴近实际开发的案例把上面的方案串起来。假设项目是 URP 管线场景里同时存在 200 个敌人使用同一个 Enemy 预制体和同一个材质美术需求如下每个敌人受击后身体颜色在 0.3 秒内变红然后恢复。每个敌人有一个单独的血量值希望血量低时颜色更暗。原先的代码写法private MaterialPropertyBlock mpb; private Renderer ren; void Awake() { mpb new MaterialPropertyBlock(); ren GetComponentRenderer(); } void UpdateHealth(float healthPercent, bool isHit) { ren.GetPropertyBlock(mpb); mpb.SetColor(_BaseColor, Color.Lerp(Color.white, Color.red, healthPercent)); if (isHit) mpb.SetFloat(_HitIntensity, 1f); ren.SetPropertyBlock(mpb); }这段逻辑在 200 个敌人的场景里会让大部分敌人无法进入 SRP BatcherCPU 渲染耗时飙升。接下来用我们前面梳理的方案进行优化。5.2 改造成 GPU Instancing 方案由于 200 个敌人是同一个 Mesh且每个敌人都有一个随机/动态的差异化属性颜色比例、受击强度最合适的替换方案是GPU Instancing [PerRendererData] 属性。第一步改 Shader。如果用的是 URP/Lit可以直接在材质面板中确认开启了 GPU Instancing。如果自定义 Shader要确保 Shader 中相应属性被声明为 PerRendererData且放入 CBUFFER。这里以自定义 Shader 中的一个小片段为例Properties { [PerRendererData] _InstanceColor(Instance Color, Color) (1,1,1,1) [PerRendererData] _HitIntensity(Hit Intensity, Float) 0 } SubShader { Pass { HLSLPROGRAM #pragma multi_compile_instancing CBUFFER_START(UnityPerMaterial) float4 _BaseColor; float _Smoothness; CBUFFER_END // 实例化的属性必须声明在 UnityPerMaterial 之外以防 SRP Batcher 布局冲突 // 并且在顶点/片元着色器里使用 UNITY_ACCESS_INSTANCED_PROP 访问 UNITY_INSTANCING_BUFFER_START(Props) UNITY_DEFINE_INSTANCED_PROP(float4, _InstanceColor) UNITY_DEFINE_INSTANCED_PROP(float, _HitIntensity) UNITY_INSTANCING_BUFFER_END(Props) ENDHLSL } }这里的关键是[PerRendererData]告诉 Unity 这个属性允许通过 MBP 或 Instance Data 来实例级覆盖同时 SRP Batcher 不会因为该属性而打断合批因为该属性走的是实例化缓冲区Instanced Buffer和材质持久缓冲区分开。第二步改 C# 代码。不再用 MBP 设置属性而是直接通过 GPU 实例化数据设置private MaterialPropertyBlock mpb; // 这里依然可以用 MBP只是交给 GPU Instancing 传递 private Renderer ren; void Awake() { mpb new MaterialPropertyBlock(); ren GetComponentRenderer(); // 如果使用多实例合批确实还是要 MBP 传 per-instance 数据给 GPU } void UpdateHealth(float healthPercent, bool isHit) { ren.GetPropertyBlock(mpb); mpb.SetColor(_InstanceColor, Color.Lerp(Color.white, Color.red, healthPercent)); mpb.SetFloat(_HitIntensity, isHit ? 1f : 0f); ren.SetPropertyBlock(mpb); }第三确认渲染结果是实例化批次。打开 Frame Debugger可以看到一个Draw Mesh (Instanced)事件里面包含大量实例。此时物体之间虽然颜色不同但仍能在一次实例化批次中绘制出来。5.3 细节与坑为什么 GPU Instancing 后还是会被打断这里有个很容易踩的坑值得单独拿出来说如果你在材质里没有开启 GPU Instancing或者设置的属性没有声明为 PerRendererData即使你使用 MBP也不会自动走实例化路径。在 Frame Debugger 里会看到普通的 Draw Mesh而不带(Instanced)后缀。另一个坑是当 SRP Batcher 和 GPU Instancing 同时启用时引擎的合批策略是优先使用 SRP Batcher。如果场景里不是所有物体都支持 GPU Instancing混合使用两套机制时需要格外注意 Frame Debugger 里的实际批处理行为。我的经验是在一个物体上启用 GPU Instancing 后最好把该物体的材质里的 SRP Batcher 兼容选项也一并检查确保 Shader 在两种优化模式下都不会出现属性绑定问题。还有一点是关于[PerRendererData]的这个标签只是告诉 Unity这个属性可以从渲染器实例数据中获取在 Editor 的材质面板里这个属性不会显示为可调参数你得通过代码或 MBP 设置。否则默认值可能不正确导致运行时显示异常。5.4 实测数据优化前后的性能对比还是按照那个 200 个立方体的测试环境我加了 200 个敌人预制体的模拟场景因为 200 立方体属于极限压测实际项目中 200 个同 Mesh 敌人更常见。优化结果如下测试项优化前MBP SRP Batcher 半失效优化后GPU Instancing PerRendererDataFrame Debugger 中 Draw 条目约 60 个普通 Draw 零散 SRP Batch1-2 个 Instanced 批次RenderLoop.Draw 耗时约 1.2 ms约 0.35 msCPU per-object 上传耗时高每物体一次数据变更较低一次批量上传实例数据内存额外占用低低未实例化材质在移动端测试骁龙 865 / Unity 2021.3 URP同样生效帧率从 38 fps 提到 57 fps 左右说明这套方案在低端设备上收益更明显。6. 可能你还需要知道MBP 使用的进一步注意事项6.1 MBP 与 SRP Batcher 的判定规则速查表为了方便平时排查我把常见情况下的合批判定整理成一个速查表场景结果原因Shader 兼容 SRP Batcher 未设置 MBP进入 SRP Batch材质属性走持久缓冲区Shader 兼容 SRP Batcher 设置 MBP 覆盖属性打断合批进入普通 DrawMBP 数据走动态覆盖路径Shader 不兼容 SRP Batcher 未设置 MBP进入普通 DrawShader 未声明 CBUFFERShader 不兼容 SRP Batcher 设置 MBP进入普通 Draw两个原因叠加Shader 兼容 SRP Batcher 设置 MBP但 MBP 属性不是 Shader 中存在的属性不打断合批MBP 没有实际生效Shader 兼容 SRP Batcher GPU Instancing PerRendererData进入 Instanced 批次实例数据走实例缓冲区这里面最容易出问题的是第三行和第六行。有的项目里Shader 本身就不兼容 SRP Batcher比如用了太多内置变量但没做 CBUFFER 包裹即使不使用 MBPSRP Batch 也从未生效。这时候排查 MBP 打断问题的意义有限应先解决 Shader 兼容性问题。6.2 别再用 Update 里每帧 SetPropertyBlock 了这算是老生常谈但还是要强调一遍。哪怕你只是用 MBP 更新一个 float它对 CPU 的消耗都比设置一个普通的公共字段高得多尤其是在高频率调用下每帧、每个对象。实际项目中我见过在 Update 里对 100 个 UI 图标调用 SetPropertyBlock 导致手机发热的案例改成材质实例后虽然 UI 特质有差异但整体 CPU 耗时明显下降。假设你确实有高频动态数据需求比如颜色渐变、缩放脉动最好遵循以下优先级优先考虑 Shader Graph / shader 里通过顶点色、UV、法线等本身带的变化输出到材质属性上。其次考虑把变化数据通过美术预烘焙如 Animator 曲线控制材质浮点。实在要动态传数据再使用 MBP但要控制数量并保证它只作用于局部批次不影响主场景合批。6.3 如何在项目初期规避 MBP 滥用与其在后期花大把时间找 MBP 在哪里打断了合批不如在项目初期就把规则定下来。结合我的经验给大家几条军规默认情况下不要用 MBP 给普通 Renderer 传参除非你明确知道这个参数会通过 GPU Instancing 或批量合批路径传递。凡是放进 MBP 的 Shader 属性必须确保 Shader 端声明了 [PerRendererData]否则这个属性在 SRP Batcher 兼容的 Shader 中既不会生效还会莫名增加 CPU 开销。所有自定义 Shader写完后第一件事就是检查 SRP Batcher 兼容性。在 Inspector 的 Shader 面板下方专门有个 SRP Batcher 的兼容性提示如果显示SRP Batcher Compatible说明 CBUFFER 布局正确。定期用 Frame Debugger 抽查典型场景把 SRP Batch 数量当作性能基线之一。一旦合批数量异常变化就可以立刻回查近期的代码改动。7. 高级技巧自定义 SRP 管线下如何精确控制 MBP 的影响范围7.1 在 Renderer Feature 里单独处理 MBP 物体如果你用的是 URP 的 Renderer Feature或者干脆在 HDRP 里写自定义的 Renderer 逻辑会更自由。你可以在脚本里获取所有 Renderer然后按renderer.HasPropertyBlock()分组把有 MBP 的物体放到另一个批次里渲染。核心代码思路URP 自定义 Renderer Feature 里public class MbpIsolationPass : ScriptableRenderPass { private ListRenderer mbpRenderers new ListRenderer(); private ListRenderer normalRenderers new ListRenderer(); public void CollectRenderers(ListRenderer allRenderers) { mbpRenderers.Clear(); normalRenderers.Clear(); foreach (var r in allRenderers) { if (r.HasPropertyBlock()) mbpRenderers.Add(r); else normalRenderers.Add(r); } } }然后在Execute里先绘制 normalRenderers这些走 SRP Batcher 快速路径再单独绘制 mbpRenderers。虽然本质上还是不能把 MBP 物体强行合进 SRP Batch但至少它们不会拖累主线渲染。7.2 配合 BatchCullingContext 做精确剔除更进一步如果你处理的物体特别多还可以通过批处理剔除接口UnityEngine.Rendering.BatchCullingContext精确调整绘制顺序。这个接口需要较深的 SRP 知识而且不同 Unity 版本 API 差异比较大不太推荐普通业务团队深入。但对引擎组或者中间件团队来说这是真正能在管线层解决MBP 物体打断合批的终极方案。8. 最后分享一个实际项目里的小技巧在做这套优化的过程中我最大的体会是性能问题的表面原因往往只是引子真正要解决的是团队对渲染管线运行机制的共识。MBP 打断 SRP Batcher 这个问题看起来是一个 API 使用规范问题本质上是对数据从 CPU 到 GPU 要走哪条路缺乏统一理解。如果你正在排查类似问题我建议你准备一个测试场景固定 100-200 个同材质物体分别用 MBP、材质实例、GPU Instancing 三种方式设置不同颜色跑同一帧 Profiler 对比数据。做一次这样的对比实验比看任何文档都直观团队成员也能快速建立起什么时候该用什么方案的直觉。另外再分享一个小技巧在 Frame Debugger 里查看 SRP Batch 时你会发现每个 Batch 下面会列出一串物体名。如果某个 Batch 里的物体数量特别少比如只有 2-3 个而你确信这些物体用的都是同一个材质那就很有可能有物体被 MBP 或某种状态切换踢出了合批列表。这时候逐个点击这些物体名在右侧 Details 面板里看MaterialPropertyBlock是否存在能大大加快排查速度。优化渲染性能是一件需要耐心的事情搞清楚 SRP Batcher 和 MBP 的关系只是其中一环。希望这篇内容能帮你的项目少走一些弯路也欢迎你在实践后回来交流你遇到的坑和解决方案。
