WebGL：纹理、网格、批次与绘制调用

依据：官方文档与本站教学拆解｜环境：WebGL 通用原理；目标 API 与扩展依设备而定｜真机：未验证

一个看似二维的图标，在 WebGL 中可以是两个三角形组成的矩形，附带纹理坐标和颜色。GPU 按顶点位置生成覆盖区域，再由片元着色器为这些区域计算颜色。使用引擎时，大部分底层工作由引擎管理，但理解它能帮助判断性能边界。

图片怎样贴到三角形上

网格保存位置等顶点数据，UV 决定从纹理哪里取颜色，Shader 定义如何计算输出，绘制调用把相关状态交给 GPU。透视并不是必须的：正交投影就能组织普通的 2D UI。WebGL 也不会自动给这个矩形增加按钮事件。

图片资源被上传为纹理，往往会在多帧间复用。频繁创建、上传或销毁资源与单纯移动对象的成本不同；只看画面上的对象数无法解释全部开销。

兼容的对象可以由引擎组织为更少的绘制调用，但合批需要满足相应条件。纹理、材质、混合、裁剪或顺序变化都可能形成边界。透明对象还经常需要保持正确的覆盖顺序，因此不能为了少一次调用任意重排。

一次绘制也不一定轻。一个覆盖全屏的复杂 Shader 可能对大量像素执行计算；多个半透明全屏层还会反复处理同一区域。相反，较多的小绘制有时主要受 CPU 提交开销影响。优化前应区分 CPU、GPU、资源上传和内存压力。

为了把统计数字压低而把大量资源塞入巨大图集，结果启动变慢、纹理驻留增加，未必有益。另一种错误是把发光滤镜铺满屏幕，却因调用数很少就认为“很轻”。需要在代表性设备上同时观察帧时间、纹理与内存、加载过程和最复杂场景。

WebGL 1、WebGL 2、扩展支持与目标微信运行环境不能混写成一个“支持 WebGL”。使用特定纹理格式、渲染目标或 Shader 功能时，应记录具体版本与能力检查；图形上下文丢失后，应用也需要正确恢复资源。引擎提供了封装，仍不能替代发布平台验证。

理解到这里就足够进入Shader。日常 UI 开发通常先使用引擎提供的 Sprite、Label、Mask 等组件，再根据测量结果处理批次和材质。

Khronos WebGL 1.0 规范提供管线与状态定义；Cocos UI 合批说明引擎层的批次组织条件。本站批次图为概念示意，不是任何项目的实测调用记录。