一、对比背景：为什么需要比较“直绘”与“合批”

在实时渲染中，一帧画面的生成可以粗略划分为CPU阶段与GPU阶段。DrawCall（绘制调用）是CPU通过图形编程接口（Graphics API）发起一次渲染的命令：在渲染管线的应用阶段，CPU需要从硬盘或内存中读取模型、纹理等资源并上传到显存，设置本次渲染所需的渲染状态（材质、着色器、光照、混合模式等），准备好顶点数据与变换矩阵，最后调用一次DrawCall，把“这一批”数据交给GPU。可以简单理解为：DrawCall就是CPU对GPU说的一句“请开始渲染这个物体”。

单看一次DrawCall，指令本身并不重，真正的开销藏在周边环节：API调用与驱动层的参数校验、渲染状态的切换、CPU与GPU之间的命令提交与同步等。当场景中有成百上千个独立物体时，如果每个物体各自提交一次DrawCall，CPU会被大量重复的准备工作占满，GPU反而处于等待状态——这就是典型的“CPU受限”型渲染瓶颈。

因此，实际项目中围绕DrawCall形成了两类基本处理思路：一是保持逐物体提交的结构，仅做局部调优；二是通过合批（Batching）把多次绘制合并为少数几次提交。两种思路在成本结构、灵活性、适用范围上差异明显，值得系统对比，这也是本文的对比主题。

二、对比对象定义

方案A：逐物体直绘（不合并提交）

指场景中每个可渲染物体独立走完“设置渲染状态—准备数据—提交DrawCall”的完整流程。每个物体保留独立的材质、网格与变换信息，渲染逻辑最直观，逻辑对象与绘制表现一一对应。

方案B：合批渲染（Batching）

指在提交前把多个物体的绘制合并为更少的DrawCall。业界通用的合批技术主要有三类：

• 静态合批：在构建期或初始化期，把不会移动的物体的网格数据变换到统一坐标后合并成一个（或若干个）大网格，之后以更少的提交完成绘制；
• 动态合批：CPU在每帧把符合条件的小型动态物体的顶点变换后拼接到临时缓冲中，一次性提交；
• GPU实例化：针对“同一网格、同一材质、仅位置或颜色等实例参数不同”的大量重复物体，用一次DrawCall携带实例数据批量绘制。

三、相同点分析

1. 渲染目标与输出一致：几种方案最终输出的画面内容相同，差异只在于“用什么方式把数据交给GPU”，而不是“画什么”。
2. 遵循同一渲染管线抽象：都要经历应用阶段的资源准备、状态设置与命令提交，以及GPU阶段的顶点处理与像素处理。
3. 都依赖渲染状态与资源管理：材质、着色器、纹理等资源的组织方式，直接决定合并的可行性与状态切换次数，这在直绘与合批中同样成立。
4. 都受CPU/GPU协作效率约束：合批减少的是CPU侧提交次数，并不改变GPU着色计算的基本单位；若瓶颈在GPU填充率或着色复杂度，合批并不能解决问题。

四、核心差异分析

1. 命令提交结构与CPU开销

直绘方案下，N个物体约等于N次DrawCall，每次调用都伴随状态设置与驱动层校验，CPU开销随物体数量线性增长。合批方案将N次提交压缩为1次或少数几次，调用与校验开销大幅下降；但需要注意，不同合批技术是把开销“转移”到了不同位置：静态合批把成本转移到构建期的数据合并，动态合批转移到每帧的顶点变换与拼接，GPU实例化则转移到实例数据的组织与着色器支持上。

2. 内存与数据组织成本

• 直绘：每个物体只保留自身网格数据，内存占用最直接；
• 静态合批：需要额外保存一份合并后的网格副本，原始数据往往仍需保留用于编辑与调试，内存占用明显增加；
• 动态合批：不产生持久化的合并数据，但每帧都要分配与填充临时缓冲；
• GPU实例化：内存占用最小，只需一份共享网格加一份实例参数数组。

3. 渲染灵活性

直绘最灵活，每个物体可独立移动、更换材质、参与不同排序。静态合批合并后以批次为单位，物体不能再单独移动或单独换材质，需要变动时往往要重建批次。动态合批允许物体自由移动，但受“材质相同、顶点量足够小”等条件限制。GPU实例化的实例可独立移动并设置参数，但网格与材质必须相同，灵活性介于两者之间。

4. 剔除与过绘行为

直绘的物体粒度细，视锥剔除效果好，视锥外物体不会产生GPU负担。合批后剔除粒度变粗：同一批次内只要有一个物体可见，整批都可能被提交处理，可能带来额外的顶点处理负担。常见的缓解做法是按空间区域分块合并，在“批次数量”与“剔除精度”之间取得平衡。

5. 排序与透明物体

不透明物体通常可按材质排序以减少状态切换，合批与排序的目标一致；透明物体则需要按深度由远及近排序以保证混合结果正确，强行合批可能与渲染正确性冲突，通常需要保留逐物体排序或限制合批范围。

6. 接入改造与工程约束

直绘零改造但优化空间也最小；静态合批需要预先标记静态物体并纳入构建流程，对频繁变动的场景维护成本高；动态合批通常由引擎按条件自动执行，接入成本低但可控性差；GPU实例化要求材质与着色器支持实例化语义，自定义着色器可能需要改造，接入门槛略高，但在大规模重复物体上收益最显著。

