1. 从一次性能测试的“反常”结果说起前阵子帮一个做移动端项目的朋友看性能问题他们主场景压测跑出来的数据把整个团队都整懵了DrawCall 峰值冲到了 900 多但 GPU 渲染耗时却稳定在 6ms 上下帧率也稳得住。按他们主程的原话“以前做端游的时候DrawCall 过 300 我就开始睡不着觉了现在 900 反而没事是不是统计工具坏了”这个疑问其实特别有代表性。DrawCall 和渲染耗时之间的关系从来就不是一条简单的正比例直线。很多人脑子里有一个根深蒂固的公式DrawCall 高 CPU 提交开销大 渲染慢 掉帧。这个公式在十年前、在 OpenGL ES 2.0 时代、在单线程提交的架构下基本成立但放到今天的硬件和渲染管线上它已经严重失真了。我打算把这件事彻底拆开讲清楚为什么 DrawCall 能到 900 而渲染耗时依然不高这背后到底是哪些机制在起作用以及作为开发者你该怎么判断自己的项目里“高 DrawCall”到底是真问题还是假警报。内容会覆盖渲染管线的提交机制、批处理与合批的边界、GPU 侧的并行能力、CPU/GPU 耗时分离的测量方法以及一套可以直接抄作业的排查流程。不管你是刚接触渲染优化的新手还是被性能数据搞晕的老手看完应该都能对“DrawCall 与耗时”这组关系有一个更清醒的认知。2. 先搞清楚 DrawCall 到底贵在哪里2.1 DrawCall 的成本构成CPU 侧才是主战场要理解“900 个 DrawCall 为什么不慢”第一步得先弄明白一个 DrawCall 到底消耗了什么。很多人下意识觉得 DrawCall 是 GPU 的负担其实恰恰相反——DrawCall 的主要成本在 CPU 侧而不是 GPU 侧。一个 DrawCall 从应用层发出到真正被 GPU 执行中间要经过这么一条链路应用层调用绘制接口驱动层做状态校验和参数打包命令被写入命令缓冲区然后提交给 GPU 前端最后由 GPU 调度到具体的着色器单元执行。这条链路里真正“重”的环节是驱动层的状态校验和命令打包这部分是纯 CPU 工作。具体来说每个 DrawCall 在 CPU 侧大致要做这些事状态检查与切换驱动要对比当前管线状态和目标状态决定哪些需要重新设置。着色器程序、混合模式、深度测试、剔除模式、顶点布局任何一项变化都可能触发状态重设。资源绑定与校验把顶点缓冲、索引缓冲、纹理、常量缓冲等资源绑定到对应的槽位驱动要校验这些资源是否合法、是否已经上传。命令编码把这次绘制的参数编码成 GPU 能识别的命令写入命令缓冲区。提交与同步把命令缓冲区提交给 GPU某些架构下还涉及 CPU 与 GPU 之间的同步点。这一整套下来在移动端单次 DrawCall 的 CPU 开销大概在几微秒到几十微秒之间具体取决于驱动实现、状态切换的频繁程度、以及平台。900 个 DrawCall如果每个平均 5 微秒那就是 4.5 毫秒的 CPU 时间——听起来不少但如果这些开销能被多线程分摊、或者被其他工作掩盖那它对最终帧时间的影响就未必致命。关键认知DrawCall 的“贵”是贵在 CPU 提交不是贵在 GPU 执行。GPU 执行一个 DrawCall 的实际工作量可能只是画几十个三角形对现代 GPU 来说几乎可以忽略。2.2 为什么老经验说“DrawCall 要压到 100 以内”那为什么老一辈开发者会把 DrawCall 卡得那么死这跟当年的硬件和 API 环境直接相关。在 OpenGL ES 2.0 和早期 DirectX 9 的时代绘制提交基本是单线程的驱动层也没有现在这么智能的批处理优化。更关键的是当年的 CPU 单核性能有限驱动开销相对更重一个 DrawCall 的 CPU 成本可能高达几十甚至上百微秒。那时候 300 个 DrawCall 就能吃掉十几毫秒的 CPU 时间直接导致主线程卡死、掉帧。再加上当年的 GPU 填充率和带宽都紧张DrawCall 多往往伴随着大量的状态切换和资源切换这些切换在当时的硬件上代价极高。所以“DrawCall 压到 100 以内”这条经验是那个特定时代的产物它有它的合理性但不能无脑套用到今天。现在的环境已经变了多核 CPU 普及图形 API 支持多线程命令提交驱动层的批处理能力大幅增强GPU 的并行度和吞吐量也今非昔比。同样数量的 DrawCall在今天的环境下 CPU 开销可能只有当年的几分之一甚至十分之一。这就是为什么 900 个 DrawCall 在今天未必是灾难。2.3 现代图形 API 对提交开销的削减真正让“高 DrawCall”变得没那么可怕的是现代图形 API 的架构改进。以 Vulkan、Metal、DirectX 12 为代表的这一代 API把很多原本由驱动在运行时做的校验和状态管理工作提前到了应用层让开发者可以自己控制命令缓冲区的构建和提交。这套机制带来的直接好处是命令缓冲区可以预先录制一次录制多次提交避免了每帧重复的状态校验开销。多线程并行录制多个线程可以同时往不同的命令缓冲区里写命令最后合并提交CPU 提交开销被分摊到多个核心上。显式的状态管理管线状态对象PSO预先创建好运行时直接切换省去了驱动层的隐式校验。在这些 API 下DrawCall 的 CPU 成本被大幅压缩。一个精心组织的渲染器即使有上千个 DrawCallCPU 提交时间也可能控制在 1 到 2 毫秒以内。这就解释了为什么 900 个 DrawCall 的项目渲染耗时依然能保持在一个很健康的水平。3. 渲染耗时到底由什么决定3.1 渲染耗时的真正大头GPU 侧的工作量既然 DrawCall 的成本主要在 CPU 侧那“渲染耗时”这个指标到底衡量的是什么这里必须先厘清一个概念我们平时说的“渲染耗时”通常指的是 GPU 完成一帧渲染所花费的时间也就是从 GPU 开始处理这一帧的命令到所有像素写入帧缓冲、渲染完成的时间。这个时间由什么决定主要由 GPU 侧的工作量决定包括顶点处理量顶点着色器要处理多少个顶点每个顶点的计算复杂度如何。光栅化与像素处理量有多少像素需要被着色像素着色器的复杂度如何有没有过度绘制。带宽压力纹理采样、帧缓冲读写、混合操作带来的显存带宽消耗。填充率GPU 每秒能处理的像素数量受限于 GPU 的 ROP 单元和显存带宽。注意这里面没有一项是直接由 DrawCall 数量决定的。900 个 DrawCall 如果每个只画 10 个三角形那总顶点量才 9000 个对 GPU 来说是小菜一碟。反过来1 个 DrawCall 如果画了 100 万个三角形GPU 照样会被压垮。所以“DrawCall 高但渲染耗时不高”这件事本质上说明的是这个项目的 GPU 侧工作量并不大DrawCall 数量虽多但每个 DrawCall 的实际渲染负担很轻。3.2 CPU 耗时与 GPU 耗时的分离测量要真正诊断“DrawCall 高为什么不慢”必须把 CPU 耗时和 GPU 耗时分开看。很多性能工具会把两者混在一起报导致误判。在移动端常用的分离测量手段有GPU 计时器查询通过 API 提供的 GPU 时间戳查询功能直接测量 GPU 执行某段命令的时间。这是最准确的 GPU 耗时数据。CPU 帧时间分析用性能分析工具抓取主线程和渲染线程的耗时分布看提交命令占了多少时间。帧率与帧时间曲线如果帧率稳定、帧时间波动小说明 CPU 和 GPU 都没有成为瓶颈如果帧时间忽高忽低就要看是 CPU 提交卡顿还是 GPU 执行卡顿。我一般会建议先看 GPU 计时器数据。如果 GPU 耗时确实很低比如 6ms那说明 GPU 侧不是瓶颈DrawCall 多只是 CPU 侧的事。然后再看 CPU 侧提交命令的耗时如果这部分也被控制在合理范围内那这个“900 DrawCall”就真的不是问题。3.3 一个容易被忽略的指标帧时间的一致性除了平均耗时帧时间的一致性同样重要。有些项目平均渲染耗时不高但帧时间抖动严重玩家会感觉到卡顿。这种抖动往往来自 CPU 侧的突发开销比如某一帧突然有大量资源需要上传、或者某一帧的 DrawCall 数量暴增。900 个 DrawCall 如果分布均匀每帧都差不多那问题不大。但如果某一帧突然从 300 涨到 900那这一帧的 CPU 提交开销就会突增可能造成明显的卡顿。所以看 DrawCall 不能只看峰值还要看它的波动情况。4. 900 个 DrawCall 不慢的几种典型原因4.1 原因一单个 DrawCall 的渲染负担极轻这是最常见的情况。900 个 DrawCall但每个 DrawCall 只画很少的几何体比如每个只画一个 UI 元素、一个粒子、或者一个小物件。这种情况下GPU 侧的总工作量很小渲染耗时自然不高。举个具体的例子一个 2D 游戏的主界面可能有几百个 UI 元素每个元素一个 DrawCall。但这些 UI 元素都是简单的四边形顶点数极少纹理也都是小图GPU 处理起来毫无压力。900 个这样的 DrawCallGPU 耗时可能只有 2 到 3 毫秒。判断方法很简单看平均每个 DrawCall 的顶点数和像素数。如果平均顶点数只有几十个那 GPU 侧基本不用担心。4.2 原因二CPU 提交被多线程分摊现代渲染器普遍采用多线程命令录制。主线程负责逻辑和场景管理渲染线程负责构建命令缓冲区甚至可以有多个渲染线程并行工作。900 个 DrawCall 的提交开销被分摊到多个核心上单核压力就小了很多。我见过一个项目主线程提交 DrawCall 的耗时是 3ms但通过多线程录制实际渲染线程的提交耗时降到了 1ms 出头。这种情况下即使 DrawCall 数量翻倍CPU 侧也扛得住。4.3 原因三驱动层或引擎层的自动合批很多引擎和驱动都有自动合批机制。比如把使用相同材质、相同纹理的多个小 DrawCall 合并成一个大的 DrawCall或者把动态合批、静态合批做到极致。你看到的“900 个 DrawCall”可能是引擎统计口径下的数字实际提交给 GPU 的可能已经被合并成了 200 个。这里有个坑不同工具的 DrawCall 统计口径不一样。有的统计的是应用层发出的绘制调用有的统计的是实际提交给 GPU 的命令数。看数据前一定要确认口径否则容易自己吓自己。4.4 原因四GPU 并行度掩盖了提交延迟GPU 是一个高度并行的处理器它可以在等待新命令的同时继续处理已有的命令。只要命令缓冲区里还有活干GPU 就不会闲着。CPU 提交命令的速度只要跟得上 GPU 消费命令的速度就不会出现 GPU 空转。900 个 DrawCall 如果提交得足够快GPU 一直在满负荷工作那渲染耗时就不会因为 DrawCall 多而增加。真正的问题是当 CPU 提交速度跟不上 GPU 消费速度时GPU 会出现“饥饿”这才是掉帧的根源。4.5 原因五瓶颈根本不在渲染还有一种情况项目的瓶颈压根不在渲染而在逻辑、物理、网络或其他系统。渲染耗时低是因为 GPU 确实没干多少活而帧率上不去是因为别的地方卡住了。这时候盯着 DrawCall 看是找错了方向。5. 实操如何判断你的高 DrawCall 是不是真问题5.1 第一步分离 CPU 与 GPU 耗时拿到性能数据后第一件事是把 CPU 耗时和 GPU 耗时分开。具体操作用平台自带的 GPU 计时工具如移动端的 GPU 计时器查询、桌面端的 GPUView 或 RenderDoc抓取 GPU 耗时。用 CPU 性能分析工具抓取主线程和渲染线程的耗时分布。对比两者看谁是瓶颈。如果 GPU 耗时远低于帧预算比如 60 帧下预算 16.6msGPU 只用了 6ms那 GPU 侧就不是问题。如果 CPU 提交耗时也在预算内那这个 DrawCall 数量就是健康的。5.2 第二步看 DrawCall 的“质量”而非“数量”不要只盯着 DrawCall 的总数要看它的构成。我一般会按这几个维度拆解维度关注点健康信号危险信号平均顶点数每个 DrawCall 画多少顶点几十到几百上万平均像素数每个 DrawCall 覆盖多少像素小面积全屏大面积状态切换频率材质、纹理、着色器切换次数切换少频繁切换批次大小每个批次包含多少绘制批次大批次碎如果 900 个 DrawCall 都是小批次、低顶点、低像素那它大概率不是问题。如果其中有一些 DrawCall 画的是全屏特效、高面数模型那就要重点关注这些“重”的 DrawCall。5.3 第三步压测边界找到真正的拐点想知道 DrawCall 到底多少才会出问题最直接的办法是做压测。逐步增加 DrawCall 数量观察渲染耗时和帧率的变化找到那个“拐点”。具体做法从当前场景出发复制一批相同的渲染对象把 DrawCall 数量逐步推高。每次增加后记录 GPU 耗时、CPU 提交耗时、帧率。画出曲线看耗时随 DrawCall 增长的斜率。如果曲线在 900 之前一直很平缓说明还有余量如果某个点之后突然陡增那就是拐点。这个拐点因项目、因平台、因硬件而异没有统一标准必须自己测。5.4 第四步用工具验证合批效果如果你怀疑引擎的自动合批在起作用可以用抓帧工具如 RenderDoc、Xcode GPU Capture抓一帧看实际提交给 GPU 的绘制命令有多少。对比引擎统计的 DrawCall 数量就能知道合批省了多少。我遇到过引擎统计 800 个 DrawCall、实际提交只有 150 个的情况。这种情况下优化引擎统计口径下的数字意义不大因为 GPU 实际承受的压力只有 150 个 DrawCall 的量级。6. 常见问题与排查技巧实录6.1 问题速查表现象可能原因排查方向解决思路DrawCall 高但 GPU 耗时低单个 DrawCall 负担轻看平均顶点/像素数无需优化或优化 CPU 提交DrawCall 高且 CPU 提交耗时高提交开销大看渲染线程耗时多线程录制、合批、减少状态切换DrawCall 高且帧率抖动提交不均匀看每帧 DrawCall 波动平滑负载、预录制命令DrawCall 统计高但抓帧少引擎合批生效对比统计与抓帧确认口径关注实际提交降低 DrawCall 后耗时没变瓶颈不在 DrawCall全面性能分析转向真正的瓶颈6.2 避坑技巧一别被统计口径骗了不同引擎、不同工具的 DrawCall 统计口径差异很大。有的把每个渲染批次算一个 DrawCall有的把每个材质切换算一个有的把阴影 pass、后处理 pass 都算进去。看数据前先确认口径否则容易做出错误判断。我的习惯是以抓帧工具看到的实际提交命令数为准引擎统计的数字只作为参考。抓帧看到的是 GPU 真正收到的东西这才是硬道理。6.3 避坑技巧二区分“提交耗时”和“执行耗时”很多人把“渲染耗时”笼统地理解为一个数其实它至少包含两部分CPU 提交命令的耗时和 GPU 执行命令的耗时。这两者的优化手段完全不同。CPU 提交耗时高优化方向是减少 DrawCall、多线程录制、减少状态切换。GPU 执行耗时高优化方向是减少顶点数、降低像素复杂度、减少过度绘制、优化带宽。搞混了方向优化就是白费力气。6.4 避坑技巧三关注“最慢的那一帧”平均数据会骗人。一个项目平均渲染耗时 6ms但偶尔有一帧飙到 20ms玩家就会感觉到卡顿。排查时要特别关注那些耗时异常的帧看它们有什么共同点是不是 DrawCall 突然增多是不是有资源上传是不是有 GC我一般会抓一段时间的帧数据按耗时排序重点分析最慢的那 1% 的帧。这些帧往往藏着真正的问题。6.5 避坑技巧四别为了降 DrawCall 而过度合批合批是有代价的。把多个小物件合并成一个大网格会增加内存占用可能增加顶点处理量还可能因为合并后无法做视锥剔除而浪费 GPU 资源。为了把 DrawCall 从 900 降到 300 而付出巨大的内存和剔除代价未必划算。优化的目标是让帧时间达标不是让某个指标好看。如果 900 个 DrawCall 下帧时间已经很健康那就没必要为了数字好看去折腾。7. 从“数字焦虑”回到“体验优先”做性能优化这些年我最大的体会是指标是手段不是目的。DrawCall 数量、渲染耗时、帧率这些都是帮助我们定位问题的工具而不是需要盲目追求的目标。900 个 DrawCall 不慢说明这个项目的渲染架构在 CPU 提交和 GPU 执行之间找到了一个平衡点。它可能用了多线程录制可能受益于现代 API 的低开销可能每个 DrawCall 的负担都很轻也可能引擎的合批帮了大忙。不管是哪种原因只要最终玩家体验流畅这个数字就是健康的。真正需要警惕的是那种“看到数字高就慌、看到数字低就放心”的思维定式。性能优化最怕的就是不看实际数据、不分离瓶颈、不区分场景拿着一条放之四海而皆准的经验就往项目上套。每个项目、每个平台、每代硬件都有自己的特性只有实测出来的数据才是可信的。如果你现在正被类似的问题困扰我的建议是先把 CPU 和 GPU 耗时分开测再看 DrawCall 的构成和质量然后做压测找拐点。三步走下来你自然就知道自己的高 DrawCall 到底是不是问题了。至于那些“DrawCall 必须压到多少以内”的说法听听就好别当真。