LayaAir3的每一个分支版本都是一次较大的提升，在3.1彻底完善了引擎生态结构之后，本次的3.2会重点完善全平台发布相关的种种能力，例如，除原有的安卓与iOS系统外，还支持Windows系统、Linux系统、鸿蒙Next系统，以及主流的国产芯片适配等。另外就是性能的大幅提升以及一键发布安装包等易用性的大幅提升。当然，主旋律之外，3D的更新也是不可或缺的，下面将分别详细介绍。

01

升级为真正的全平台引擎

HTML5引擎通常被视为全平台引擎，因为HTML5标准的WEB基本上可以运行于各个系统平台。从这个角度来看，LayaAir之前的版本也可称为全平台引擎。但对于发布原生安装包的角度来说，LayaAir的历史版本只能发布安卓与iOS系统的安装包，并不是真正意义的全平台。

从LayaAir3.2开始，在历史版本的发布能力之上，我们会新增支持Windows系统、Linux系统、鸿蒙Next系统的发布。其中，Windows系统的exe安装包发布在3.2.0-beta.1版本内率先推出测试，Linux系统、鸿蒙Next系统还在紧密对接中，将会在3.2正式版之前推出。

一旦3.2正式版推出，开发者可以基于各个操作系统发布安装包、基于HTML5标准发布Web版本、以及发布到各个主流小游戏平台，使得LayaAir引擎升级为真正的全平台游戏引擎。

相对于非全平台的游戏引擎，LayaAir3引擎一套代码开发，全部平台发布运行的模式，可以大幅降低开发成本、提升市场推广机会。

与此同时，作为自有知识产权的国产引擎，LayaAir3对主流的国产芯片也在陆续对接之中，对信创硬件的支持将是3D引擎实现全国产化替代的关键，也是很多信创项目的刚需。

02

Native易用性大幅提升

对于从来没有打过包的开发者而言，Native打包是一个门槛很高的事情，很多游戏公司甚至设置了专门Native打包的工程师。我们在社区里，也发现了开发者因为安装Native打包环境等问题被卡住流程。

因此，3.2版本中，我们支持自动打包成为各平台的安装包（例如exe、apk、ipa），并且提供选项，由开发者自主选择对应平台的安装环境，然后自动安装好打包所需的环境，使得开发者不必再为安装什么样的环境才能顺利打包而发愁。

当然，对于资深的开发者，如果更习惯使用传统的开发环境来打安装包，我们也保留了发布为原生包工程的方案。例如安卓勾选导出Android Studio项目、iOS勾选导出Xcode项目即可发布为原生包工程，而不是直接打包。

另外，由于iOS系统的限制，常规测试流程非常繁琐，对于新手也是非常大的障碍。因此，我们会提供LayaAir引擎官方的运行器安装包，支持在安卓和iOS系统的真机环境中，直接使用安装包扫码IDE，在IDE里即时修改，真机扫码立即查看效果。不仅大幅降低了iOS中的测试成本，对于安卓真机测试，也可避免一次又一次的打包等待时间。提升了原生包测试的易用性。

在PC端，我们提供了PC模拟器。与移动端的运行器一样，可以在项目中即时修改，在PC模拟器上直接查看打包后的运行效果。

基于以上的优化，LayaAir Native打包与测试的易用性大幅提升，开发者的门槛大幅下降。开发与发布效率得以明显提升。

03

性能与效率大幅提升

无论何时，引擎的性能都是非常核心的指标，这将是项目发挥效果的天花板。本次版本，我们从Native安装包的运行性能、Spine动画的运行性能、3D粒子性能这几个方面对引擎性能进行了明显提升。

3.1

安装包运行性能提升

LayaAir3.2开始，我们优化了Native引擎的底层架构。引擎的渲染底层以及部分对性能消耗较大的核心模块，已下沉到Native C++层进行了实现。

经过此次调整，Native APP的运算性能得以明显提升。同样以7477个渲染节点的3D示例为例，安卓测试机型的性能提升了50%，iOS测试机型的性能提升了近100%。

3.2

Spine运行性能提升

