LayaAir 3：从 drawCircle 到固定网格，为什么 drawcall 仍会涨？

本文修订自《LayaAir 3 踩坑：graphics.drawCircle 让 drawcall 只涨不跌》。补充固定网格触发共享 store 扩张的案例，并更正“固定顶点数就安全”“VAO 增加就是泄漏”等过度概括。

源码依据为本项目使用的 LayaAir 3.4 系列 WebGL 构建；历史排查记录标注过 3.4.1。2026-11-10 使用项目实际 Web 构建，在 Chrome 中进行前后对比。内部实现会随版本变化，复现时请核对实际加载的引擎文件。

最初的现象：一个扩散圆环，让普通精灵也拆批了

项目里曾用 Graphics 每帧画一个不断扩大的圆环：

graphics.clear();
graphics.drawCircle(cx, cy, radius, null, color, lineWidth);

效果看起来正常，但 drawcall 从平时十几次涨到四十多次。圆环结束、重开场景后也没有恢复，刷新页面才恢复。

抓帧时更值得注意的不是圆环自己的绘制，而是普通精灵：同一个 program、同一张纹理，仍被拆成多条 drawElements，期间反复切换 VAO。

最初排查锁定了 drawCircle 的自适应细分。把它改为固定段数的多边形后，当时的问题得到缓解。原分享据此给出了“固定顶点数”的建议。

这个建议有用，但它只解决了一个维度。

先分清：command、op、store 和 drawcall

Laya 的 Graphics 绘制大致经过：

业务绘制命令 command
    ↓ 编译
图形 op
    ↓ 分配或复用
render unit + store 中的顶点块与索引视图
    ↓ 形成 render element
按顺序检查兼容性并合批
    ↓
GPU drawElements

一条 Graphics 命令不等于一个 drawcall。多个命令可能编译成同一 op，多个元素也可能合成一次绘制；反过来，画在同一个 Sprite、使用同一张图集，也不能保证只有一次绘制。

store 是共享的，不属于某个特效

当前 WebGL 实现中的 WebGraphicsOpVIStore 持有顶点缓冲、索引缓冲和 bufferState。后者在 WebGL 中关联 VAO。

WebGraphicsOpVIStorePool 先尝试 preferred store，再尝试其他已有 store；都放不下时才新建。当前源码普通新 store 默认提供 4096 个顶点容量，按四个顶点一块分配，单次大申请还可能创建更大的 store。

这是 Graphics 的共享存储，而不是“火花一份、UI 一份”。大型临时特效也会占用普通精灵所在的分配空间。

回收到池里，不等于归还顶点块

WebGraphicsRenderUnitPool 按两个量分桶：

(ceil(vertexCount / blockSize), indexCount)

回收 render unit 时，通常会保留它占有的顶点块，以便之后同尺寸复用。当前池有数量上限，超出时会销毁单元；真正销毁可归还块。因此不能把这个机制说成“所有资源永远不释放”。

但已有 store 不会因为效果结束就自动压缩、迁移剩余数据或从静态 store 列表中移除。容量峰值可能留下长期影响。

第一类压力：尺寸种类不断变化

当前 _drawCircle 会根据半径与 Graphics 变换缩放计算段数。相关源码可概括为：

segments = clamp(floor(radius × scale × 2π / segmentLength), minSegments, maxSegments)

半径连续变化时，段数可能连续变化，于是顶点和索引容量出现许多种组合。每种组合都可能留下一批缓存单元，逐渐增加共享 store 的占用。

这就是原来圆环案例的风险：

半径变化 → 细分数量变化 → 容量桶变多
        → 缓存占块增加 → 新增 store → 元素分布到不同缓冲

固定段数、量化半径或用局部 quad 计算圆形，可以减少尺寸种类。但还有第二类压力。

第二类压力：尺寸固定，总量仍然很大

后来项目的能量回流改成带状拖尾：每颗光点由曲线带和头部组成，顶点数固定，UV 与索引共享。

依然出现 DC 上升。

我们先把头部和拖尾合成每颗一份固定网格，又尝试保留同一条 DrawTrianglesCmd，只更新顶点、颜色与透明度。这些改动减少了命令和重建，却没有消除共享 store 扩张。

原因并不神秘：固定尺寸减少了桶的种类，没有减少这些网格要占用的总容量。

以当次参数为例，每颗 30 个实际顶点，按四顶点块对齐后占 32 个顶点容量。96 个槽位可占 3072 个顶点容量。这还没有算其他普通精灵和缓存单元。

透明、零面积或不再移动的网格，也可能继续持有分配。它们没有可见像素，不代表它们不占 store。

为什么两个 store，能拆出很多 drawcall？

