底层机制：ConstantBuffer 合并原理

理解 SRP Batcher 的价值需要先理解传统渲染流程中的 CPU 端瓶颈：

传统渲染流程的开销

在传统渲染流程中，CPU 端每发起一次 Draw Call 需要执行以下操作：

1. 设置 Shader 常量（材质参数、PerObject 属性等）。
2. 调用图形 API 提交渲染命令。
3. 等待 GPU 端开始处理。

虽然单次 Draw Call 的 CPU 开销很小（< 0.01ms），但场景中如果有 1000 个对象，就是 10ms 的 CPU 时间——直接吃掉 60 FPS 目标的 60% 帧预算。CPU 端的瓶颈不在 GPU 渲染本身，而在状态切换。

SRP Batcher 的解决思路

SRP Batcher 的核心创新是把"每个对象独立的 ConstantBuffer"转换为"共享同一 Shader 的所有材质共享一个大的 GPU 缓冲区"。具体实现：

1. 为每个兼容 SRP Batcher 的 Shader 变体，分配一个 Persistent ConstantBuffer（在 GPU 显存中）。
2. 场景中所有使用该 Shader 变体的材质，材质参数被上传到这个共享 Buffer 中的独立槽位。
3. Draw Call 之间不需要重新设置 ConstantBuffer，CPU 端只需要切换槽位索引（< 0.001ms 开销）。

结果：场景中 1000 个对象可能只需要几次 Draw Call（按 Shader 变体分组），CPU 端开销降至几乎为零。

Shader 兼容条件：cbuffer UnityPerMaterial 的标准声明

SRP Batcher 的兼容性由 Shader 的特定声明决定。Unity 在编译时检测 Shader 是否满足条件：

必要条件一：所有材质属性必须声明在 UnityPerMaterial CBUFFER 中

传统的 Shader 写法：

float4 _BaseColor;

SRP Batcher 兼容的写法：

CBUFFER_START(UnityPerMaterial)
float4 _BaseColor;
CBUFFER_END

这一规则的原因是：SRP Batcher 需要把所有材质属性统一管理，而分散的 float4 声明无法被统一管理。

必要条件二：不能使用 PerObject 关键字（部分）

某些 PerObject 关键字（如 UNITY_MATRIX_M 的不同空间版本）会破坏 SRP Batcher 兼容性。Unity 文档列出了所有兼容与不兼容的关键字清单。

必要条件三：不能使用 MaterialPropertyBlock

MaterialPropertyBlock 允许运行时修改材质属性，但这与 SRP Batcher 的"统一缓冲区"机制冲突。使用了 MaterialPropertyBlock 的 Renderer 会被 SRP Batcher 排除在合批之外。

必要条件四：多 Pass Shader 有限制

多 Pass Shader 在 SRP Batcher 中只能合批相同 Pass 数量的对象，且所有 Pass 必须兼容 SRP Batcher。这在自定义 Renderer Feature 场景下经常成为问题。

失效原因完整清单：12 种隐蔽的破坏模式

基于多个独立游戏项目的调试经验，SRP Batcher 失效的常见原因按频率排列：

失效一：使用 MaterialPropertyBlock

最常见的失效原因。MaterialPropertyBlock 用于运行时修改材质属性（如血量剩余时改变颜色），但会被 SRP Batcher 排除。解决方案：使用 MaterialPropertyBlock 替代方案（如 GPU Instancing、Shader 属性数组）。

失效二：Shader Graph 默认输出不兼容

Shader Graph 默认生成的 Shader 可能不满足 SRP Batcher 兼容条件（特别是 Reference 命名空间的属性）。需要在 Shader Graph 的 Graph Inspector 中检查 SRP Batcher 兼容性状态。

失效三：使用 multi_compile 而非 shader_feature

multi_compile 生成的 Keyword 变体如果跨越了材质属性，可能破坏 SRP Batcher 的统一缓冲区。Shader_feature 生成的局部变体对 SRP Batcher 友好。

失效四：场景中存在使用 BRP 材质的对象

从 Built-in 迁移到 URP 的项目经常遗留未升级的材质。这些 BRP 材质的 Shader 不兼容 URP 的 SRP Batcher，会被自动排除在合批外。

失效五：使用了不兼容的渲染状态

某些渲染状态（如 ZTest Always、Blend One One）会破坏 SRP Batcher 的统一处理。需要在 Shader 中尽量使用标准的渲染状态。

失效六：动态加载的 Prefab 材质

运行时通过 Addressable 或 Resources 加载的 Prefab，其材质的 SRP Batcher 注册可能在加载瞬间失败。需要在加载完成后显式调用 Material 重新初始化。

失效七：自定义 Mesh 的 Vertex Layout

某些自定义 Mesh 的顶点格式与 URP 标准不一致，可能导致 Shader 变体选择错误，进而破坏 SRP Batcher 兼容性。