对于Spine动画，很多开发者都认可LayaAir引擎内置版的性能。但内置版存在两个问题，一是没有及时与Spine官方的版本同步，二是功能被阉割了，只保留了基础功能。所以多数开发者选择了Spine官方库的引入，该方案基于Spine官方的JS运行库，将渲染接入到LayaAir，所以功能齐全。但带来的问题就是Spine官方运行库的性能远不如LayaAir引擎内置的骨骼动画。

3.2开始，为提升Spine动画使用者的体验，我们针对Spine的官方库做了私有的性能优化，大幅提升了Spine官方库的动画在LayaAir引擎中的运行性能。

我们首先采用了合并指令、GPU运算优化、缓存运算优化，这几种方式对CPU计算能力瓶颈进行提升。在一些CPU计算能力相对较差，但GPU相对较好的机型上，甚至可以得到几十倍的提升。这对CPU能力不强的机型，以及不支持JIT的iOS小游戏环境，是非常有价值的。

缓存优化由于会额外占用内存，属于牺牲内存提升性能的一种方案，引擎默认不开启，当开发者在Spine性能得不到满足的时候，内存消耗也不大的情况下，可以主动开启缓存优化。但是对于Spine使用量不是特别大的产品，也可以保持默认不开启，即便是不开启，相对于Spine官方库的性能也得到了明显的提升。

Spine动画最终运行性能的瓶颈主要存在两方面，一方面是计算性能的瓶颈，另一方面是渲染的瓶颈。例如屏蔽渲染的时候，可以支撑同屏8000个Spine接近满帧，一旦正常渲染，最多只能支持到同屏500个spine动画接近满帧，例如下图所示。

在上图的测试数据中，细心的开发者会发现，不同机型在GPU计算优化的幅度存在差异，这是由于不同机型的GPU能力的差异导致，GPU能力越强，采用GPU计算优化的效果越明显。在某些GPU能力弱的机型上，GPU计算优化的效果甚至还不如合并优化的性能，如果存在这种机型，开发者可以选择手动关闭默认开启的GPU计算优化功能。

尽管经过一系列的计算优化后，Spine性能已提升了数倍到几十倍不等，但我们仍然没有停下优化的脚步。当下正在对Spine动画的渲染部分进行极致优化，预计在3.2正式版推出前，Spine动画的整体性能会得到进一步的提升。

3.3

3D粒子编译效率提升

曾有开发者反馈3D粒子较多的时候导致卡顿。我们分析Demo后发现，shader的define数量较多，这导致了shader变体数量庞大，编译时间过长。

由于shader在持续编译的过程出现卡顿现象，这是不可避免的。所以，我们进行了一系列的优化工作，主要目标是减少shader的define数量，降低shader变体数量，以减少编译时间，避免出现明显的卡顿现象。

例如一个Demo的粒子材质球，在优化前有92种变体，编译时长为7.004秒。使用3.2优化后的版本，只剩下66种变体，总编译时长也降至1.474秒。

以上数据由于是累计值，因此在项目的实际使用过程中，材质球越多，得到的对比差距会越大。这对大量使用3D粒子的项目来说，大幅提升了用户体验。

04

正式支持WebGPU

LayaAir3.0开始接入WebGPU，直到此次的3.2版本，我们终于全面接入了WebGPU的图形API，这将是非常有意义的一个LayaAir引擎发展新里程。

WebGPU作为现代Web图形标准，具有支持CPU多线程、支持通用计算能力等WebGL所不具备的能力与众多优势。注定要替代WebGL图形标准，主流3D引擎均会陆续接入该标准的API。

从引擎的角度，相较于WebGL，WebGPU提供了更高的性能优化和更低级别的硬件控制，使游戏引擎能够充分利用现代硬件的图形处理能力，这会带来更加出色的图形渲染和计算性能，以及更多基于WebGL无法实现的引擎功能。

当前，尽管WebGPU并没有在所有的平台中支持，但全面的支持已成趋势，我们如今完成接入，是为了未来更加平滑过渡到WebGPU的时代。

