运行性能优化指南

更新时间 2025-02-25 11:59:58

概述

运行性能与玩家体验

游戏运行性能直接影响玩家体验。玩家如频繁遇到卡顿，发烫，闪退，很快就会流失。优秀的运行性能是玩家留存、在线时长的重要保证。

• 游戏画面品质和运行性能是一个权衡。
• 游戏流畅度，响应速度和设备发热需要权衡。
• 要考虑不同设备，不同环境的运行兼容性。 ​ 运行性能需要关注的数据指标可以参考 小游戏性能评测标准。 理解小游戏的运行框架，对提升小游戏的运行性能有很大帮助。在此基础上，再不断了解，使用常见的游戏优化方案来提升性能。 ​

运行环境

TapTap 小游戏运行在Android iOS平台上。 运行环境的不同，必然导致相同的游戏内容，在不同平台下的运行性能表现不同，所以需要考虑小游戏在不同平台下的差异。

各平台脚本执行环境是各不相同的：

• 在 iOS 上，小游戏逻辑层的 javascript 代码运行在 JavaScriptCore 中；

• 在 Android 上，小游戏逻辑层的 javascript 代码运行在 V8 中；

• 运行性能： 默认iOS和Android都会开启JIT特性；

• 内存限制：小游戏在 Android 系统下使用独立进程，对内存相对宽松。但iOS下，对内存的限制要高很多（低档机需<1G）。

• 发热：

  • 启动阶段会进行webassembly的编译，CPU占用较高。编译完成后会降低。所以代码分包能够较好的减少编译阶段的时间。

• 渲染：当前 TapTap Unity 小游戏已经支持WebGL2.0，相当于OpenGLES3.0。未支持WebGPU。WebGL2.0渲染支持说明 ​

小游戏与 App 的性能差异

小游戏 VS App：本质上是虚拟机与原生系统的运行差异。

• CPU区别：通常而言，小游戏运行性能是 App 手游性能的1/3，开发者应该特别注意CPU侧的性能瓶颈。

  • JS 或 WASM，是以虚拟机的形式运行在类浏览器环境中，因此CPU算力会受限于虚拟机的执行效率。
  • Unity WebGL目前不支持多线程，导致部分模块比如AI、动画、渲染无法得到多线程的加速。

• GPU区别：小游戏是以 WebGL API 进行渲染，其中 WebGL1.0 相当于 OpenGLES2.0, WebGL2.0 相当于 OpenGLES3.0。

  • WebGL 在原生的渲染API进行封装存在少量负荷带来的开销，但基本的渲染能力与原生 App 接近。
  • 渲染特性如 GPU Instantcing、SRP Batche r需要 WebGL2.0。 （需要注意的是，当 App 手游使用了这些特性时，在小游戏未开启 WebGL2.0 时则会进一步拉大差距）

普通小游戏 VS Unity 小游戏：本质上是 JS 与 WASM 的性能差异。

• WASM是强类型语言，这将使得JIT优化能更准确预判运行期类型，因此相对于JS能更快达到JIT指令优化后的峰值。通常而言，WASM~=1.5 * JS, 即JS运行效率的150%以上。 ​

优化目标

由于小游戏的性能无法完全达到原生 App 的性能水平，不同的游戏对性能的要求也有很大差别。所以开发者需要根据自己的游戏内容，建立不同的最低机型要求和流畅度标准。 建议：

• 轻度休闲游戏应保证低档机型30fps以上，需特别注意机型兼容性(可使用小游戏云测获取兼容性报告)，以达到买量用户覆盖度。
• 中重度游戏应保证中高档机不限帧时达到40fps以上，实际运行可限帧30以保持长时间挂机运行的发热量。

详细的基准机型与性能要求可参考 小游戏性能评测标准