GLES2渲染优化实战：PvZ-Portable批处理与状态缓存提升帧率

1. 从一次掉帧说起PvZ-Portable 渲染路径到底卡在哪植物大战僵尸的移植版在社区里一直有人折腾PvZ-Portable 算是其中完成度比较高的一个方向。它把原本跑在特定平台上的游戏逻辑抽出来用相对通用的图形接口重新实现渲染让这套老游戏能在更多设备上跑起来。我最初接触这个项目的时候想法很简单一个 2D 塔防游戏画面元素无非就是草坪、植物、僵尸、子弹、阳光能有多吃性能结果实测下来在中低端安卓设备上僵尸一多、子弹一密集帧率就开始往下掉尤其是那种满屏豌豆射手齐射的场面掉帧非常明显。问题不在游戏逻辑逻辑部分跑得飞快。瓶颈全在渲染路径上。具体来说是每一帧都在重复做大量本可以避免的工作重复的矩阵计算、重复的状态切换、重复的纹理绑定、重复的绘制调用。这些东西单看一次开销都不大但一帧里累积成百上千次就成了压垮帧率的最后一根稻草。这篇文章我想聊的就是怎么把这条渲染路径上的重复工作砍掉。核心思路围绕GLES2和OpenGL这套移动端常见的图形接口展开因为 PvZ-Portable 在移动端主要就是靠 GLES2 来出画面的。如果你正在做手游性能优化或者手头有个用 OpenGL 渲染的 2D 项目觉得帧率上不去这里面的思路应该能直接抄作业。我会把每一步为什么这么做、参数怎么定、坑在哪里都讲清楚尽量让你看完就能动手改。先说结论方向渲染路径优化的本质是把每帧重复计算的东西缓存下来把每帧重复提交的东西合并起来把每帧不必要的状态切换去掉。听起来像废话但真正落到代码里每一块都有讲究。2. 渲染路径的整体设计与优化思路拆解2.1 先搞清楚一帧里到底发生了什么在动手优化之前必须先把当前渲染路径摸清楚。PvZ-Portable 的渲染大致是这样一条链路游戏逻辑更新完所有实体的位置和状态之后进入渲染阶段遍历所有需要绘制的对象对每个对象做一次完整的绘制流程。这个流程包括几个步骤计算这个对象的世界变换矩阵把矩阵传给着色器绑定这个对象用的纹理设置混合模式等渲染状态最后发起一次绘制调用。一帧里如果有 200 个可见对象这条链路就走 200 遍。问题在于这 200 个对象里绝大多数用的是同一张纹理图集混合模式也完全一样变换矩阵里大部分只是平移不同。也就是说200 次流程里真正有差异的部分可能只占很小一块剩下的全是重复劳动。我做过一个粗略的统计在一个僵尸密集的场面里单帧的绘制调用能到 300 次以上其中纹理绑定操作有 300 次左右但实际用到的不同纹理只有个位数。矩阵上传操作 300 次但其中旋转和缩放的变化极少大部分只是位置不同。这就是典型的重复工作。2.2 优化的三个层次我把优化分成三个层次从易到难收益也从小到大。第一个层次是减少重复计算。矩阵、颜色、UV 这些每帧都要算的东西能缓存的就缓存能预计算的就在初始化阶段算好。这个层次改动最小风险最低收益也比较直接。第二个层次是合并绘制调用。把用同一张纹理、同一套渲染状态的对象攒到一起一次性提交。这就是常说的批处理batching。这个层次改动中等需要重新组织渲染数据的结构但收益很大绘制调用能从几百降到几十甚至个位数。第三个层次是消除冗余状态切换。OpenGL 的状态机是有开销的每次切换纹理、切换混合模式、切换着色器程序驱动层都要做一堆校验和准备工作。把相同状态的绘制排在一起避免来回切换能省下不少开销。这三个层次不是互斥的实际做的时候是叠加的。我建议的顺序是先做第一层把能缓存的都缓存了再做第三层把状态切换理顺最后做第二层上批处理。因为批处理会改变数据组织方式如果前面没理顺后面改起来会很乱。2.3 为什么选 GLES2 作为优化基准有人可能会问现在都什么年代了为什么还在 GLES2 上做优化不直接上 GLES3 或者 Vulkan这个问题很实际。PvZ-Portable 的目标是尽可能广的设备覆盖包括一些比较老的安卓机。GLES2 的兼容性是最好的几乎所有的移动 GPU 都支持。GLES3 虽然功能更强但在一些低端设备上支持不完整Vulkan 就更不用说了驱动质量参差不齐。而且对于 2D 游戏来说GLES2 的能力完全够用。我们不需要复杂的几何着色器不需要计算着色器就是简单的纹理贴图和混合。在这个前提下把 GLES2 的渲染路径优化到极致比换一个更高级的接口但优化不到位效果要好得多。提示如果你的项目已经确定只跑在新设备上GLES3 的实例化绘制instancing能进一步减少绘制调用但 GLES2 没有这个特性所以批处理只能靠手动合并顶点数据来实现。这是 GLES2 优化的一个关键约束后面会详细讲。3. 核心细节解析与实操要点3.1 矩阵计算的缓存策略先说矩阵。每个可绘制对象都需要一个模型矩阵把局部坐标变换到世界坐标。在 PvZ-Portable 里大部分对象只有平移没有旋转和缩放。原来的做法是每个对象每帧都重新构造一个 4x4 矩阵然后上传给着色器。这里有两个浪费。第一构造矩阵本身有计算开销虽然不大但乘以几百次就不小了。第二上传矩阵是一次 GL 调用几百次上传就是几百次调用。我的做法是把矩阵计算拆开。对于只有平移的对象模型矩阵其实就是一个平移矩阵而平移矩阵和投影矩阵相乘的结果可以预先算好一个基础矩阵然后每个对象只需要在这个基础上加上自己的偏移量。更进一步如果投影矩阵在一帧内不变通常是这样那么可以把投影矩阵和视图矩阵预先乘好存成一个常量每个对象只需要传一个二维偏移量给着色器让着色器自己完成最终的坐标计算。具体来说着色器里可以这样写// vertex shader attribute vec2 a_position; attribute vec2 a_texCoord; uniform mat4 u_mvp; // 投影 * 视图一帧内不变 uniform vec2 u_offset; // 每个对象的平移偏移 uniform vec2 u_scale; // 缩放没有缩放时传 (1,1) varying vec2 v_texCoord; void main() { vec4 worldPos u_mvp * vec4(a_position * u_scale u_offset, 0.0, 1.0); gl_Position worldPos; v_texCoord a_texCoord; }这样每个对象只需要上传u_offset和u_scale两个 vec2而不是一个完整的 mat4。上传的数据量从 64 字节降到 16 字节而且省掉了 CPU 端的矩阵乘法。实测下来这一项在对象数量多的时候能省下可观的 CPU 时间。注意u_mvp这个 uniform 在一帧内只需要设置一次不要在每个对象绘制前都设置。GL 的 uniform 设置是有开销的尤其是当驱动需要重新编译着色器状态的时候。把不变的 uniform 提到循环外面是很容易被忽略的优化点。3.2 纹理绑定的合并与图集化纹理绑定是渲染路径上的另一个大头。每次glBindTexture调用驱动都要检查这个纹理是否已经绑定如果没有则执行绑定操作可能还涉及到纹理参数的重新设置。在 PvZ-Portable 里原来每个对象绘制前都绑定一次纹理即使连续几个对象用的是同一张纹理。最直接的优化是加一个缓存记录当前绑定的纹理 ID如果这次要绑的和上次一样就跳过。这个改动很小但效果立竿见影。我实测在一个典型场面里纹理绑定调用从 300 多次降到了 20 多次。但光靠缓存还不够因为对象之间的纹理使用顺序是随机的缓存命中率有限。更彻底的做法是图集化把所有小图打包到一张大图里所有对象都用这一张图集这样纹理绑定就只需要一次。PvZ-Portable 本身就有图集的概念但原来的实现里图集分了好几张而且对象绘制顺序没有按图集排。我的做法是把所有静态资源合并到一张 2048x2048 的图集里这个尺寸在 GLES2 设备上兼容性最好最大纹理尺寸低于这个值的设备很少然后调整绘制顺序让同一张图集的对象连续绘制。这样纹理绑定基本就固定在一次了。图集化的关键是 UV 坐标的重新计算。每个精灵在图集里的位置变了对应的 UV 也要跟着变。这部分最好在资源加载阶段就处理好把每个精灵的 UV 矩形预先算好存起来渲染时直接取用不要在每帧里现算。3.3 渲染状态排序与状态机优化OpenGL 是个状态机混合模式、深度测试、剔除模式这些都是状态。每次状态改变驱动都要做相应处理。在 PvZ-Portable 里不同对象的混合模式可能不同比如普通精灵用普通混合发光效果用叠加混合。如果绘制顺序不按混合模式排就会频繁切换状态。我的做法是在每帧开始渲染前先对所有可见对象做一次排序排序的键依次是着色器程序、纹理、混合模式。排序之后相同状态的对象就聚在一起了状态切换次数大幅减少。排序本身有开销但对象数量在几百这个量级时排序的开销远小于状态切换省下来的开销。如果对象数量特别大可以考虑用桶排序或者基数排序但对于 PvZ 这种规模标准库的排序足够了。这里有个细节排序会改变绘制顺序而 2D 游戏的绘制顺序往往决定了遮挡关系。所以排序的键里必须包含一个层级或者 Z 值保证遮挡关系正确。我的做法是给每个对象一个渲染层级排序时先按层级排同层内再按状态排。这样既保证了遮挡正确又优化了状态切换。3.4 顶点数据的组织与批处理批处理是收益最大的一步。核心思想是把多个对象的顶点数据合并到一个缓冲区里一次绘制调用画完。在 GLES2 里没有实例化绘制所以只能手动合并。具体做法是维护一个动态顶点缓冲区每帧把所有要绘制的对象的顶点按顺序写进去然后一次glDrawArrays或者glDrawElements画完。每个对象的顶点数据包括位置、UV、颜色。位置是对象在屏幕上的位置加上精灵的局部坐标UV 是精灵在图集里的 UV颜色用于 tint 效果。合并的时候要注意只有状态相同的对象才能合到一批里。所以批处理的单位是“状态批次”每个批次内的对象共享着色器、纹理和混合模式。一帧里可能有几个批次每个批次一次绘制调用。顶点缓冲区的管理是个关键点。不要每帧重新创建缓冲区那样开销很大。正确的做法是创建一个足够大的缓冲区每帧更新里面的数据。GLES2 里可以用glBufferSubData来更新或者用glMapBufferOES直接映射内存写入这个扩展在 GLES2 设备上支持度不错但需要检查。我用的方案是双缓冲准备两个顶点缓冲区一帧写这个下一帧写那个避免写入时 GPU 还在读上一帧的数据。这个技巧在移动端尤其重要因为移动 GPU 的架构和桌面不同对缓冲区的读写冲突更敏感。提示批处理的大小要控制。一次绘制太多顶点可能会超出驱动的内部限制导致性能反而下降。我的经验是每批控制在 1000 到 2000 个顶点左右比较稳妥超过这个数就拆成多批。具体阈值因设备而异需要实测。4. 实操过程与核心环节实现4.1 改造前的基准测试动手之前先建立基准。我在一台中端安卓设备上跑了一个固定的测试场景满屏豌豆射手对着一波僵尸持续射击持续 60 秒记录平均帧率和最低帧率。改造前的数据是平均 42 帧最低 28 帧卡顿感明显。同时用 GPU 调试工具抓了一帧的渲染调用统计下来绘制调用 312 次纹理绑定 318 次uniform 上传 900 多次状态切换 200 多次。这些数字就是优化的靶子。4.2 第一步矩阵与 uniform 的缓存改造先改矩阵部分。把投影矩阵和视图矩阵预先乘好存成一个全局的 mat4每帧只更新一次。每个对象的绘制循环里只上传 offset 和 scale。代码结构大致是这样// 每帧开始时设置一次 glUseProgram(program); glUniformMatrix4fv(u_mvp_location, 1, GL_FALSE, mvp.data()); // 每个对象绘制时 glUniform2f(u_offset_location, obj.x, obj.y); glUniform2f(u_scale_location, obj.scaleX, obj.scaleY); // ... 绑定纹理、绘制改完之后再测平均帧率到了 48 帧最低 33 帧。提升有但还不够。GPU 调试工具显示绘制调用次数没变说明瓶颈还在绘制调用和状态切换上。4.3 第二步纹理绑定缓存与状态排序加纹理绑定缓存很简单维护一个GLuint currentTexture变量绑定前比较一下。状态排序稍微麻烦一点需要在渲染前对对象列表排序。排序的键我设计成一个 64 位整数高 32 位是渲染层级低 32 位是状态哈希着色器 ID、纹理 ID、混合模式组合出来的。这样一次排序就能同时保证遮挡正确和状态聚合。uint64_t sortKey (uint64_t(layer) 32) | stateHash; std::sort(renderList.begin(), renderList.end(), [](const RenderItem a, const RenderItem b) { return a.sortKey b.sortKey; });这一步之后纹理绑定降到了 30 次左右状态切换降到了 40 次以下。帧率到了平均 53 帧最低 38 帧。已经能感觉到明显流畅了但离满帧还有距离。4.4 第三步顶点批处理的实现批处理是重头戏。我实现了一个SpriteBatch类核心是一个动态顶点数组和一个索引数组。每帧开始时清空然后遍历排序后的渲染列表把每个对象的四个顶点和六个索引追加进去。当遇到状态变化时就把当前批次提交绘制然后开始新批次。顶点格式我用了位置2 个 float、UV2 个 float、颜色4 个 unsigned byte。颜色用 byte 而不是 float是为了省带宽。一个顶点 20 字节1000 个顶点才 20KB对移动设备很友好。struct Vertex { float x, y; float u, v; uint8_t r, g, b, a; };提交批次的时候用glBufferSubData更新顶点缓冲区和索引缓冲区然后一次glDrawElements。索引缓冲区的好处是四个顶点可以复用六个索引画两个三角形比glDrawArrays的六个顶点省一点。这里有个坑glBufferSubData在有些驱动上如果频繁调用小数据量更新性能不好。我的做法是攒够一批再更新而不是每个对象更新一次。因为我们是按批次提交的所以天然就是攒够一批更新一次这个问题自然规避了。批处理改完之后绘制调用从 312 次降到了 8 次左右因为还有几个不同状态的批次。帧率直接到了平均 59 帧最低 52 帧。基本满帧了。4.5 参数选择与计算过程批处理的缓冲区大小怎么定我算了一下最坏情况下屏幕上可能有 500 个精灵每个精灵 4 个顶点就是 2000 个顶点。每个顶点 20 字节顶点数据 40KB。索引每个精灵 6 个共 3000 个索引每个索引 2 字节用 unsigned short共 6KB。总共不到 50KB。这个量级对移动设备来说很小所以我把缓冲区大小定在 4096 个顶点和 8192 个索引留了一倍余量。双缓冲的实现是准备两套缓冲区对象用一个标志位交替使用。这样 GPU 在读上一帧的缓冲区时CPU 可以写另一套不会互相阻塞。图集大小选 2048x2048是因为 GLES2 规范要求最大纹理尺寸至少 2048选这个值能保证所有设备都支持。如果设备支持更大的可以动态查询GL_MAX_TEXTURE_SIZE再决定但为了简单固定 2048 最省事。5. 常见问题与排查技巧实录5.1 画面错乱与闪烁批处理改完之后最容易出现的问题是画面错乱精灵位置不对或者闪烁。我遇到过一次原因是顶点数据的写入顺序和索引的对应关系搞错了。批处理里每个精灵占 4 个顶点索引是相对于批次起始位置的偏移如果偏移算错就会画到别的地方去。排查方法先把批处理关掉退回逐个绘制确认逻辑没问题。然后打开批处理但每批只放一个精灵确认单个精灵的顶点和索引正确。再逐步增加每批的精灵数观察从第几个开始出错就能定位到偏移计算的问题。5.2 纹理边缘出现接缝图集化之后精灵边缘可能出现细线或者颜色渗漏。这是纹理采样时采到了相邻精灵的像素。解决办法是在图集里给每个精灵留 1 到 2 像素的 padding或者在着色器里把 UV 往内缩一点点。我用的方案是 padding 加 UV 内缩。padding 在打包图集时留UV 内缩在计算 UV 矩形时做缩的量是半个像素对应的 UV 值。这样双保险基本不会出现接缝。5.3 帧率不升反降有时候改完批处理帧率反而降了。这种情况通常是批次划分不合理批次太多每批的顶点太少导致绘制调用的开销没有摊薄。或者是排序开销太大超过了省下来的状态切换开销。排查方法统计每帧的批次数和每批的平均顶点数。如果批次数超过 20或者每批平均顶点数低于 100就说明批次划分有问题。检查排序键的设计看看是不是状态哈希太细导致相同状态的对象没有聚到一起。5.4 常见问题速查表问题现象可能原因排查方法解决方案画面错乱闪烁顶点索引偏移错误逐批减少精灵数定位检查索引计算确保相对偏移正确纹理边缘接缝采样越界放大图集查看边缘加 paddingUV 内缩半像素帧率不升反降批次过多或排序开销大统计批次数和顶点数调整排序键合并批次内存占用升高缓冲区过大或双缓冲查看缓冲区分配按实际需求调整缓冲区大小低端设备崩溃超出纹理尺寸限制查询 GL_MAX_TEXTURE_SIZE图集尺寸降到设备支持范围内5.5 几个容易忽略的细节第一个细节是glFlush和glFinish的使用。这两个调用会强制驱动执行命令破坏流水线能不用就不用。我见过有人在每帧结束调glFinish帧率直接腰斩。除非确实需要同步否则不要调。第二个细节是着色器的 uniform 位置。每次glGetUniformLocation都有开销应该在初始化时查一次把位置存起来。这个虽然是小开销但积少成多。第三个细节是顶点属性的启用和禁用。glEnableVertexAttribArray和glDisableVertexAttribArray也是有开销的如果属性数组在整个渲染过程中都启用就不要每批都禁用再启用。我的做法是在初始化时启用渲染结束后再禁用中间不动。第四个细节是混合模式的设置。glBlendFunc的调用开销比想象中大尤其是当驱动需要重新计算混合状态的时候。把相同混合模式的对象排在一起减少调用次数效果很明显。6. 优化效果验证与后续扩展方向6.1 最终效果对比改造完成后我在同一台设备上跑了同样的测试场景。平均帧率从 42 帧提升到 59 帧最低帧率从 28 帧提升到 52 帧。绘制调用从 312 次降到 8 次纹理绑定从 318 次降到 6 次uniform 上传从 900 多次降到 20 次以内。CPU 占用率也明显下降因为省掉了大量的矩阵计算和 GL 调用。在另一台更低端的设备上测试原来只能跑 25 帧左右优化后能稳定在 45 帧以上已经可以正常游玩了。这说明优化对低端设备的收益更大因为低端设备的 CPU 和 GPU 都更弱省下来的每一分开销都更宝贵。6.2 还能继续挖的地方批处理做完之后渲染路径上的大头基本都砍掉了。如果还想继续优化有几个方向可以挖。一个是把静态的、不变的对象预先合并成静态批次比如背景的草坪、固定的装饰物这些每帧都不变可以预先合并好每帧直接画连顶点数据都不用重新写。这个能进一步省 CPU 时间。另一个是考虑用纹理数组或者图集分页减少纹理切换。不过 GLES2 不支持纹理数组这个方向受限。还有一个是优化排序算法。如果对象数量继续增长排序可能成为新的瓶颈。可以考虑用计数排序或者桶排序把 O(n log n) 降到 O(n)。不过对于 PvZ 这个规模暂时没必要。6.3 我个人在实际操作中的体会做渲染优化这几年我最大的体会是先测量再优化不要凭感觉。我见过太多人一上来就改代码改完发现没效果甚至更慢。原因就是没搞清楚瓶颈在哪。GPU 调试工具、帧率统计、调用计数这些手段一定要用起来。第二个体会是优化是有层次的要按顺序来。先做低风险高收益的比如缓存和状态排序再做高风险的批处理。如果一上来就上批处理出了问题很难定位因为改动太大。第三个体会是移动端的优化和桌面端很不一样。移动 GPU 是 tile-based 的架构对带宽和状态切换更敏感对绘制调用的容忍度更低。在桌面上可能几百次绘制调用无所谓在移动端就是灾难。所以移动端的优化要更激进地合并和缓存。最后分享一个小技巧如果你不确定某个优化有没有效果可以做一个开关运行时切换然后对比帧率。这样比改来改去再回滚要高效得多。我在做批处理的时候就是这么干的先加开关确认有效果再默认打开出问题也能快速关掉排查。