如果大家想体验WebGPU的渲染能力，可以在PC端的Chrome浏览器地址栏里输入 chrome://flags 并回车，然后在搜索栏中输入WebGPU，将WebGPU Support的选项设置为Enabled，最后重启Chrome浏览器。

完成浏览器的设置后，再到IDE里将引擎的渲染切换为WebGPU即可。步骤为：项目设置 -> 运行 -> 引擎模块 ->  WebGPU(Beta)。

需要注意的是，启用WebGPU后，需要使用HTTPS协议访问，3.2版本已支持该项设置，我们点击顶部的倒三角图标，再点击启动https即可。

设置好环境后，我们对1473万个三角面的5184个PBR材质物体，在不做合并优化的情况下，基于WebGL和WebGPU进行性能测试和对比。

测试环境的浏览器采用Chrome 125.0，CPU为Intel(R) Core(TM) i7-8700，GPU为RTX3090。测试结果显示，同样是5184个DrawCall，1473万三角面，WebGPU的性能相对于WebGL提升了20-25%左右。随着后续WebGPU在接入完成后的进一步优化，应该还有性能提升的空间。

05

3D相关功能的新增

在3D方面，LayaAir3.2中有两个重要的更新，其一是新增了材质缩略图预览，使得开发者可以在IDE中通过缩略图快速识别和选择所需的材质，而无需逐一打开，节省了大量时间，并使得材质的管理更加直观和高效，进一步提升了材质功能的易用性。

另一个重要的更新是在引擎中新增了3D导航寻路相关的功能，并且在IDE中提供了6个3D导航寻路组件，方便开发者使用。

静态导航表面(Nav Mesh Surface)组件用于生成导航网格，导航网格是一种用于寻路和导航的数据结构，它描述了3D环境中角色可以行走的表面。例如，指定哪些区域是可行走的，并根据定义的可行走区域自动生成导航网格。

动态导航表面(Nav Mesh Modifier Surface)组件用于在运行时动态修改导航网格。例如，当需要在游戏运行时动态地向导航网格中添加或移除障碍物时，使用该组件在运行时创建一个区域，该区域会覆盖或修改现有的导航网格。

导航障碍物(Nav  Mesh Obstacles)组件用于表示障碍物的组件，当前实现了盒子和圆柱体形状的障碍物。通过在场景中放置障碍物对象，以及设置障碍物的类型与形状，影响导航网格的生成和寻路计算。

代理寻路(Nav Agent)组件是用于控制角色或物体等寻路对象(导航的代理)在导航网格上移动和寻路的组件。该组件是实现寻路对象在复杂环境中自主寻路和移动的关键。

导航区域链接(Nav Mesh Link)是用于连接两个不同导航网格表面的组件。它允许在导航网格之间创建链接，通过指定移动时的起点和终点，使得角色可以在这些链接上移动。这在游戏场景中非常有用，特别是当你有多个不连续的可行走区域时，例如平台、楼层等。

动态区域体积(Nav Mesh Modifier Volume)是用于在体积区域内修改导航网格属性的组件。例如，在场景中定义一个三维区域，开发者可以为该区域设置一个区域标记。例如标记该区域为不可行走时，那么代理在寻路时，则会绕开此区域。

以上这些导航组件功能的推出，进一步提升了开发效率和游戏体验，使得开发者无需从头编写复杂的路径规划算法，让角色能够智能地在复杂3D场景中进行路径选择和动态避障，适用于多种游戏类型。同时还降低了新手的开发门槛。

写在最后

为了早一些让开发者尝鲜LayaAir 3.2新特性，本次3.2.0-beta.1版本中，并没有把3.2规划的全部功能一次性开放出来，会在后续的其它beta版本中陆续推出，请大家及时关注引擎官网（LayaAir.com）下载的更新日志。

在3.2.0正式版推出前，我们还会持续保持3.1.x正式版的小版本更新，对于即将有上线需求的开发者，推荐使用正式版引擎与IDE。

参与测试版本体验的开发者欢迎添加微信账号（LayaAir_Engine）加入到3.2 beta版本测试反馈群，交流测试版本中遇到的问题，以及对未来3.3版本中的期待。

END