失效八：使用了 Surface Shader

Surface Shader（Unity 旧版的高级 Shader 系统）不兼容 SRP Batcher。必须改写为 HLSL Shader 或 Shader Graph。

失效九：Editor 预览与 Build 行为差异

某些 Shader 在 Editor 中能启用 SRP Batcher，但在 Build 版本中失效。常见原因：Shader 的某些分支在 Build 编译时被剔除，导致变体不匹配。

失效十：动态合批（Dynamic Batching）冲突

当项目同时启用了 Dynamic Batching 和 SRP Batcher 时，URP 会优先选择 Dynamic Batching（因为它更快决策）。需要在 Player Settings 中关闭 Dynamic Batching。

失效十一：变体过多导致缓冲区溢出

极端情况下，过多的材质变体可能超过 SRP Batcher 的缓冲区大小限制。Unity 会回退到传统渲染模式。

失效十二：CPU 端 LateUpdate 修改材质属性

在 LateUpdate 中修改材质属性（如 float4 _Color = newColor）会触发材质的 ConstantBuffer 上传，频繁修改会导致 SRP Batcher 失效。应该使用 MaterialPropertyBlock 或 GPU 端方法。

与 Dynamic Batching 的互斥关系与优先级

Dynamic Batching 是 Unity 传统的自动合批机制，对小网格对象有较好的合批效果。但在 URP 中，SRP Batcher 与 Dynamic Batching 是互斥关系——同一个对象只能选择其中一种合批路径。

优先级规则

URP 的合批决策顺序：

1. SRP Batcher 兼容 → 走 SRP Batcher 路径。
2. GPU Instancing 兼容 → 走 GPU Instancing 路径。
3. Dynamic Batching 兼容 → 走 Dynamic Batching 路径。
4. 都不兼容 → 每个对象独立 Draw Call。

Dynamic Batching 的局限性

Dynamic Batching 的合批对象数量有 300 个顶点的硬性限制（每个对象），且只对共享相同材质的对象有效。在大型 3D 项目中，Dynamic Batching 的作用有限，通常建议直接关闭以避免决策冲突。

Player Settings 配置建议

• SRP Batcher：默认启用，保持开启。
• Dynamic Batching：建议关闭（除非有大量 100 顶点以下的对象）。
• GPU Instancing：保持默认启用，作为 SRP Batcher 失效时的备选。

Shader Graph 与自定义 Shader 的兼容性验证

对独立游戏项目，最实用的 SRP Batcher 兼容性验证流程是：

步骤一：检查 Shader Graph 兼容性

在 Shader Graph 的 Graph Inspector 中，找到 "SRP Batcher" 标签。如果显示 "Compatible"，说明该 Shader Graph 输出兼容 SRP Batcher。如果显示 "Not Compatible"，标签下方会列出具体的不兼容原因。

步骤二：检查自定义 HLSL Shader

对自定义 HLSL Shader，需要手动验证：

1. 所有 Properties 是否声明在 CBUFFER_START(UnityPerMaterial) ... CBUFFER_END 中？
2. 是否使用了不兼容的 PerObject 关键字？
3. Pass 数量是否一致？
4. 是否使用 MaterialPropertyBlock？

步骤三：使用 SRP Batcher 验证工具

Window → Analysis → SRP Batcher 工具可以批量分析项目中的所有 Shader，给出兼容性报告。这是项目级兼容性检查的最高效工具。

Frame Debugger 中 SRP Batch 统计的解读

Frame Debugger 是验证 SRP Batcher 是否实际生效的最终工具。打开 Window → Analysis → Frame Debugger，运行游戏后捕获一帧：

关键指标

• SRP Batch：实际启用了 SRP Batcher 的 Draw Call 数量。
• SetPass Calls：每次 SetPass 调用会触发 ConstantBuffer 切换，是 SRP Batcher 优化的对象。
• Draw Calls：总 Draw Call 数量，可能包括非 SRP Batcher 路径的对象。

理想目标

启用 SRP Batcher 后：

• SRP Batch 数量应占总 Draw Call 数量的 80-95%。
• SetPass Calls 数量应大幅低于总 Draw Call 数量。
• CPU 渲染时间应明显下降。

常见异常解读

• SRP Batch 数量为 0：所有 Shader 都不兼容，需要全面审查。
• SRP Batch 数量远低于 Draw Call 数量：部分对象使用了不兼容的 Shader 或 MaterialPropertyBlock。
• SetPass Calls 仍然很多：可能存在多 Shader 变体切换，需要减少变体数量。

独立项目的系统性启用流程

对正在使用 URP 的独立游戏项目，推荐以下系统性启用流程：

阶段一：现状评估（1-2 天）

1. 用 SRP Batcher 工具扫描项目所有 Shader，记录不兼容 Shader 清单。
2. 用 Frame Debugger 捕获典型场景的渲染数据，建立性能基线。

阶段二：Shader 升级（3-7 天）

