麒麟子

V1

2022/08/18阅读:52主题:默认主题

3.6 新特性详解 3/3:性能篇

和从前说再见

看完前面两篇文章,开发者们不淡定了,有很多朋友私信麒麟子说: “加了这么多东西,性能能行吗?”

能行,不仅没降,反而在某些方面有大幅提升!

因为“性能提升”也是 3.6 作为重要的 Cocos Creator 里程碑版本规划中需要完成的目标。

这篇文章我们就来看看 Cocos Creator 3.6 中关于性能方面改进。

Cocos Creator 3.x 自推出以来,一直就被开发者们催更性能优化。 主要集中在几个方面:

  • 原生性能
  • 粒子性能
  • 2D渲染性能

关注这几个问题的朋友们,是时候打开香槟,启动 Cocos Creator 3.6 ,和它们说再见了!

接下来,我们从实测结果数据,以及引擎为此所做的改动这两个层面,分别讲解 3.6 中带来的性能提升。

原生性能

测试数据

为了尽可能模拟复杂的执行环境,引擎组选择了静态场景+动画模型混合的测试用例。

从上图中可以明显的看到,同样的测试用例, v3.6 比 v3.5 高出了50%以上。

引擎原生化

在和引擎组交流后,得到的答复是:“方法比较简单,就是将原来处于TS层的场景管理、资源管理等模块,用C++重新实现了一遍”。

方法简单但并不表示工作量小,引擎组为此付出了一年多的努力。

但从结果上看,这一切努力都是值得的,自 Cocos Creator 3.6 版本开始, Cocos 引擎可以称得上 “双核引擎”了,即在原生平台为C++内核,在非原生平台为JS/TS内核。

这种做法在业内并不多见,因为它成本极高。需要使两套引擎核心保持对等架构,并且维持相同的渲染效果。

但也只有这样,才能更好地服务相应平台,在极端情况下为相应平台做最精细的优化。

V3.3 vs. V3.6

左图为 Cocos Creator 3.3 原生化状态,蓝色为C++部分,红色为TS部分,可以看出 v3.3 的状态为:

  • TS模块:SeneGraph、Data Driven、AssetManager、Assets
  • C++&TS模块:RenderScene
  • C++模块:RenderPipeline、GFX、FrameGraph

右图为 Cocos Creator 3.6 原生化状态,绿色为C++部分,蓝色为TS部分,可以看出 v3.6 的状态为:

  • TS模块:AssetManager
  • C++&TS模块:Assets、Data Driven
  • C++模块:SeneGraph、RenderScene、RenderPipeline、GFX、FrameGraph

从这个对比中可以看出,RenderScene 和 SceneGraph 模块的完全原生化,应该对此次的性能提升起到了主要作用。

从进展来看,目前 Assets、Data Driven 的原生化即将完成,AssetManager 也应该会在后面的版本中得到解决。 离完全原生化的目标实现不远了,相信届时 Cocos Creator 的原生端性能又会提升不少。

粒子性能

Created with Cocos Creator v3.6

上面的截图,来自于团队同事用 Cocos Creator 做的一个项目,里面的每一根蜡烛,地上的每一团火焰,都是由若干个粒子发射器组成的。 在 v3.5 中,这个场景跑起来特别吃力,只能关闭一些粒子特效。 但在 v3.6 版本中,场景特效全开的情况下,依然特别流畅。

开发者们也不只一次提到过,粒子系统的性能限制了美术的发挥空间,导致游戏效果受限,希望能够加入粒子合批,提升性能。

3D渲染中的合批有两种方案:

  • 网格合并(Merging Vertex Buffers)
  • 几何体实例化(GPU Instancing)

由于几何体实例化需要硬件和系统支持,在前几年的系统中,引擎会选择在支持的设备中采用几何体实体化方案,在不支持的设备中退回到网格合并方案,以确保最大的可用性。

但 DrawCall 导致的性能瓶颈本身就以 CPU 侧为主,而网格合并又是以增加 CPU 运算负担为代价的,用网格合并换 DrawCall 无异于 CPU 资源换 CPU 资源,在某些情况下可能适得其反。

随着硬件的增强和新版图形API普及率的提升,几何体实例化的覆盖率已接近100%。因此此次粒子系统的合并选择了几何体实例化作为合批方案。

注意:Cocos Creator 3.6 及以上版本的 CPU 粒子和 GPU 粒子均支持几何体实例化(GPU Instancing)方式合批。

与此同时,Mesh 粒子也支持合批了,对于粒子系统而言,不管是 Billboard 还是 Mesh,二者在合批处理上并无差别。

麒麟子用引擎组给的测试用例测试了一下, CPU粒子在545个的情况下,依然能够保持在30帧以上,如下所示:

