LayaAir 3.4.0-beta.1 来了，这是一次以性能为核心驱动力的系统级版本升级。
围绕"性能提升、动画能力扩展、渲染能力升级与开发易用性增强"四个关键维度，对引擎底层管线、动画系统、渲染架构以及 IDE 与调试工具进行了成体系的强化。
本次版本不以单点功能堆叠为目标，而是通过 WebGPU Compute、WebGPU系统性升级、引擎通用性能优化、动画系统能力扩展以及调试工具能力丰富等等，显著提升复杂场景下的运行稳定性与可维护性，使引擎更适配大型、重度项目与长期运营型项目的开发需求。
01
WebGPU的能力与性能提升
尽管 LayaAir 自 3.2 版本起已支持 WebGPU 图形 API，但在本版本中，我们对 WebGPU 渲染进行了系统性升级，完善了渲染架构，并进一步提升了引擎性能。同时，借助引擎提供的 WebGPU 能力，开发者可以利用 Compute Shader 等功能在项目中进行更灵活的渲染优化，从而实现更高效的渲染效果和更稳定的帧率。
1.1
支持Compute，新一代渲染管线
WebGPU Compute 是 WebGPU 提供的通用 GPU 计算能力，允许开发者在浏览器环境中通过计算着色器将高并行、计算密集型任务直接交由 GPU 执行，而不再局限于传统的"只为渲染服务"的图形管线。是把 Web 端引擎带入"现代图形架构"的关键一步。没有 Compute，WebGPU 只是"更快的 WebGL"，有了 Compute，它才是真正的新一代 Web 图形架构。
本次版本新增了 WebGPU Compute 能力，使得计算任务不再作为渲染流程之外的"附加步骤"，而是与渲染阶段共享 GPU 资源生命周期、执行顺序与同步机制，从根本上减少 CPU 介入与 GPU 状态切换成本。
基于这一能力，粒子仿真、骨骼烘焙、实例化裁剪、后处理等高频、可并行、计算密集型任务可迁移至 GPU 执行。相较传统 CPU 驱动模式，该方案能够显著降低主线程负载，并减少因计算峰值引发的帧率波动问题，使复杂场景下的性能表现更加稳定、可预测。
（基于WebGPU Compute的渲染效果）
在引擎层面，Compute Shader 本质上是一段运行在 GPU 上的并行计算程序，不依赖顶点、片元或光栅化流程，而是通过 StorageBuffer、StorageTexture 等可读写资源直接操作 GPU 内存。它以 workgroup 为调度单位，面向数据而非图形，特别适合数据量大、规则统一、并行度高的任务，例如 GPU 剔除、实例参数构建、粒子与动画更新、图像与体数据的通用计算等。
为了降低开发者的学习成本，引擎选择继续使用 GLSL 作为编写语言，并在内部完成到 WebGPU 所需 WGSL 的转换，但Compute Shader 的价值不只是"能跑 WGSL"，而是被完整纳入资源系统、编译链和绑定系统中：以 .computeshader 资源形式存在，沿用 Shader3D 结构，通过 GLSL 编写，并由引擎自动完成 GLSL → SPIR-V → WGSL 的转换；所有资源通过 uniformMaps 声明，由引擎自动生成 bind group 布局和绑定点，开发者无需手动管理 set / binding。
在使用层面，Compute Shader 的使用流程清晰而工程化：编写计算逻辑 → 声明 uniformMaps → 创建 ComputeShader → 准备对应顺序的 ShaderData → dispatch 执行。需要注意的是，uniformMaps 与 ShaderData 必须一一对应、顺序严格一致，这是最关键的契约。dispatch 的数量以 workgroup 为单位，需要结合 local_size 才能得到真实并行规模。
在平台支持层面，除了在 Web 平台的支持外，Compute Shader 在 Native 引擎中已率先实现了安卓平台支持，未来也将逐步覆盖更多发布平台。
最后，需要明确的是，Compute Shader 也并非万能，它不适合分支极端复杂、强顺序依赖或低并行度的计算。在健康的架构中，Compute Shader 应用于规模化、结构化的数据处理，而不是业务逻辑本身。只有明确这一边界，Compute 才会成为性能工具，而不是技术负担。
1.2
渲染升级，10万节点流畅运行
WebGPU的渲染架构升级与通用计算能够在统一的 GPU 资源与调度体系中运行，不仅充分释放了 WebGPU 在并行计算、资源管理与执行效率方面的能力，也显著提升了引擎在复杂场景下的整体通用性能表现。
在升级后的 WebGPU 架构下，引擎能够更高效地组织渲染指令与 GPU 资源，减少 CPU 介入与状态切换开销，使得在节点数量庞大、渲染压力较高的场景中，帧率与帧时间表现更加稳定、可预测。
为验证全新 WebGPU 渲染架构在实际项目中的性能表现，我们在同一硬件环境与尽可能一致的运行条件下，对 3.3 引擎 WebGL 与 3.4 引擎新架构 WebGPU 的性能进行了对比测试。
测试选用华为 Mate 70 Pro 设备，搭载麒麟 9020 SoC，系统版本为 HarmonyOS v6.0.0.108 SP6，小游戏服务版本号 v15.4.2.100。测试过程中关闭设备 USB 充电，并使用 HiSmartPerf 普通模式进行性能采样，以避免高性能模式对数据的干扰。
测试场景为节点数量超过 10 万的复杂场景，分别在 WebGL 与 WebGPU 模式下运行。测试结果如下图所示：
（WebGL模式的测试数据）
（WebGPU模式的测试数据）
从测试结果来看，WebGL 模式平均帧率约为 14.8 FPS，平均帧耗时约为 67.3 ms，整体帧时间较高且存在明显性能压力。相比之下，新架构 WebGPU 帧率与帧时间均保持在较为稳定的水平，平均帧率均约为 53.1 FPS，平均帧耗时约为 18.8 ms。
（完整的测试对比数据）
测试结果表明，在 10 万级节点规模的复杂场景中，全新 WebGPU 渲染架构能够显著降低单帧耗时，并有效减少性能波动。
02
引擎底层的通用性能优化
本次版本对引擎底层的通用性能优化方面，重点围绕合批体系与渲染流程展开。首先是重构并优化了 3D 合批机制，同时新增了自定义合批代理与自定义裁剪接口，使复杂场景下的性能调度更加灵活、稳定。
在渲染流程细节上，进一步优化了单个渲染元素的 preRender 处理，并精简了每个 drawCall 的渲染混合状态流程，提升了整体渲染效率。
2.1
引入BatchAgent提升性能
**BatchAgent（批处理代理）**是 3.4 版本引入的一套高度抽象、模块化的渲染合批优化体系。它通过在渲染系统与具体渲染节点之间引入代理层，将原本发生在"每一帧渲染阶段"的合批判断与标识计算，前移到节点生命周期阶段完成，从设计上减少了重复计算的发生频率，为性能优化提供了更稳定的基础。
与历史版本中基于 WebGLInstanceRenderBatch 的"渲染时动态合批"不同，新架构采用 接口 + Agent 实现分离 的方式，对渲染节点进行集中管理。节点在添加或属性变化时即完成 BatchMark 的计算与缓存，渲染阶段只需直接使用这些结果进行合批。这一改变使合批成本从"与帧率强相关"转变为"与节点变化相关"，是整体性能提升的核心原因。
这一架构改进在实际测试中得到了明确验证。测试基于 API 模板中的动态合批 InstanceBatch 示例 ，在相同场景、相同资源条件下，对比 3.3 与 3.4 的运行表现。在 IQOO Z3 移动设备上，帧率从约 20 FPS（51ms）提升至 46 FPS（22ms） ，性能提升约 130% ，CPU 压力显著下降；在 PC 集显平台（Intel HD 630）上，帧率由 50 FPS 提升至 60 FPS ，有效缓解了原本明显的 CPU 合批瓶颈；而在 小米 15 设备上，则稳定逼近 60 FPS 的硬件渲染上限，说明在算力充足的设备上，瓶颈已不再来自合批逻辑本身。
（3.3.7合批方案 PC 测试数据）
（3.4.0合批方案 PC 测试数据）
（完整的合批测试对比数据）
这些性能提升并非来自单一技巧，而是多项优化的叠加结果：BatchMark 的预计算与缓存避免了每帧重复判断；InstanceRenderElement 的对象复用减少了 GC 压力；裁剪与合批在同一 Agent 内完成，降低了数据遍历与状态切换成本。尤其在移动端 CPU 资源紧张、GC 敏感的环境下，这种"把工作从每帧挪走"的策略带来了非常直接的收益。
总体来看，3.4 的 BatchAgent 架构不仅在测试数据上验证了其有效性，更重要的是完成了一次合批体系的结构性升级。它将渲染性能从"靠硬件堆算力"转向"靠架构减少无效工作"，并为 WebGPU 平台下的 GPU Compute 裁剪、裁剪结果缓存、静态与动态物体分离等进一步优化，奠定了清晰而可扩展的基础。
2.2
自定义代理与裁剪
前文介绍的 BatchAgent（批处理代理） 是引擎内置的合批能力，用于在常规 3D 渲染流程中自动减少 drawCall。在此基础上，引擎进一步开放了自定义批处理代理与自定义裁剪能力，允许开发者针对特定对象类型或业务场景，参与批次管理与可见性裁剪过程，从而进一步减少无效渲染与渲染调用开销。
在架构设计上，系统通过 ISceneRenderManager 注册不同渲染类型对应的 IBatchModuleAgent ，将批次合并与裁剪逻辑从具体渲染管线中解耦。该机制为 WebGPU、WebGL、OpenGLES 等多种渲染后端提供了统一的接口规范，同时允许各后端根据自身特性实现最优的批次处理与裁剪策略。
不同渲染后端采用了差异化的批次标记结构：WebGPU 使用 OneBatchMark ，支持更丰富的裁剪信息与缓存机制，适合复杂批次管理；WebGL 使用 BatchMark，侧重实例化渲染的轻量级合批支持。批次分组会综合材质 ID、几何数据 ID、正反面设置、接收阴影标志、反射探针 ID、光照贴图索引、体积 GI ID 等多维条件，共同决定对象是否可以合并到同一批次。
IBatchModuleAgent 是整个系统的核心通用接口，定义了批次管理与裁剪流程中的关键操作，包括渲染节点的添加与移除、属性变更响应、裁剪信息设置，以及执行裁剪并输出 IModuleAgentResource（不透明 / 透明渲染队列）。系统同时配合动态缓冲区管理机制，根据场景复杂度自动扩展或收缩缓冲区规模，避免固定大小带来的限制，在保证性能的同时提高内存利用率。
在裁剪策略上，引擎采用 CPU 精确裁剪 + GPU Compute Shader 批量裁剪 的混合方案。GPU 裁剪主要面向大批量对象，负责 AABB、平面、距离与 Layer 等规则化裁剪；CPU 裁剪则用于非批次对象或包含特殊逻辑的节点，以保证裁剪结果的正确性与灵活性。在 WebGPU 模式下，该流程可完全由 Compute Shader 并行执行，并直接配合 Indirect Draw 输出渲染结果，避免 CPU 与 GPU 之间的频繁数据回传。系统还为相机裁剪、方向光阴影裁剪与聚光灯阴影裁剪分别维护独立缓存，以减少重复计算。
从功能层面来看，引擎默认启用相机视锥裁剪、方向光阴影裁剪与聚光灯阴影裁剪，并会根据材质、几何、阴影与光照 ID 自动完成批次分组。开发者在常规使用中无需手动参与合批或裁剪流程，系统会在渲染阶段自动生效。针对蒙皮网格等特殊渲染元素，引擎也提供了专门的批处理支持，例如 WebGPU 后端的 SimpleSkinRender 类型，以及用于存储骨骼动画参数的额外实例数据，满足蒙皮对象的批次需求。
当遇到更复杂或更具针对性的优化需求（如植被系统、粒子系统、大规模实例化对象，或需要自定义裁剪规则的节点）时，开发者可以通过实现 IBatchModuleAgent 接口并注册自定义代理，明确指定哪些对象可以参与合批、如何分组、在什么阶段参与裁剪，以及如何输出最终的渲染队列。配合 WebGPU 后端的并行计算优化、批次排序与状态变更追踪等机制，开发者可以在不侵入现有渲染管线的前提下，对特定对象类型进行更深度、更精细的性能优化。
2.3
不合批的性能提升
本次版本的通用优化，除了合批方面外，还重点针对单个渲染元素的 preRender 流程以及每个 drawCall 的混合状态流程进行了重构与精简。这些改动并不体现在功能层面，而是直接作用于渲染管线的决策与状态管理环节，为高 drawCall 场景下的性能稳定性打下了更扎实的基础。
在单个渲染元素的 preRender 流程中，引擎通过更精细的状态缓存机制，渲染元素在进入渲染阶段前，不再重复进行不必要的状态计算。几何状态、材质状态与渲染管线相关信息被有效缓存并进行对比，只有在真实发生变化时，才会触发后续更新。这种"变化驱动"的策略显著减少了重复判断和无效处理，使 preRender 阶段更加轻量、可控。
与此同时，引擎在着色器与管线相关流程中引入了更严格的按需更新策略。材质数据、宏定义或场景状态未发生变化时，渲染元素可以直接复用已有结果，避免重复的编译与配置操作。配合更精确的状态比对逻辑，渲染准备阶段从"每帧检查一切"，转变为"只为变化付出成本"，在复杂场景中尤为关键。
在 drawCall 层面，本次版本对混合状态的管理方式进行了集中优化。混合状态不再在每次 drawCall 中重复计算，而是通过统一的缓存机制进行管理与复用。相同参数组合对应的混合状态可以被快速命中，从而避免频繁的状态构建与切换。当混合状态确实发生变化时，引擎才会更新对应的渲染管线，最大限度地压缩了状态切换带来的额外开销。
这些优化并非停留在理论层面。在实际设备测试中，同一渲染场景、6000 个 Draw Call 的条件下，对比 3.4 引擎与 3.3 引擎的测试结果显示：
（小米15的测试对比数据）
（完整的测试对比数据）
对比 3.4 与 3.3 引擎版本的测试结果可以看到，新的渲染流程在准备阶段更加高效，状态切换更加稳定。整体渲染耗时得到明显改善，为复杂场景下的性能释放提供了更充足的空间。这一轮优化不仅提升了引擎自身的效率，也为开发者在高复杂度项目中构建更丰富的视觉效果提供了更可靠的底层支撑。
03
引擎功能的性能优化
基于开发者的反馈，2D 动态图集的功能终于在本次版本中支持了，Spine 的性能也再一次得到了全方位的提升。
3.1
Spine性能提升
Spine 动画是游戏项目中最常用的动画素材之一，同时也往往是性能压力的主要来源之一。因此，围绕 Spine 的性能优化，对整体项目性能具有非常重要的意义。
自 3.2 版本起，LayaAir 的 Spine 系统引入了快速渲染模式（useFastRender）。该模式开启后，会基于 GPU 运算优化、渲染指令合并以及缓存计算结果等策略，大幅降低运行时开销。在 GPU 性能较好的设备上，Spine 的整体性能甚至可以获得数十倍的提升。
不过，快速渲染模式并非没有代价。首先，缓存策略会额外占用一定内存，本质上是一种"以空间换时间"的方案；其次，快速渲染模式下的总骨骼数不得超过100，且当单个顶点受控骨骼数量超过 4 个时，可能会出现渲染异常；同时，该模式并不会对 drawCall 进行合并。因此，在部分场景下，快速渲染并不是唯一或最优选择。
从本次版本开始，当 useFastRender 为 false 时，引擎会自动启用 Spine 顶点合批机制，以减少 drawCall 数量。在该模式下，Spine 动画不会缓存生成后的网格数据，而是每一帧都根据骨骼变换实时计算顶点位置、UV、颜色等 mesh 信息并提交渲染。这种方式具备更高的灵活性，能够完整支持动态换装、IK 约束、网格变形等高级特性，但相应地也会带来更高的 CPU 计算开销。因此，开发者需要根据项目实际需求进行权衡，而不是单纯为了减少 drawCall 而关闭快速渲染模式。
需要特别说明的是，本次版本 Spine 性能的大幅提升，并不仅仅来自 useFastRender 关闭后的自动顶点合批 ，而是源于两项更核心的优化：动画缓存机制 与 Native 引擎中引入 Spine C++ 运行时。
在 Native 环境下，C++ 的运算效率天然高于 JavaScript，尤其是在 iOS 等不支持 JIT 的平台上，C++ 运行时相对于 JS 的优势更加明显。因此，Native 引擎中支持 Spine C++ 运行时，将为大量使用 Spine 动画的项目带来显著的性能收益。
动画缓存的控制开关为 enableCache，适用于 Web、小游戏以及 Native 环境。开启后，引擎会缓存已经计算完成的 mesh 顶点数据（位置、UV、颜色等），从而减少中间帧的重复计算，显著降低 CPU 开销。示例代码如下：
kotlin
const renderNode = sprite.addComponent(Spine2DRenderNode);renderNode.templet = templet;renderNode.play(6, true, true);renderNode.useFastRender = false; //开启动画缓存renderNode.enableCache = true;this.renderNodes.push(renderNode);为了验证动画缓存与 C++ 运行时的性能优势，我们基于 Windows 平台的 Native 安装包，使用 500 个 Spine 官方的 spineboy-pro 动画素材，在 Spine 4.2 运行时环境下进行测试。测试条件为关闭快速渲染模式（useFastRender = false），对比结果如下：
需要注意的是，动画缓存默认按 1 秒 / 30 帧 的粒度进行缓存，可能会带来一定的动画细节损失。同时，该方案同样是通过增加内存占用来减少 CPU 运算，动画数量和皮肤复杂度越高，内存开销也越大，因此不建议在所有场景中盲目开启。
此外，本次版本还对 Spine 相关的会员增值功能进行了整体优化，包括 Spine 动画烘焙 以及 跨精灵顶点的动态合批。其中，动态合批支持将多个 Spine 精灵的顶点数据合并至同一个顶点缓冲区，并可自动识别使用相同混合模式和 Shader 的精灵进行合并；同时还支持批次的动态重组，在每一帧中分析可合批对象，将连续可合批的 Spine 精灵统一提交渲染，并通过统一图集纹理，进一步提升合批成功率。
多种优化策略的协同作用，使得从 LayaAir 3.4 版本开始，Spine 动画在性能与稳定性上，都获得了全面而极致的提升。
3.2
2D动态合批图集
众所周知，图集（Atlas）是一种将多张小纹理整合为一张大纹理的资源优化技术，能够有效减少 drawCall、降低纹理切换次数、减少 I/O 请求，是 2D 产品中提升渲染性能与显存利用率的关键手段之一。
在 LayaAir 3.4.0 之前 ，引擎仅支持预设图集 方案。开发者需要通过图集制作工具，或在 IDE 中配置自动图集规则，在预览或发布阶段统一生成图集纹理与数据。这种方式在资源结构稳定的项目中表现良好，但在某些存在散图数量庞大、且不同用户加载资源集合不一致的项目中，也暴露出明显局限。
例如在角色数量众多的三国类游戏中，每位玩家实际拥有的角色组合各不相同，若仍采用预生成图集的方式，往往会造成图集冗余、显存浪费，甚至影响加载效率。这类场景迫切需要一种可在运行时，根据实际加载内容动态合并纹理的解决方案。
为此，LayaAir 3.4.0 正式引入动态图集能力，从根本上解决了这一痛点，在保证灵活性的同时，显著提升了渲染性能与资源利用率。
在引擎中，动态图集由 DynamicAtlasManager（动态图集管理器） 统一负责。初始化阶段，开发者可通过 DynamicAtlasConfig 对动态图集进行配置。默认配置下，大纹理尺寸为 1024×1024 ，最多支持 4 张大纹理 ，纹理单元尺寸为 16 像素 ，扩边尺寸为 1 像素 ，并使用 R8G8B8A8 格式。开发者可根据项目规模与目标平台灵活调整这些参数，以在显存占用与渲染性能之间取得最佳平衡。
同时，动态图集管理器还支持立即执行合并、自动扩展大纹理数量、纹理查重等高级特性，能够适配多种复杂使用场景。
纹理添加 是动态图集的核心能力之一。通过 addTexture 方法，开发者可以将 Texture 对象动态加入图集，并支持指定缩放系数及目标大纹理索引。系统会自动处理纹理重复添加的情况，若纹理已存在于图集中，将直接返回成功。
对于新纹理，管理器会调用底层 LargeTexManager 进行空间分配；当空间不足时，会返回失败并输出警告信息。添加成功后，引擎会生成对应的纹理信息记录，包括纹理 ID、URL、在大图集中的 UV 坐标以及大纹理索引，并自动关联所有使用该 Texture2D 的小纹理对象。
此外，addTextureByUrl 提供了基于 URL 的快捷接口，会从加载器中获取已加载的纹理后，自动完成后续合并流程。
为提升批量处理效率，动态图集管理器还提供了 addTextures 与 addTexturesByUrl 方法，可在游戏初始化或场景切换阶段一次性合并多张纹理，显著简化代码逻辑。
在纹理生命周期管理方面，动态图集同样支持动态移除 。通过 removeTexture 方法，开发者可以根据纹理 ID（并可指定大纹理索引）将纹理从图集中移除。移除操作会释放对应的图集空间，并从管理器的映射关系中清除记录。同时，系统会自动还原所有关联的 Texture 对象，将其 bitmap 与 UV 坐标恢复为原始状态，并清除动态图集标记。根据需要，还可选择是否触发纹理的 CHANGE 事件，以通知相关组件进行响应更新。removeTextureByUrl 则提供了基于 URL 的便捷移除接口。
关于 动态图集管理器的更多能力与完整使用示例，欢迎前往引擎官网文档查阅，这里不再展开。
04
动画能力的增强
在动画能力方面，本次版本实现了多项重要功能，重点包括：全新 IK 动画与骨骼约束组件、2D/3D 动画引导线，以及 3D Spine 动画支持等。
这些功能的加入，不仅大幅提升了动画表现的细腻程度与真实感，也为开发者在复杂交互控制及跨维度动画创作上提供了更高效的工具链支持。
4.1
新增IK动画
在传统的角色动画系统中，动画通常基于正向动力学（FK）运行。引擎从动画文件中读取骨骼数据，并按照骨骼层级自上而下依次计算关节的旋转与位移，最终驱动模型完成动作。这种方式对动画资源依赖较强，角色的运动轨迹在制作阶段就已经被固定下来，运行时只能进行有限的复用与混合。
本次版本中，引擎新增了 IK 链（ChainsIK）组件，正式引入反向动力学（IK）能力。通过 IK，开发者只需指定末端节点（如手、脚）的目标位置，引擎即可自动计算并驱动整条骨骼链的旋转与位移，使角色自然地到达目标姿态。这种动画结果由引擎实时生成，更强调"计算过程"，而非"播放过程"。
（指定立方体为手臂末端节点的效果）
IK 动画的加入，使角色动画在项目中的实用性得到显著提升。对于手部抓取、脚部落地、角色与场景交互等常见需求，开发者无需为不同目标位置反复制作动画资源，只需调整目标节点即可完成动画表现。这不仅降低了动画制作与维护成本，也让角色能够在运行时应对随机位置和动态环境，表现更加灵活自然。
4.2
新增骨骼约束
本次版本中，引擎新增了骨骼约束（BoneConstraints）组件。 该组件旨在为骨骼各轴向的旋转提供精确的控制边界，目前已完整支持铰链约束（Hinge）、欧拉约束（Euler）以及摆动-扭转约束（Swing-Twist）等类型，并允许开发者灵活配置约束空间与目标骨骼。
（欧拉约束可视化调节）
作为一种通用的骨骼运动限制机制，骨骼约束组件不仅能独立生效，更可与动画、物理及反向动力学（IK）系统深度协同。 它通过参数化的方式定义关节活动范围，确保骨骼在任何复杂运动下都能保持合理、可信的姿态。
在实际应用中，该组件的加入显著提升了角色动画的自然度：在普通动画播放或多层动画混合过程中，约束机制能自动校正因资源差异或过渡计算导致的关节脱臼、肢体超限等失真现象。而在反向动力学（IK）解算过程中，该组件则扮演了关键的"边界保护"角色，防止目标驱动下出现非正常的骨骼翻转，确保手臂抓取、头部注视等行为的姿态解算更加自然稳定。
除了生物形体模拟，骨骼约束组件在物理模拟与场景交互领域同样表现出色。 通过对铰链结构或复杂机械臂的运动控制，开发者可以轻松实现门窗开关、阀门拧动以及链条连接等符合真实物理特性的交互反馈。配合内置的事件通知机制，任何约束数据的变更都能实时同步至相关组件。通过这一套统一、可复用的约束规范，开发者能够以极低的维护成本，在各种复杂的游戏开发场景、虚拟现实（VR）手势交互以及高精度工业仿真中，构建出兼具稳定性与真实感的动态体验。
4.3
新增动画引导线****
本次版本在时间轴动画体系中引入了动画引导线功能，为复杂运动轨迹的编排带来了全新的工作方式。该功能支持在 2D 与 3D 空间内实时显示并追踪物体的运动路径，将原本抽象的位移数据转化为直观、可见的视觉参考。通过在编辑器中直接观测运动轨迹的平滑度与走向，开发者能够以极高的精度掌控物体的位移节奏，大幅消除了传统工作流中依靠反复运行验证、盲调关键帧参数带来的低效与不确定性。
（动画引导线编辑界面）
在技术应用层面，动画引导线为开发者提供了更具逻辑性的创作支持，但需要注意的是，该功能与基于位置的关键帧动画采用不同的驱动逻辑。当开发者启用动画引导线功能后，为了确保运动轨迹的唯一性与精确度，时间轴中原有的位置关键帧数据将被清除。由于两者在位移控制上存在互斥关系，开发者需根据具体需求，在自由的关键帧编辑与受引导线驱动的轨迹编排之间做出选择，以获得最适宜的运动表现。
这一功能的加入显著优化了复杂运动路径的编排体验，例如为子弹轨迹、投掷物抛物线或摄像机导轨设计精准的空间曲线，确保运动过程平滑自然。在 2D 领域，它同样适用于设计灵动的 UI 交互特效与粒子流向，增强视觉层面的灵动感。而在 3D 场景开发中，通过引导线对 NPC 巡航或场景道具位移的实时校正，开发者可以快速排查运动轨迹中的偏差与生硬感，确保在剧情动画或即时演算中实现极具电影感的空间调度。
4.4
新增3D Spine动画
在本次版本中，LayaAir 引擎新增了 Spine3DRenderer 组件，补齐了 Spine 动画在 3D 场景中的原生渲染能力，使基于 2D Spine 数据的角色与特效能够真正融入完整的 3D 世界。这一组件面向 3D 渲染管线设计，与 Sprite3D 深度协同，为 3D 游戏与应用提供了更加灵活、统一的角色动画解决方案。
Spine3DRenderer 的核心价值在于打通了 Spine 动画与 3D 空间之间的边界。开发者无需改变既有的 Spine 制作流程，即可将动画直接放置在三维坐标系中，并参与 3D 场景中的位置、旋转与缩放计算。动画不再只是"贴在屏幕上的 2D 表现"，而是作为标准的 3D 渲染对象，与模型、粒子、灯光等其他 3D 元素共享一致的渲染流程与生命周期。
（添加Spine资源到3D场景）
在渲染表现上，Spine3DRenderer 提供了对 3D 场景高度友好的能力支持。其中，Billboard 渲染模式允许 Spine 动画在三维空间中始终朝向相机，在保证空间定位准确性的同时，显著提升角色与特效的可读性与视觉表现力。这一特性非常适合用于 3D 场景中的角色展示、交互式 NPC、动态提示或特效表现，使 Spine 动画在 3D 环境中既自然又高效。
在系统设计层面，Spine3DRenderer 被完整纳入 3D 渲染管线，与引擎现有的渲染状态管理、批处理策略及性能优化机制保持一致。动画的更新、渲染与状态切换都遵循 3D 渲染流程进行处理，从而避免了 2D 与 3D 混用时常见的状态割裂问题。这种一致性不仅提升了运行效率，也让 Spine 动画在 3D 项目中的使用方式更加直观、可控。
在功能层面，Spine3DRenderer 延续了 Spine 动画成熟的核心能力，包括完整的动画播放控制、皮肤系统、事件回调机制以及模板化资源管理。开发者可以像在 2D 环境中一样控制动画的播放、暂停、循环与时间进度，并复用 SpineTemplet 模板实现资源共享。在此基础上，Spine3DRenderer 针对 3D 场景提供了更加精简而高效的渲染实现，用于在效果与性能之间取得平衡。
作为对比，Spine2DRenderNode 依然是 2D 场景中成熟稳定的 Spine 动画解决方案，主要服务于 2D 坐标体系与平面渲染流程，并在骨骼映射与外部皮肤管理等方面提供了更偏向 2D 使用习惯的能力。Spine3DRenderer 并非对其进行替代，而是面向 3D 场景提供了一条全新的技术路径，使 Spine 动画能够在 2D 与 3D 项目中各司其职、互不妥协。
通过引入 Spine3DRenderer，LayaAir 引擎在 Spine 动画支持层面实现了从 2D 到 3D 的完整覆盖。开发者可以在保持既有动画资产与制作流程不变的前提下，将 Spine 动画自然地扩展到 3D 场景中，构建更加立体、统一且高性能的角色与动画表现体系。这一能力的加入，为 3D 项目的角色表现与交互设计提供了更加广阔的发挥空间。
4.5
新增轻量化2D动画组件
在本次版本中，我们新增了 AnimatorClip2D 组件，用于简化轻量级 2D 动效的制作与控制流程。
在以往的开发模式中，2D 时间轴动画通常需要依赖动画状态机进行管理，这在复杂动画逻辑下十分必要，但对于只需要使用时间轴动画、且不存在状态切换需求的应用场景而言，完整的状态机流程往往会带来额外的资源与维护成本。而 AnimatorClip2D 的核心设计理念，是将动画播放逻辑与状态管理进行解耦。对于独立的动画资源，开发者无需创建额外的控制器，即可完成动画的创建与播放。
在工作流层面，自本次版本起，创建 2D 动画时，开发者可以根据实际需求选择创建动画状态机或直接创建动画。默认仍保持原有的制作与使用流程，创建并生成动画状态机文件与相应组件，适用于存在多动画状态切换的场景。当先创建了AnimatorClip2D 组件时，则会直接创建对应的 mc 动画文件，并将该文件自动绑定 AnimatorClip2D 组件，以 Clip 作为最小驱动单元进行管理。
（2D动画片段组件可直接播放）
从性能与资源使用角度来看，AnimatorClip2D 采用轻量化的单 Clip 驱动模型，减少了状态机中大量状态节点与过渡条件的常驻开销，更适合高密度 UI 动画或大规模简单动效的使用场景。在保证动画表现力的同时，为项目提供了一种更加高效、易用的 2D 动画解决方案。
05
IDE与安装包能力提升
除了引擎重磅升级外，本次版本中 IDE 也深度满足了开发者的诉求。
开发者现在可以在 Linux 环境下使用 LayaAir3-IDE 进行开发了，极大地扩展了工作环境的选择。同时，IDE 新增了集成 Spector.js 截帧工具的帧调试器，以及移动端 APP 预览器。这些工具的加入进一步优化了从开发到真机调试的工作流，在提升调试效率的同时，也大幅降低了项目的开发成本。
5.1
新增Linux环境IDE
本次版本中，LayaAir3-IDE 正式实现了对 Linux 环境的原生支持，打破了操作系统平台的限制。 对于习惯在 Linux 体系下工作的开发者而言，这不仅是工具可用性的扩展，更是开发流程一致性与效率的显著提升。开发者无需再依赖虚拟机或远程桌面等间接方案，即可在熟悉的桌面环境中直接进行项目构建。
在工程实践中，这一更新使 LayaAir 迈向了更加开放和专业化的方向。 无论是需要与 Linux 自动化构建、持续集成（CI/CD）系统深度集成的团队，还是在教育、科研等偏向 Linux 生态的领域，都能获得无缝的部署体验。开发者可以根据项目需求，在 Windows、macOS 与 Linux 之间自由切换，而无需在功能完整性与开发体验间做出妥协。这一进化，使 LayaAir 在专业开发与企业级应用领域具备了更强的适应性与长期商业价值。
Linux 支持的另一核心价值，还体现在对国产信创体系与自主可控技术路线的适配上。 在政企及行业应用项目中，Linux 往往是标准或优先选择的操作环境，开发工具的原生支持直接决定了项目的落地效率与合规性。LayaAir3-IDE 能够更自然地融入国产软硬件生态，满足对开发环境可控性与长期可维护性的严苛要求，为信创项目提供稳定且完整的工具链支撑。
5.2
新增帧调试器
本次版本的 IDE 中新增了帧调试器面板，并在面板中集成了 Spector.JS。以往，开发者在面对复杂渲染问题时，往往只能依赖经验与间接数据进行判断，而帧调试器的出现，使每一帧的 GPU 渲染过程都可以被完整捕获与还原，让渲染不再是"黑盒"。无论是定位 drawCall 激增的原因，还是排查材质、状态切换导致的异常渲染问题，都可以在 IDE 内直观完成，大幅提升调试效率与问题定位的准确性。
帧调试器主要适用于性能调优、复杂场景分析以及渲染异常排查等场景。当项目中出现帧率波动、渲染顺序异常、透明混合错误或资源使用不合理等问题时，开发者可以直接从单帧的渲染执行链路入手，逐步还原 GPU 的真实工作过程，从而做出有针对性的优化决策。
打开帧调试器面板后，整体界面分为两个核心区域。顶部为功能区，主要用于控制帧捕获行为。功能区左侧提供相机按钮，用于触发帧数据的捕获操作；右侧则是捕获选项设置，可选择低分辨率截图、高分辨率截图或不生成截图，以平衡调试精度与性能开销。需要注意的是，帧捕获仅在 IDE 的场景处于实际运行状态时才可用。
（帧调试器面板界面）
功能区下方的主要面板区域，即为 Spector.JS 的核心显示界面，也是帧调试的实际工作区域。当点击相机按钮并成功捕获帧数据后，Spector.JS 会完整记录该帧中 GPU 的所有渲染调用，并以可视化方式呈现出来。开发者可以沿着这一帧的执行顺序，逐条分析渲染过程中的关键步骤。
在 Spector.JS 中，Commands 与 Captures 是最常被关注的两个入口。Captures 用于管理已捕获的帧数据，每一次点击相机按钮，都会生成一次新的帧捕获记录，方便开发者在不同时间点或不同场景状态下进行对比分析。Commands 则展示了该帧中所有渲染指令的执行序列，包括每一次 drawCall、状态切换以及资源绑定操作。通过 Commands，开发者可以清楚地看到哪些渲染操作占据了主要开销，以及是否存在不必要的重复调用。
Information 区域则提供了更偏向全局与上下文的信息，用于帮助开发者理解当前帧所处的渲染环境。其中，Init State 描述的是帧开始时 GPU 的初始状态，包括已绑定的管线、缓冲区和纹理等信息；End State 则展示帧结束时的状态结果。通过对比 Init State 与 End State，开发者可以快速判断某些状态是否被正确恢复，或者是否存在跨帧污染的问题，这在排查渲染异常时尤为关键。
帧调试器的推出会让渲染调试从"猜测与试错"，进化为"可视化与可验证"。开发者不再需要脱离 IDE 借助外部工具，而是可以在熟悉的开发环境中，直接洞察 GPU 每一帧的真实执行细节。这一能力将为高性能项目和复杂渲染场景提供坚实的技术支撑，也让渲染优化真正变得可控、可分析、可复现。
5.3
新增移动端APP预览器
本次版本推出的移动端 APP 预览器，彻底解决了移动端开发、尤其是 iOS 平台下真机调试极度繁琐的核心痛点。
长期以来，iOS 系统的封闭性使得开发者在真机测试时面临重重阻碍：即便只是细微的逻辑调整，也往往需要经过证书配置、编译打包、甚至等待 App Store Connect 审核或通过 TestFlight 分发等冗长流程。
移动端 APP 预览器的出现，让开发者只需扫描 IDE 二维码，即可绕过复杂的打包环节，将项目瞬间同步至 Android 或 iOS 设备运行，实现了从代码修改到真机触达的秒级响应。
对于 iOS 开发者而言，该工具的价值在于填补了"所见即所得"的真机测试空白。 由于模拟器无法完全还原 iOS 系统的底层渲染特性、高刷屏表现、多点触控反馈以及特有的安全区域（Safe Area）适配，许多关键问题只有在真机上才会暴露。预览器提供了一个稳定、高度仿真的运行环境，使开发者能够第一时间验证 UI 布局与交互手感的真实表现。这种极速反馈能力，不仅大幅提升了调试效率，更确保了项目在 iOS 环境下的表现力与性能能够得到精准把控。
为确保在 iOS 设备上顺利运行，开发者需了解企业级应用的信任流程。 由于该预览器是以企业级应用形式直接提供安装，不经过 App Store 渠道，因此在首次启动前需要手动建立信任。开发者在安装完成后，需进入 iOS 系统的"设置"，依次选择"通用"与"设备管理"（或"VPN 与设备管理"），在"企业级应用"列表中找到对应的开发者证书，并点击"信任"。完成此操作后，即可在 iOS 设备上解锁高效、便捷的实时预览体验。
06
即将推出的重要能力
虽然前文展示了诸多重磅更新，但仍有几项核心能力未能赶在本次首秀中完整呈现。好在它们已进入最后的冲刺阶段，离正式见面仅一步之遥。后续的 Beta 版本将开启'连载模式'，持续为大家解锁这些关键功能。
6.1
场景视图的运行时编辑
场景视图的运行时编辑能力是 LayaAir 3.4.0 后续 Beta 版本即将推出的重要功能，它的核心作 用是即使开发者在项目预览运行状态下，依然可以在场景视图中直接点选节点，并对其位置、旋转、缩放等变换属性进行实时操作，所有调整都会即时作用于当前运行中的逻辑系统、物理计算以及渲染结果。这使得场景视图从"静态编辑工具"升级为"参与运行态的调试窗口"。
这一能力的核心价值，在于显著缩短了从"发现问题"到"验证结果"的反馈链路。以往在运行态暴露的问题，往往需要停止运行、修改参数、重新启动场景才能验证效果，而运行时编辑允许开发者在真实执行环境中直接修正节点状态，并立刻观察行为变化，从而大幅提升调试效率，尤其在复杂场景与多系统联动的情况下优势更加明显。
6.2
2D任意位置插入3D渲染
在追求极致视觉表现的开发过程中，如何在高频交互的 2D 场景中低成本地嵌入 3D 渲染元素，一直是困扰开发者的技术挑战。传统的 RenderTexture 中转方案虽然通用，但往往伴随着显存占用高、渲染链路长以及交互适配复杂等痛点。为了彻底打破这一瓶颈，我们即将在后续版本中推出基于底层架构的一种创新方案。
新方案采用单一开关驱动的极简模式，通过统一的配置方式，在不同渲染维度之间切换节点的运行行为。开发者无需关心底层差异，即可在 2D 与 3D 表现形态之间进行快速切换，从而在同一套节点体系中灵活承载不同类型的渲染需求。
在 3D 表现模式下，节点不仅能够承载标准的 3D 渲染能力，也支持组织完整的 3D 子节点结构，并在整体流程中保证类型与结构的正确性；而在 2D 表现模式下，其行为又能够自然回归到现有的 2D 体系之中，保持与既有 Sprite 工作流的高度一致。这种设计将跨维度带来的复杂性收敛在统一接口之下，显著降低了混合渲染场景中的使用与维护成本。
虽然这一重磅功能仍需细节打磨，但它已在我们的 Beta 计划中整装待发，将在后续更新中上线，助力您的产品实现更具竞争力的视觉跨越。
6.3
Spine能力持续增强
在 3.4.0-beta.1 版本中，我们率先完成了 Spine 4.2 C++ 运行时库的集成。这一更新旨在确保开发者能第一时间在生产环境中体验到原生底层驱动带来的极致加速与稳定性。
但这仅仅是系列升级的起点。在接下来的 Beta 版迭代中，我们将采取"滚动更新"的策略，陆续补全对其他主流 Spine 版本 C++ 运行时库的支持。与此同时，备受期待的 Spine WASM 版本也已进入最后的发布序列，将随后续版本陆续面世。
我们致力于通过这种高频的增量迭代，逐步构建起覆盖全场景的动画加速方案，敬请期待。
6.4
3D物理的车轮组件
组件
我们对底层物理引擎的赋能也并未止步。在即将到来的 Beta 版更新中，3D 车轮物理组件也将正式与大家见面。
不同于传统的刚体碰撞，Wheel Collider 是专为车辆模拟设计的物理组件。它内置了高度优化的悬挂系统（Suspension） 、轮胎摩擦力模型（Friction Model）以及刹车力矩控制逻辑。开发者只需将其挂载到车轮节点上，通过简单的参数调节，即可模拟出赛车在高速过弯时的侧滑感、越野车在崎岖地形下的悬挂起伏，甚至是不同地面材质对轮胎抓地力的细腻影响。
车轮物理组件仍在进行最后的场景压测与易用性优化，无论你是想打造极速竞技的赛车游戏，还是追求重型载具的真实质感，这一组件都将成为你的强大助力。动力全开，敬请期待！
07
写在最后
性能提升并非单纯追求更高帧率，而是通过降低系统负载与运行波动，为动画表现、视觉效果与玩法设计提供稳定且可控的性能空间，从而提升整体体验与开发效率。
LayaAir 3.4.0-beta.1 的发布，标志着引擎正式进入"架构驱动性能"的新阶段。通过深度挖掘 WebGPU Compute 能力和彻底重构 BatchAgent 渲染体系，我们将复杂场景的运行效率推向新的高度。这不仅是一次底层管线的"减负"，更是面向大型、重度及长期运营项目的系统级升级，使开发者能够轻松应对日益增长的算力需求与复杂业务挑战。
在后续版本中，Native 引擎将持续优化性能与降低开销，目标是在复杂场景与实际项目中，尤其是 APP 端，也能达到顶级 C++ 游戏引擎的表现。
我们在追求极致性能的同时，也始终致力于构建更加人性化、专业化的开发生态。从多端覆盖的 Linux IDE 到直观的帧调试器，从 2D/3D 渲染边界的消除到物理车轮组件的引入，每一项改进都旨在缩短从创意到实现的距离。LayaAir 引擎将助力每一位开发者在更稳定的基石上，创造出更具竞争力的游戏产品。
END