1. 优先升级项目内最常用的 Shader（影响最大）。
2. Shader Graph 生成的 Shader 通过 Graph Inspector 检查并修复。
3. 自定义 HLSL Shader 添加 CBUFFER_START(UnityPerMaterial) 包装。

阶段三：代码层清理（2-3 天）

1. 扫描项目中所有使用 MaterialPropertyBlock 的代码，评估迁移到替代方案。
2. 关闭 Dynamic Batching（如已启用）。
3. 建立 Shader 兼容性 Code Review 规范。

阶段四：性能验证（1-2 天）

1. 用 Frame Debugger 重新捕获渲染数据，对比启用前后的 SetPass Calls 与 CPU 渲染时间。
2. 在目标硬件（特别是移动端）上进行实测，验证性能改善。

真实项目案例：SRP Batcher 启用的典型路径

案例一：中型 RPG 项目（500 个独特材质）

初始状态：SRP Batcher 兼容性 60%，SetPass Calls 1200。修复后：兼容性 95%，SetPass Calls 320（-73%）。CPU 渲染时间从 4.2ms 降至 1.8ms。主要修复点：升级 30 个第三方 Shader 到 SRP Batcher 兼容版本，重写 8 个自定义 Shader。

案例二：移动端休闲游戏

初始状态：SRP Batcher 兼容性 40%，性能不达标。修复后：兼容性 90%，Draw Call 从 800 降至 180，CPU 渲染时间从 6ms 降至 1.5ms。主要修复点：移除所有 MaterialPropertyBlock 使用，迁移到 GPU Instancing + 颜色数组属性。

案例三：从 BRP 迁移的策略游戏

初始状态：大量遗留 BRP Shader，SRP Batcher 兼容性 20%。修复后：兼容性 85%。主要修复点：批量重写所有自定义 Shader，统一使用 SRP Batcher 兼容的 CBUFFER 结构，废弃所有 Surface Shader。

初级用户路径：5 分钟验证 SRP Batcher 状态

1. 打开 Window → Analysis → SRP Batcher 工具。
2. 点击 "Clear" 然后 "Check All"。
3. 查看报告中 "Compatible" Shader 数量与 "Not Compatible" Shader 数量。
4. 对 Not Compatible 的 Shader，点击右侧的 "Show" 按钮查看具体原因。

这四步完成，你已经知道项目 SRP Batcher 兼容性的整体状况。不需要立即采取行动，先记录基线数据。

中级用户路径：完整启用清单

对于已经掌握 SRP Batcher 基础知识的中级开发者，建议建立以下工程实践：

1. Shader 兼容性基线：在项目启动时建立 SRP Batcher 兼容性基线（应 > 90%），CI 阶段检测新增 Shader 的兼容性。
2. MaterialPropertyBlock 审查：定期审查项目中的 MaterialPropertyBlock 使用，逐步替换为替代方案。
3. 第三方 Shader 评估：新引入的第三方 Shader 必须在引入前评估 SRP Batcher 兼容性。
4. 性能回归测试：在 Shader 升级或新增场景时，跑性能回归测试，确保 SRP Batcher 状态未退化。
5. Frame Debugger 性能 Profile：作为发布前质量门禁，关键场景的 SetPass Calls 数量应在阈值内。

争议焦点：SRP Batcher 与 GPU Instancing 的取舍

社区中持续讨论的一个争议是：在处理大量重复对象（如草地、树木）时，应该使用 SRP Batcher 还是 GPU Instancing？

支持 SRP Batcher 派：SRP Batcher 是 URP 通用合批方案，对象不需要同质；不需要特殊配置；与所有 Shader 兼容（满足条件时）。反驳意见是 SRP Batcher 对大规模同质对象（数千个相同模型）的合批效率不如 GPU Instancing。

支持 GPU Instancing 派：GPU Instancing 对同质对象的合批效率最高；支持大规模对象（数万个）而不增加 CPU 开销；与移动端 GPU 高度兼容。反驳意见是 GPU Instancing 限制对象必须同质，对异质场景无能为力。

Xmohe 判断：两者不是非此即彼的关系。SRP Batcher 是 URP 项目的"默认合批方案"——所有对象都应该尽可能满足 SRP Batcher 条件；GPU Instancing 是"同质对象的补充方案"——当场景中有大量同质对象时，启用 GPU Instancing 作为性能优化补充。两者共存是 URP 项目的最佳实践。具体的取舍策略将在主题 06（Render Graph）中进一步展开。

Xmohe 编辑观点：SRP Batcher 是 URP 性能优化的"基础设施"——不是可选优化，而是默认就应该启用的最佳实践。本文建立的 12 种失效原因清单是项目级调试的实用工具，开发者应将其作为 Shader 引入与代码 Review 的标准检查项。SRP Batcher 的投入产出比是 URP 所有性能优化中最高的，没有理由不启用。