批次兼容性不仅检查纹理和 shader，还检查 bufferState、裁剪、类型与混合状态、globalRenderData，以及自定义材质的数据等。

不同 store 的 bufferState 不同。在当前合批路径里，不能直接合并。

假设普通精灵按画面顺序排列为：

store A → store B → store A → store B → store A

即使它们使用同一图集和同一个 program，也会被分成多段批次。store 只多一个，DC 不一定只多一次。

这也解释了另一个容易误判的现象：storeCount 保持不变，DC 仍可能因为可见节点和绘制顺序变化而继续增加。

另外，批处理可能为不同顶点缓冲与共享索引缓冲创建新的 VAO。抓帧中的 VAO ID 不是 store 下标；仅凭 VAO 数量不能直接判断 store 数量或内存泄漏。

这次怎么验证，而不是继续猜？

在现有 Playwright 工程里，我们通过仅测试启用的 DebugBridge 触发火花：连续四轮，每轮六次击杀效果，奖励设为零，使用隔离浏览器存储。

测试在真实 render pass 的 fillRenderElements 之后、合批之前采样元素序列，关联：

元素对应的业务节点路径；
源 geometry.bufferState 与 Graphics store；
纹理、材质与绘制顺序；
storeCount 和预留缓冲容量。

注意，这份列表是合批前序列，不是 GPU 最终 drawcall 序列。最终提交仍需结合帧调试器看。

对比结果：

| 指标 | 持久 Graphics 网格 | 独立 Mesh2D |
| --- | --- | --- |
| 负载前 Graphics store | 1 | 1 |
| 首轮后及效果结束后 | 2 | 1 |
| Graphics 顶点预留字节 | 262144 → 524288 | 保持 262144 |
| 火花存储 | 共享 Graphics store | 独立缓冲与固定 VAO |

旧版在首轮扩到两个 store，之后没有在这段测试里继续增加。因此，这次证据支持“共享池容量扩张影响合批”，不支持“每帧无限泄漏”。

修复版采样中，普通 Graphics 源 store 不再交错；活动帧截图确认光点、拖尾仍可见，没有页面、shader 或请求错误。

最终修法：让高容量动态特效离开共享 Graphics 池

火花系统改为一份固定容量的 Mesh2D，配一个 Mesh2DRender：

索引与容量：初始化时建立
位置、颜色、UV：独立顶点缓冲
每帧：更新顶点并上传
空闲：禁用 renderer
销毁：释放自己创建的 mesh 与材质

这样火花不再向 Graphics store 申请逐颗网格单元，普通精灵的分配空间不会被这批网格占用。

这不是把同样数据“换个 API 就零成本”。独立 mesh 需要自管容量、上传和生命周期，而且 shader 必须改用对应 BASERENDER2D 接口，不能直接照搬 Graphics 的顶点属性表。

它适合大量动态局部网格；少量稳定 UI 图元仍可以使用 Graphics。也不建议把所有粒子改成一个全屏 shader：每像素遍历大量小光点，可能从 CPU 问题变成片元填充问题。

这算引擎问题吗？

算是引擎存储与合批策略带来的性能限制，但不能直接定性为无限泄漏或 WebGL/VAO 错误。

保留缓存、按尺寸复用、要求同 bufferState 才合批，各自都有合理性。它们叠加后，大型临时几何的峰值会影响共享池的长期分布，业务侧又缺少隔离和自动整理手段，这就是本次实际踩到的限制。

向引擎反馈时，应提供最小复现、实际引擎版本、稳定负载前后指标、节点到 store 的顺序，以及重复负载是否持续新增 store。大网格独立分配、缓存回收和跨缓冲重打包都可以是引擎侧研究方向，但不是本文已经验证的改进。

不建议业务代码强行清私有池、修改容量上限或销毁共享 store；活跃单元仍可能引用这些缓冲。

修正后的实践建议

动态几何同时检查尺寸种类、峰值总量、生命周期和绘制顺序。
固定分段是减少尺寸桶的手段，不是合批保证。固定四边形也不是无条件安全。
保留命令有助于复用，但空闲缓存仍可能占块；类型检查不能证明底层没有新分配。
同 program、同 texture 下切 VAO，先追 bufferState 和 store 分布；不要先削 shader 运算。
区分正常新增效果批次、容量峰值保留、绘制交错与真正持续增长，分别记录证据。
用新预览会话比较修复前后；场景重开不一定重置全局池。
这次测试验证的是指定负载和当前引擎，不代表所有设备与全部玩法的性能保证。

完整实现与复现入口见项目的存储原理和渲染排查。

最后附上我的小游戏《水一箭》，就是画特效遇到的这些drawcall问题