帧同步在小游戏实践中的那些坑（三）性能篇

前文介绍了数据一致性、体验优化等方面。由于帧同步将所有的运算都放在客户端，而且所有游戏对象都需要参与运算、不能省略，因此对游戏进行性能优化也非常必要。本文将着重介绍H5游戏的性能优化的一些方法。

三，性能优化

游戏在运行过程中，最主要的资源消耗就是CPU、GPU、内存三部分。比如CPU有太多的渲染状态切换、逻辑更新太复杂，GPU的Draw Call和Over Draw太高，内存存在太多纹理、场景对象等。而这一切都会产生功耗。手机性能优化的核心就是，如何以最少的资源消耗，获得最好的用户体验。

1.GPU优化

讲GPU优化前，首先要介绍一下渲染管线。CPU首先要决定渲染哪些对象、坐标是多少、加载什么纹理、哪些需要被裁剪，然后设置渲染状态，发送纹理数据。紧接着调用DrawCall。GPU则通过顶点着色器、光栅化、片段着色器等流程将其渲染出来。

GPU优化首当其冲是要进行合批、降Draw Call。原因是，GPU的渲染是并行的，它的工作方式决定了：少次多量的渲染指令、比多次少量的渲染指令，利用率高的多。常见的合批方式有：

• 动态合图。采用引擎自带的动态合图，能最快速的达到合图效果。
• 静态合图。开发者自行进行的合图方式，需要开发者对于图集和渲染顺序的把控更为严格，当然效果也更好。
• bmfont。英文字母、数字、标点符号等，采用位图bmfont，能达到合图的效果。
• 文本缓存。系统自定义的文本不能参与合图。但对于不怎么改变的文本，可以使用文本缓存的方式进行合图。

此外，GPU的优化方式还有：优化自定义的shader，降低OverDraw（即像素点被重复绘制的比率）；进行脏矩形优化（将屏幕分割成若干矩形，只渲染有变化的矩形区域）；显示裁剪等。

举个我们游戏的栗子。不优化前，占用90+ Draw Call；采用动态合图降到30+ Draw Call；再使用静态合图、bmfont等、降到10+ Draw Call。

2.CPU优化

CPU的优化方式有：

• 减少渲染状态切换。因为在调用Draw Call前CPU首先要进行渲染状态的设置，如果状态产生了切换，就需要重新设置，于是不可避免的会打断合批。因此尽量将渲染状态相同的放在一起渲染。渲染状态包括纹理状态改变、材质、混合模式改变等。
• 差异化刷新率。比如降低视野外的物体的刷新率，而战斗场景和UI界面刷新率也可以不同。
• 分帧执行。比如需要实例化大量node，或播放很多特效。就可以分到多帧去执行，避免爆点卡顿。
• 事件机制。谨慎对待每帧都执行的update，将轮询方式改成事件触发方式。
• 复用运算。比如有一个群体寻路的功能，就可以复用第一个人的寻路路径。控制粒子数量。
• 注意控制粒子数量，减少计算量。可根据高中低档机分别进行控制。

举个游戏的CPU优化对比图。优化后CPU降了2个百分点：

3.内存优化

内存优化的方式有：

• 使用对象池。频繁创建、销毁对象，非常消耗资源。比如游戏中的子弹。使用对象池则能减少GC，降低内存碎片。
• 纹理压缩。CPU和GPU读取的纹理格式不同。PNG和JPG需要CPU解码后传给GPU。因此在内存中存在源文件数据、解码数据两份，内存占用较高。可采用纹理压缩，直接使用PVR、ETC、ASTC等GPU能直接读取的格式。但也有缺点：一是各平台对这些格式的支持程度不同，二是是图片纹理的质量可能受到影响。
• 音频优化。每秒音频文件的数据量 = 声道数 * 采样率 * 每个采样占用的bit数。经测试，5个2M的MP3音乐，解码后的数据量可能达到100MB。因此如果内存占用过大，可酌情进行优化，比如双声道改单声道，降低采样率等。此外，较大的背景音乐使用Dom Audio而非Web Audio进行播放，因为Web Audio要完全解码后才播放、占用内存较大，而Dom Audio可以边解码边播放。
• 资源释放。游戏场景切换时，静态资源设置自动释放，动态加载的资源则需要手动进行释放。
• 逻辑优化。设置分级Log，避免频繁创建大array，避免大量匿名函数等。

举个游戏的内存优化对比图，优化后内存降了60、70MB：

链接：

帧同步在小游戏实践中的那些坑（一）数据篇：
https://blog.csdn.net/weixin_42109916/article/details/109307299
帧同步在小游戏实践中的那些坑（二）体验篇：
https://blog.csdn.net/weixin_42109916/article/details/109310916
帧同步在小游戏实践中的那些坑（三）性能篇：
https://blog.csdn.net/weixin_42109916/article/details/109311921