示意性伪代码对比：

// 方案A：逐物体直绘
for obj in scene.visibleObjects:
    setRenderState(obj.material)   // 材质、着色器、混合模式等状态
    setTransform(obj.matrix)       // 变换矩阵
    submitDrawCall(obj.mesh)       // N 个物体 → N 次 DrawCall
// 方案B：GPU实例化示意
mesh, material = sharedResource               // 共用同一网格与材质
for obj in scene.sameKindObjects:
    instanceData.append(obj.matrix, obj.color) // 收集实例差异
setRenderState(material)
submitDrawCallInstanced(mesh, instanceData)    // N 个物体 → 1 次 DrawCall

五、对比表格

对比维度	逐物体直绘	静态合批	动态合批	GPU实例化
DrawCall数量	高，与物体数线性相关	低	较低	最低
CPU每帧开销	高	低	中，随规模上升	低
内存占用	基准	明显增加（网格副本）	较低（临时缓冲）	最低
物体可移动性	完全自由	合并后不可单独移动	自由	自由（实例级参数）
网格/材质要求	无限制	无硬性要求	材质相同、顶点量小	网格与材质必须相同
接入改造量	无	需标记静态、构建期处理	基本自动	需着色器支持实例化
剔除精度	物体级	批次级，需分块缓解	物体级	实例级或批次级
典型场景	物体少、逻辑复杂	建筑、地形装饰等静态物	小型频繁移动物体	植被、碎石、人群等重复物

六、典型场景选择

1. 静态场景元素（建筑、地形装饰、关卡结构）：优先考虑静态合批，构建期一次合并长期受益，但要评估内存预算与区块划分。
2. 大规模重复物体（草地植被、碎石、弹幕、群体角色）：优先考虑GPU实例化，一次提交覆盖成百上千个实例，CPU与内存双收益。
3. 频繁移动的小型动态物体：可依赖动态合批，顶点量过大时每帧拼接成本会得不偿失，需要用数据验证。
4. UI与粒子系统：通常依赖图集、图集合批等通用手段，属于合批思想在不同资源类型上的延伸，需单独评估其排序与混合约束。
5. 材质差异大、结构复杂的角色与道具：合批收益有限，保持直绘并优先控制物体总量与LOD层级更为现实。

七、选型建议

1. 先量化再动手：借助性能分析工具与渲染调试视图确认瓶颈位于CPU提交侧，而非GPU填充率或着色复杂度；若瓶颈在GPU侧，合批收益有限。
2. DrawCall不是越少越好：合并会增加顶点处理量、内存占用与剔除粒度损失；在物体可见率低的大地图场景中，过粗的合并可能反而抬高GPU负载。
3. 按物体生命周期匹配技术：静态物用静态合批，重复物用实例化，动态小物体才考虑动态合批，避免“一种技术打天下”。
4. 混合使用是常态：实际项目通常多种手段并存，应以渲染状态切换次数与每帧CPU渲染耗时作为综合观察指标，而不是只盯DrawCall数字。
5. 按团队与迭代节奏权衡：在迭代频繁、人力有限的阶段，优先选择条件自动、侵入性低的手段；在性能压力大、场景结构稳定的项目中，再投入构建期合并与实例化改造。

八、迁移与使用注意事项

1. 材质与着色器一致性核查：合批以“材质相同”为基本前提，接入前应梳理资源引用关系，避免运行时因材质实例差异意外拆分批次。
2. 着色器改造风险：接入GPU实例化时，自定义着色器需要补齐实例化语义支持，需做全量渲染回归，防止出现绘制错误。
3. 内存预算：静态合批会放大网格内存，需要在包体、显存与性能收益之间做量化权衡，避免“换一种方式超支”。
4. 静态标记时机：物体标记为静态后应避免运行时位移；确需更新时，要评估重建批次的代价与频率。
5. 剔除与遮挡验证：合并后应通过渲染调试视图检查是否存在视锥外过绘，必要时引入空间分块策略。
6. 云端与多端部署：对于运行在云端GPU算力（如基于百度智能云GPU云服务器类服务搭建的云端渲染、云游戏业务）中的项目，合批优化同样能降低每帧CPU开销、提升单机可承载的并发路数；同时要注意不同目标平台图形能力差异带来的支持范围区别。
7. 指标监控与回归：将DrawCall数量、状态切换次数、每帧CPU/GPU耗时纳入性能看板，任何资源或配置变更后做对比回归，防止优化成果被后续迭代悄悄吃掉。

九、总结

DrawCall本质上是CPU向GPU发起的一次绘制命令，其性能问题的根源在于大量重复提交带来的CPU侧开销。逐物体直绘结构清晰、灵活度最高，但物体规模大时容易让CPU成为瓶颈；合批渲染通过更少次数的提交换取性能，代价则体现为内存、灵活性、剔除精度与接入改造等不同形式的成本。静态合批、动态合批与GPU实例化分别在“静态不动、小型移动、大规模重复”三类场景中最具性价比。选型的关键不是追求DrawCall数字最低，而是先定位真实瓶颈，再按物体特性、更新频率与资源预算匹配相应技术，并以量化指标持续验证优化效果。