跳到主要内容
版本:2.3.0

提升游戏性能

建议先阅读官方文档的 UI 渲染批次合并指南 了解一些基础知识。

社区版对动态合图、文本渲染等功能进行了大量的改进,现在,你只需要确保以下几点就可以大幅提升游戏的性能。

使用动态合图

在之前,动态合图不支持复用图集的废弃区域,所以我们通常会关闭该特性,倾向于靠静态图集或者自动图集达到降低 Draw Call 的目的。

现在,社区版几乎重构了整个动态合图系统,实用性得到大幅提升:

  • 支持复用废弃区域
  • 自动参与多纹理渲染
  • 支持 Spine 参与动态合图

你只需要重新启用动态合图,并尽量让更多的纹理都参与合图,即可大幅降低 DrawCall 的数量。

我们还建议做以下调整:

放宽能参与合图的纹理尺寸限制

cc.dynamicAtlasManager.maxFrameSize = 1024;     // 推荐 512、1024 甚至 2048

你可以根据游戏运行过程中所使用的动态图集数量,来逐步放宽限制,取得一个平衡点。

优化动态图集的使用率

当游戏使用的动态图集数量太多,你可以控制某个组件或纹理不参与动态合图:

  • 调整纹理的 packable 属性
  • 调整组件的 allowDynamicAtlas 属性

通过让某些优化性价比较低的纹理不参与合图,例如:

  • 大尺寸、单独出现的纹理:比如背景图,尺寸较大使得占用图集的空间大,并且一个场景内可能只有单个节点会显示,不存在需要大量合批的情况。

来优化图集的使用。

及时释放无用资源

由于社区版支持了图集空间的复用,所以释放资源的同时也会将其占用的图集空间释放,以提供给其它纹理使用。

建议在不用的时候及时释放一些冷门资源,常用的资源则不进行释放,避免频繁释放后加载导致的性能消耗。

使用 Label 缓存模式

在之前,引擎提供的缓存模式都各有问题,无法在实际项目中使用:

  • Bitmap 模式:虽然能够参与动态合图,但无法复用废弃空间,随着游戏的运行,废弃字符的纹理占满图集后就失去了优化效果。

  • Char 模式:依然是无法复用的问题,仅有一张字符纹理,当纹理被填满后甚至无法渲染出文本。

现在,由于社区版使动态合图支持了复用,并且还重构了 Char 模式的实现,使得 你只需要合理运用这两种缓存模式即可完成对 Label 的优化工作。

首选 Char 缓存模式

我们建议 Label 默认使用 Char 缓存模式,相比 Bitmap 模式,Char 模式是按字符进行复用的,有着更高的性能优势。

备选 Bitmap 缓存模式

如果遇到以下场景,则不适合使用 Char 模式进行渲染:

  • 显示像 Emoji 这种字素簇的字符串,由于内部实现无法分割为单个字符,所以不能正常显示。
  • 超大字体,可能瞬间占满字符纹理。
  • 显示聊天消息、输入框、玩家名称这类不可控的内容,由于第一条限制,所以为了保证 Label 能正常显示,则不建议使用。

这时候就可以改用 Bitmap 模式进行渲染,依然能参与动态合图进行合批。

注意事项

  • 勿对 fontSize 属性进行动画或者缓动

无论是否使用缓存模式,也不建议频繁修改 fontSize 属性,这会导致每帧都需要重新生成文字纹理,造成大量的性能消耗,可以转为使用节点的 scale 来代替。

  • Char 缓存模式依旧不能在内部字符纹理填满时正常渲染

这是引擎原本的限制,我们未对其进行修复,原因是我们认为 8 张数量已经够多了,8 张都用完的情况大部分是没有合理搭配使用两种缓存模式。

启用 Spine 合批

Spine 组件现在不仅可以参与动态合图,还能与其他渲染组件进行合批。

只需启用组件上的 Enable Batch 属性即可。

提升 TiledMap 性能

一个 TiledMap 可能会有很多个 TiledLayer,如果开启了 TiledMap 的 Culling 特性,则需要每个 Layer 都单独计算 Culling 数据。

社区版新增了在满足一定条件的情况下可以复用 Culling 数据的特性,以减少 CPU 的性能消耗。

可前往 复用 Culling 数据 文档了解更多详情。

启用多线程支持

现在,以下引擎的部分增加了多线程支持:

  • 资源管线(下载与缓存部分)
  • 音频系统
  • XMLHttpRequest

启用后可以释放其对主线程的占用,减少卡顿现象。

除此之外,还支持自定义多线程扩展,大幅简化了将项目逻辑多线程化所需的步骤!

并且在微信小游戏平台下还有以下改进:

  • 默认启用网络接口和音频接口的高性能模式
  • 网络接口支持 HTTP/2、HTTP/3(QUIC) 协议

详情请阅读文档:多线程支持