想要亲自尝试的朋友,可以自行下载测试案例:https://github.com/cocos/cocos-benchmark ,从 lobby 场景进入。

2D渲染性能

Cocos Creator 3.x 的 2D 渲染性能一直备受关注,开发者最希望的就是有一天 3.x 的性能能够赶上 2.x 版本。

令人惊喜的是,在 7 月 22 日的社区公测版本中,就已经包含了原生平台 2D 渲染性能优化。如下图所示:

忍不住要摘抄一下:2D性能在原生平台各项性能测试已赶上2.x

从下图中我们可以看出,在低端设备(HUAWEI-荣耀v9 Android 、iPhone 6s iOS)和中端设备(XIAOMI8 Android、iPhone 11 iOS)上,都取得了满意的表现。

数据来源于Cocos引擎测试报告

费了好大的力气,麒麟子找到了负责这一次2D渲染优化升级的引擎工程师之一,鸭舌同学。了解到了一些2D性能提升的主要工作。

引擎原生化

受益于引擎原生化,许多计算由 TS 改为了 C++,仅从语言运算能力层面的就提升了不少性能。

当模块改为C++后,C++本身的语言特性,使引擎团队可以用更多的方法去优化性能。 这一部分又带来了不少提升。

内存优化

各位没看错,2D的内存使用量也优化了。之所以内存优化出现在性能优化这里,是因为内存优化也是受 C++ 语言特性而带来的。

在使用了一些字节对齐(Byte Alignment)和联合体(Union)之后,2D对象的内存使用量仅为原来的一半。

TS层优化

引擎原生化后,TS层变得更加简洁了,同时也带来了一次优化结构的机会。 在这个过程中,去除了一些冗余的运算,加入了惰性更新机制。当一个组件的某属性没有变化时,不会做运算。

管线优化

为了保持统一,减少故障率,3.x 版本中早期的 2D 对象渲染是共享的3D 对象渲染流程,但由于 3D 对象渲染流程的复杂度,无论从CPU开销,还是内存开销都比纯2D高出不少。

在做原生化的同时,也对这个问题做了优化,重新梳理了专门的 2D 管线,2D 对象与 3D 对象的渲染完全独立,确保了 2D 渲染以最小的开销进行,在CPU运算开消DrawCall内存使用量IO过高导致的耗电发烫等方面均有显著提升

总结

性能的提升是一个常态化工作,是每一个版本都会迭代增强的部分。

Cocos Creator 3.6 并不完美,如在包体、内存、加载速度等方面还有很大的提升空间,官方的性能测试也不能覆盖所有的项目情况,更多实际的数据还需要开发者自行验证并给予反馈。

不过,麒麟子相信,只要持续不断地优化,将来肯定会全方位超越 2.x,成为一个优秀的2D&3D一体化双核引擎。

不管是 原生性能粒子性能还是2D渲染性能,都是开发者在项目中经常遇到且无法绕过的坎,只有引擎将此完善,开发者才能将自己的产品做得更好。

在这个移动、便携、可穿戴设备日益精细化发展的年代,追求性能与效果的极致,成为了最矛盾却又最刚性的需求。

很高兴看到 Cocos Creator 始终在不遗余力地完善编辑器功能、提升开发效率,与此同时,在增强渲染特性、提升渲染效果的同时的依然保持了它双核引擎(Native与Web)、伸缩性架构(高性能、低功耗,易定制)的优势。

不管是“让游戏开发变得更简单”,还是“以技术驱动数字内容行业效率提升”。 在提升生产效率这个关键点上,Cocos 始终初心未改,砥砺前行。

写在最后

至此,关于 Cocos Creator 3.6 新特性的盘点就结束了。

如前文所说,做这个 3.6 版本特性盘点的初衷,是希望给没有时间去分析新特性的朋友们一个详细的解释,挖掘 3.6 中的重要特性、功能改进的价值并呈现到大家面前,以供项目选型和升级决策提供一个有根据的参考。

值得惊喜的是,通过这一次的盘点,麒麟子也收获不少。

在盘点的过程中,麒麟子认真学习并梳理了相关细节,全方位的了解了 3.6 的升级过程以及覆盖的要点,在以后和开发者的交流中会更高效、更准确。

在对细节进行梳理的过程中,也遇上过许多缺失的信息、问题,在与相关同事交流的过程中,更加熟悉了同事们的工作状态和方案考量因素,更能理解引擎的发展路线和下一步规划。 同时也特别感谢被我打扰过的同事们,每一位都是知无不言,有的人还手把手教会了我如何使用新特性。

期待下一个引擎版本,这样的文章,麒麟子还想继续写!

分类:

工具介绍

标签:

开源软件

作者介绍

麒麟子
V1

Cocos布道师