主要是四种众所周知的优化手段的简单总结
1.静态批处理
此术语的详情在静态批处理
即静态批处理的顶点的转换不会在CPU上进行，且静态批处理是先将网格合并，再转换到世界空间，并为它们构建一个共享的顶点和索引缓冲区
- 兼容性
- 需要满足的条件
对第一个红框做说明，比如这里有一堆静态的树，那么变换只对所有树生效且相同时，才会不破坏批处理，如果只是修改单棵树的变化，那么会破坏批处理
- 开启方式
非运行时状态开启
-运行时状态设置
- 副作用
即使用静态批处理会增大内存消耗
2. 动态批处理
此术语的详情在动态批处理
- 兼容性
即高清渲染管线不支持（HDRP）
- 设置方式
- 限制
- 非动态生成Mesh的动态批处理
处理方式为将所有顶点转换到世界空间，这里与静态批处理不同，消耗主要是在CPU上，并且这里还指明了一点，即对于阴影投射器，物体本身的材质可以不同，但阴影依旧可以批量处理
- 动态生成Mesh的动态批处理
粒子系统，Line Renderer，Trail Renderer，这三个renderer会动态生成Mesh
3. GPU Instancing
此术语的详情在GPU Instancing
在这里，有个特殊的点，即“每个实例可以有不同的属性，比如颜色或比例”
解释如下
注意，根据官方文档，Graphics.DrawMeshInstanced方法已经过时，需要使用 Graphics.RenderMeshInstanced 替代，注意，此API一次最多渲染1023个实例
- 兼容性
这里的注意点是GPU Instancing和SRP Batcher不兼容，SRP Batcher的优先级会高于GPU Instancing
这里也指出了当你实在想用GPU Instancing而不是SRP Batcher时，可以直接用Graphics.RenderMeshInstanced
- 限制
这里需要注意的是当调用 Graphics.RenderMeshInstanced 或 Graphics.RenderMeshIndirect时，每一个调用方法都会是一个单独的DrawCall，并且Unity不会合并
- 开启方式
还有就是可以用Graphics.RenderMeshInstanced之类的方法
- 光照方面
- 性能影响
即顶点数量少于256的网格不要使用GPU Instancing
4. Scriptable Render Pipeline Batcher (SRP Batcher)
此术语的详情在SRP Batcher
即SRP Batcher不减少DrawCall数量，只是减少准备DrawCall所需的时间，加快每一次DrawCall的提交速度
- 兼容性
- 使用方式
- 在URP中
- 在HDRP中
- 工作原理
即SRP Batcher的最核心原理就是缓存区，将渲染状态数据存储在GPU的缓存区中，从而加快了渲染速度，且Shader变体需要相同才能被批处理
- 如何使SRP Batcher不兼容
这里的着色器图着色器指Shader Graph
5. 四种方式对比总结
- 原理
| 类型 | 核心原理 | 数据流与执行时机 |
|---|---|---|
| 静态批处理 | 预处理合并网格：在构建时或运行时启动阶段，将多个静态物体的网格永久合并成一个大网格，顶点坐标变换到世界空间 | 构建时：收集物体 → 合并网格 → 存储为资产 运行时：一次DrawCall |
| 动态批处理 | 实时合并小网格：每帧在CPU端，将多个满足严格条件的小型动态物体的顶点数据实时计算并合并到临时缓冲区，提交一次绘制 | 每帧：收集候选 → 检查条件 → 计算世界坐标 → 合并顶点 → 绘制 → 丢弃临时数据 |
| GPU Instancing | GPU并行绘制相同网格：CPU将每个实例的变换矩阵/属性打包成数组，一次性发送给GPU，GPU在顶点着色器中根据实例ID并行处理所有实例 | 每帧：CPU构建实例数据数组 → GPU常量缓冲区 → 一次DrawCall （内部可能分批次） |
| SRP Batcher | 持久化材质状态 + 快速切换对象数据：将材质的Shader属性存储在GPU的持久缓冲区中，每帧仅上传每个对象的变换矩阵到循环缓冲区，绘制时通过对象ID快速索引 | 初始化时：材质数据上传GPU并常驻 每帧：对象变换矩阵 → 循环缓冲区 → 多次DrawCall （但每次仅设置对象偏移） |
- 限制
- 静态批处理
这里相同材质指的是同一个本地材质文件，即Renderer.sharedMaterial要相同
- 动态批处理
这里的材质实例相同其实也是指的同一个本地材质文件，即不能同一个材质的多个副本
