《诛仙手游》小游戏：重度游戏在小游戏平台下的探索与实践

在 2025 年 5 月 24 日的 Unity User Group 北京站活动中，完美世界《诛仙手游》客户端负责人刘彦麟带来分享《重度游戏在小游戏平台下的探索与实践》。本文为演讲全文实录，点击阅读原文，可下载演讲 PPT 资料。演讲视频可通过下方链接地址观看。

https://www.bilibili.com/video/BV1rzj9zVEGd/?spm_id_from=333.788.videopod.sections&vd_source=6ad5666ecbc7fe0e80d963da7e237d92

我来自完美世界《诛仙手游》项目组。本次分享的内容聚焦于完美世界小游戏开发的经验，特别是小游戏下 WASM 和堆内存的优化方案，以及团结引擎对于小游戏的技术支持。

我们的小游戏移植工作启动于 2023 年中旬。然而，早在几年前，尝试小游戏的想法就已经萌生，并且进行过技术尝试。这其中包括对 Unity 和其他 H5 引擎的探索，但由于未能达到预期的综合目标，这些尝试最终未能继续推进。

随着 2022 年和 2023 年小游戏市场快速发展，以及大量“爆款”涌现，其中不乏 MMO（大型多人在线）、SLG 等中重度游戏也表现出色。无论从产品、运营，还是从技术角度来看，都促使我们决定再次尝试小游戏平台。

经过约半年的调研和分析，发现无论是市场前景还是技术承载能力来看，都存在机会。因此，我们在 2023 年 6 月正式启动小游戏的项目。经过约半年时间的移植工作和产品调优，项目从 2024 年的 1 月开始对外进行多轮 CCB 测试，今年 1 月，在微信小游戏平台开启正式 OB。目前，开发团队也正在进行抖音平台的性能调优，后续还会发行到更多小游戏平台。

MMO 类游戏因其固有的特性，即使在硬件资源丰富的端游或手游平台上，如果技术方案欠妥，亦可能产生相当大的性能问题。这因为此类游戏需要更大内存，更大的计算承压（包括 CPU 与 GPU），且部分功能需要多线程支持，而这些问题在小游戏平台上将进一步放大。这其中，内存和 CPU 是相对关键的要素，亦是攻克小游戏平台性能瓶颈的关键点。

在小游戏平台上，iOS 设备的内存普遍限制在 1.4G。然而，在手游平台上，1.4G 仅是部分低端机型的内存阈值，且此类机型在 APP 平台上的占比极小。此外，小游戏平台的 CPU 性能大约仅为手游的 1/3，并且不支持多线程，这使得小游戏平台对密集性运算更为敏感。然而，重度游戏恰恰需要大量计算，以及运行时的内存支持。同时，Unity 中的许多功能也依赖多线程支持，例如动画、蒙皮、粒子系统和物理系统。一些功能甚至会借助 Job System 来加速计算。然而，在小游戏平台上，这些功能都会转为主线程上的线性计算，不仅无法利用多线程优势，还会抢占主线程资源，进一步加重运算压力。

小游戏内存主要分为几个方面，其中影响最大是 UnityHeap、WASM 以及 GPU 显存，这三者是移植后造成小游戏平台内存暴增的主要因素，只要妥善处理这三方面，整体内存使用基本就能达标。

WebAssembly性能优化与内存挑战

WebAssembly 并非旨在替代 JavaScript（JS），而是通过扩展 Web 的能力提升其性能上限，从而更好地支持 3D 游戏、vr/ar 图像/视频编辑等类似的需要高性能计算要求的任务，其主要作用在于弥补 JS 在算力方面的不足。JS 作为解释性语言，运行效率相对较低；而 WASM 则是编译型的字节码，性能更接近原生。

在一篇关于 WASM 与 JS 能耗对比的论文中，对比了在安卓平台下，不同的手机浏览器中 WASM 与 JS 的能耗表现，可以清楚地看到，JS 的能耗远远大于 WASM，最大能耗差异接近三倍。这意味着将 WebAssembly 用于 Web 应用能显著降低对移动设备的能耗，最直接的影响就是降低发热。

尽管 WASM 的性能接近原生，但两者之间仍存在一定差距。下面这篇论文对多种 WASM 独立运行时的程序进行了表征性研究，并从内存、机器指令、缓存命中等方面与原生程序进行了性能对比。最终的结论就是在独立运行时下，wasm 就会比原生程序降低 1.5～9.5 倍的性能。以上两篇论文发表于 2022 年，具有很高的参考价值。

WASM 调用 WebGL API 时，同样也需要遵守浏览器的安全模型和策略。 WebGL 中每次调用 API 都会伴随着一定开销，这主要是由于安全验证所引入的。 在重度游戏中，WebGL API 调用极为频繁，这意味着在 Web 平台下，状态切换的代价会更高。 因此，有必要尽可能减少 SetPass 调用以及与 WebAPI 的交互。

WASM 虽然解决了 JavaScript 在高性能计算的问题，但也带来了内存挑战。 在小游戏中，编译后的 C++ 代码会再次通过 emscripten 编译成 WASM。 在运行时，WASM 代码会被再次编译并实例化，而编译+实例化的过程将会产生近 10 倍 wasm 文件大小的内存占用。

例如，在诛仙第一个 Chrome 版本中，WASM 文件大小为 90M，这意味着在运行时产生了 900M 的内存。 鉴于 iOS 小游戏内存限制为 1.4GB，WASM 占据了 900MB，仅剩 500MB 可用空间，这对于 MMO 游戏而言是远远不够的。 这部分内存的实际最终大小与平台、内核版本也有关系。 我们在不同的手机及不同浏览器上进行过详细测试，结果显示，尽管内存大小存在一定浮动，但最终结论都接近于 10 倍。 因此，对 WASM 进行缩减是必要的。

WASM 是代码编译的结果，因此，缩减 WASM 的本质就是缩减代码的使用。 Unity 项目的代码主要由引擎代码、package、第三方库，以及游戏逻辑代码组成。 可以通过 Player settings 对引擎代码和托管代码进行剔除，但这种剔除并不彻底，部分代码可能被引擎误判为已使用，或因错误操作产生引用，此时便需要进行手动剥离。 其中，最常见的就是 package 和第三方库，特别是对于仅在 editor 下使用的代码库，要正确设置其程序集平台，保证其只在 editor 环境下使用。

除此之外，还有一些需要注意的方面。例如命名空间，小游戏中无法使用多线程，尽管使用多线程的代码编译无误且运行结果正确，但最终还会以单线程方式执行，这会导致性能差异。因此，需要剔除线程类的命名空间。

对于 Job、Task 等与线程相关的，由于无法发挥其多线程优势，也应该直接代码中剔除，并相应的将功能改为单线程实现，同时基于单线程优化代码算法。

另外，关于共享库的使用，例如 json，在微信和抖音小游戏 SDK 当中都包含一份 json，而一些第三方库或 package 也可能包含或引用一份 json。对于此类问题，需要进行手动修改，确保项目存在一份 json。

关于代码设计模式，优秀的设计模式固然能提高项目的可扩展性和可维护性，但是过度设计则会影响开发效率，尤其在小游戏环境中，过度的设计模式会使 WASM 变得更加臃肿。

WASM 作为相对低级的编译目标，不支持泛型或模板等高级语言特性，生成的 wasm 代码是针对具体类型的具体实现。虽然在编译时，可以设置编译参数，进行编译优化，但对于过度复杂的设计模式，编译优化也无能为力。

举例来说，将属性写为访问器形式，编译后会额外产生 2 个函数。 此外，foreach 循环还会额外产生包含 try-catch 的语句，这些都会增大 WASM 的体积。

除编译问题，代码方面还有许多值得注意的地方。比如，对于 string，运行中产生的并且频繁使用的 string，最好使用 intern 把它强制放到常量池。能使用常量就使用常量，比如 vector.one，没必要再 new vector(0,0,0)。类似的问题还有很多。因此，需开发人员更加了解 IL2CPP，和 WASM 的机制，以便编写出更高质量的代码。

再说回到编译的问题，编译时可以导出一张符号表，如右上这张图 symbols.json 就是导出的明文符号表，左下就是该符号表的内容。利用这张符号表就可以对其文件进行解析，从而统计代码中每个类的占比。图右下，显示了对符号表处理的结果，例如 uilabel 约占整个 WASM 的 0.1%。开发团队会根据解析结果，从占比最高的类入手，逐步进行分析和优化，进而实现代码的剥离。图右下的是我们最开始生成的 wasm 分析文本。

目前，此功能在团结下已经得到了非常大的改进，能够可视化查看和对比两版本的差别，极大地提高了研发效率。

经过上述处理，WASM 文件已从最初的 90MB 精简至目前的 51MB，相当于节省了 400MB 的内存空间。

从图右侧可以看出，前述的每一步 WASM 精简方法，都对 WASM 内存产生了显著的影响，然而，目前仍有 500 兆的 WASM 编译内存，这仍然是一个相当大的数值。

即使通过代码剔除，在游戏的实际运行中，仍会存在一部分使用不到的函数。 事实上，每个小游戏平台目前都提供了代码分包的能力，可以将运行时使用的函数收集到主包，未收集到的函数划分到子包。 主包中所包含的函数，才是整个游戏生命周期所使用的函数。 通常情况下，大部分游戏的主包代码占比不会超过 50%，这意味着在最差的情况下，可以通过代码分包将 WASM 的编译内存再次减半。

首次进行代码分包是一个相对耗时的过程，需要进行充分的函数收集，以避免因收集不全导致函数被划分到子包。频繁地远程拉取子包函数，会使游戏运行变得异常卡顿。以上便是我们针对 WASM 文件的所有优化方法。

小游戏中的Unity堆内存

小游戏中的堆内存结构与 APP 基本一致，两者均通过贝母 GC 进行管理，但在细节上存在差异。

在 web 平台，UnityHeap 被实现为一个连续的线性内存空间数组，这部分内存是通过浏览器分配的，并且在生命周期内不会返还给浏览器。

在初始化阶段，需要为 UnityHeap 设定并设置一个大小，即预留内存。 当内存不足的时候，系统会通过 CopyArray 的方式进行扩容，此过程会产生一个内存峰值，极有可能导致内存崩溃。 例如，若预留内存设置为 600 兆，由于内存对齐，实际可能匹配到 608 兆，当内存不足进行扩容时，该帧的内存峰值可能达到 1.4GB，此时极易发生崩溃。 多数中重度游戏崩溃的原因，都是未能设置合理的预留内存，从而在内存扩容时发生崩溃。

通常对于重度游戏，推荐的预留内存值为 768 兆。 然而，并非必须严格遵循此值，只要确保内存峰值不超过预留内存即可，即使略大于 768MB 也无妨。 同理，如若游戏内存峰值肯定达不到 768 兆，也可设置得更小，将内存让给其他空间，比如 js。 因此，设置预留内存的目的是在合理的范围内使用内存，避免触发内存扩容和内存浪费。

托管内存方面，与 APP 不同，托管堆（Managed Heap）来自于 Unity 堆，释放后也只会返回给 Unity 堆，而不会返回给系统。 尤其在 Web 平台下，托管堆具有只增不降的特性，这是一个显著的差异。

托管堆不只一块，会根据实际的内存使用，在 Unity 堆中开辟多块，那么就会产生托管堆的碎片。 尽管 Unity 没有提供相关的设置或者相关的编译参数，来提前预留托管内存，微小抖小平台也没有提供相关的接口进行设置，但可以利用托管堆只增不降的机制，提前开辟一大块托管堆内存进行复用，以减小内存碎片，提高内存的整体使用率。 通过对比图示可以看出，上图未进行托管内存预留时，内存分布较为分散； 而下图进行预留后，内存碎片明显减少，整体内存消耗也随之降低。

在内存管理方面，GC（垃圾回收）在移动平台和 Web 平台也存在显著差异。 移动平台上，GC 在触发后会立即执行，而在 Web 平台，GC 仅在两个特定时机触发： 每帧结束时会执行少量 GC，以及切换场景时会执行一次完整的 GC。 因此，在 Web 平台的单场景尤其是单帧内，对内存的使用要注意以下几个方面：

一是设置合理的预留内存： 避免因为预留内存不足而造成 Copyarray。

二是避免内存碎片：特别针对托管内存，可以提前申请合理的使用空间并善用对象池来有效预防。

三是避免帧内内存峰值：在移植过程中，曾出现过单帧内加载多张配置文件导致托管内存暴增的情况。对于 native 内存的暴增，最常见的原因是对 AssetBundle 的加载。避免单帧内存峰值的最佳方法是拆分数据，分帧加载。

尤其值得注意的是，强烈推荐使用小游戏平台提供的 AssetBundle 接口，例如微信的 WXAssetBundle 和抖音的 TTAssetBundle。尽管早期项目曾尝试不依赖小游戏平台接口，但效果不佳。实践证明，WXAssetBundle 或 TTAssetBundle 能真正利用文件系统，从而显著减少内存占用。

四是，避免不当使用像代理、匿名 lambda、闭包等，这些不规范的使用方式会频繁产生堆内存，进而造成内存碎片，降低堆的利用率。

基于Unity的优化策略

许多常用的 Unity 优化方法在小游戏和手游上同样适用，对于优化来说，可以把小游戏视为对性能要求更为严苛的手游，以下是一些手游和小游戏开发中被验证实用的优化方法。

首先，针对 Unity 资源件，可根据项目的实际需求进行进一步精简。 比如 anim，Unity 下，anim 可以针对不同文件，设置不同的误差，采用不同的压缩率。 但在相同的骨骼点下，它们所需的精度有所差异； 这意味着相同的误差对于不同的骨骼点会产生不同的影响。

对于站立动作，其通常是新玩家进入游戏创角场景后看到的第一个动作。 较大的压缩误差会使脚步与地面产生较大的位移。 通过对比 error 1.0 和 0.5 的设置，可以观察到模型脚步与地面之间存在显著差异。 尽管有些项目为了给新玩家提供更好的体验，会在创角场景采用独立的资源以保证更优质的效果，但这会额外增加包体大小，并可能导致频繁的下载。

在《诛仙》项目中，我们采用了程序化方法对动画文件进行组合性压缩，针对不同动作、不同肢体部位采用不同的压缩误差，以此实现效果与性能的平衡。可以看到经过组合压缩的站立动作，腿部与地面的相对位移几乎很小。

具体来说，对于于站立动作，在腿部会采用更低的误差以减少滑步现象，而其他部位则会采用高误差低精度的方式进行处理，从而平衡整个动作文件的大小并保障局部动作效果。 经过这种处理，动作文件在腿部组合压缩后会拥有更多的采样点，确保了腿部的精度。

同时，在不影响手臂效果的前提下，组合压缩会尽可能减少手臂的采样点，从而平衡了整体文件的内存占用。

通过下图可以看出，组合压缩会更加拟合原始动作文件，而 Error 1.0 和 Error 0.5 的文件则与原始动作文件存在明显的曲线偏差。

这种组合压缩方法不仅能达到预期的效果，而且压缩后的文件大小也非常理想，甚至在某些情况下会比 Error 1.0 的文件更小。

除了 AssetBundle，全局光照（GI）数据也是重度游戏，尤其是 MMO 类游戏消耗内存的重要部分。在大场景中，目前通常通过光照贴图（Lightmap）和光照探针（Light Probe）的方式实现效果。光照探针作为一种实现 GI 的方式，相比 Lightmap，它更容易规避单帧内申请过多内存，也更便于实现离散的分帧加载，并且在制作 TOD 时更为便捷，显著增加了灵活性。

然而，光照探针的灵活性也伴随着内存的问题。 一个 Lightmap 中的采样点可视为一个 RGB 值（即 3 个 float），而 Unity 中的光照探针使用的是三阶球谐函数（3rd order Spherical Harmonics），这需要 9 个系数，共计 27 个 float。 对于 GI 而言，采样点越多，效果自然越好。 但是，过多的光照探针相比 Lightmap 内存势必也会翻倍。

鉴于球谐函数用作 GI 通常是低频信号，其在空间中的变化是平滑且连续的，因此相邻球谐函数的系数也极为相似。基于这一特性，可以对场景中的探针进行基于特征空间的降维压缩，从而有效优化内存占用。

在二维空间中，可以通过找到一个特征轴来表达平面内点的特征。同理，在三维空间中，也可以通过多个特征轴来表达三维空间的特征。因此，可以提取所有球谐函数的特征数据，并将其映射到特征空间，再根据前 n 个特征来重构原始数据，从而实现高保真度的压缩与还原。

从上图右侧可以看出，在不同特征数量下所表达的平面结果：特征数越多，越接近原始效果。在三维空间中，对于光照探针、环境光遮蔽（AO）等具有方向性的数据，均可通过这种方法进行降维压缩。

上图左侧的图像展示了三阶球谐函数的原始效果。中间的四幅图是经过降维并还原后的结果，其中特征是叠加的。当特征数量为一时，它表达的是最主要的特征。随着特征数的增加，细节也随之增多。在中间的四张图中也可以观察到，随着特征数量的增加，绿色部分变得更加明显。当特征数达到 13 时，整体效果与原始球谐采样几乎一致。

当然，也可以直接使用二阶球谐函数，但它会产生明显的差异。从上图左侧的两张图可以看出，尽管二阶球谐函数的色调与三阶一致，但在明度上存在较大差异，并且这种差异会随着建筑结构、光源等空间复杂度的增加而愈发明显。但是当特征 =13 的时候， 与三阶球谐相比，无论从色调还是明度，几乎感受不出差距。

利用特征空间进行降维的目的不仅是为了实现高还原度，更在于其在内存方面具备显著优势。

通过左上的两个公式可以更直观地看出，在大量探针的应用场景下，基于特征空间的降维显著降低了球谐阶数对内存的影响。具体而言，三阶球谐函数每增加一个探针将稳定增加 108 字节。而基于特征空间的压缩方法，每次增加的字节数是特征数乘以 4。当特征数等于 13 时，每个探针仅增加 52 字节。并且此时几乎可以还原原始探针的全部效果。

鉴于球谐函数主要用于表达 GI 的低频信号，在实际应用中可以适度缩小特征数。这样做既能有效减少内存占用，又能确保 GI 效果的质量。

以上阐述了针对数据压缩的方法。如前所述，小游戏对 Draw Call 和 SetPass 更为敏感。在保证效果的前提下，LOD 是降低 Draw Call 和面数的最佳方法。

LOD 的优势在于可以通过全局划分显著减少 Draw Call 和面数。但值得注意的是，单场景、单帧内对内存的申请也会随之增大。

我们重写了 LODGroup 组件，在切换不同物体的同时，能够使其以流式的方法逐步加载卸载对应的资源，这意味着仅加载当前可见的资源，而非一次性加载所有资源。这种做法能够平衡 LOD 带来的内存增加，有效管理和利用模型资源，从而达到平衡内存、Draw Call 和面数的目的。

值得注意的是，由于 web 环境下不支持多线程，所以 Unity 自带的的流式纹理也是无法正常工作。所有资源的流式加载都需要手动重新实现。

除了实体，我们也对粒子做 LOD。 如上图，随着 LOD 等级变化，部分粒子发射器会被直接剔除，而另一些粒子并不会被剔除，但其粒子的产生速率与生命周期会明显的缩短。 这种优化方式在团战等特效密集的的场景中效果明显，能在保证整体视觉效果的同时，进一步降低粒子消耗，优化场景性能。

对于草地特效这类同质物体群落，使用 LODGroup 无法达到理想效果。LODGroup 主要表达的是单个物体随距离远近的变化，而植被群落则表达为一个面。因此，我们通过 CullingGroup 的方式，基于距离实现不同密度的实例化绘制。使用 CullingGroup 的主要目的是弥补实例化合批无法被剔除的问题。后面我也会介绍一种在团结引擎下能够进行剔除的实例化合批的方法。

对于大型场景，还可以根据地块和距离调整特征数，让不同的地块使用不同的特征数，可以进一步降低探针内存。比如近处使用 13 特征的 GI，尽可能还原效果，而中距离、远距离逐步降低特征数，减少内存消耗。

团结引擎支持下的优化与实践

团结引擎对小游戏的支持是开发团队当前正在利用的重要引擎功能之一。借助团结引擎，我们能够进一步降低内存消耗。在将项目从 Unity 切换至团结引擎后，开发团队在所有配置（包括 projectsetting，playersetting 等引擎层面的参数设置）均保持相同的前提下进行了内存对比。结果显示，直接使用团结引擎能够为项目额外节省约 60 兆的内存，这一优化效果非常可观。

在团结引擎中，托管代码精简新增了“extreme”模式。相较于“high”模式，“extreme”模式在代码剔除方面更为激进。对于 MonoBehaviour 和 ScriptableObject，该模式仅保留项目中实际使用的类及函数。在我们的项目中启用此选项，能够将最终的 WASM 文件大小进一步缩小约 10 兆字节，这相应地意味着可以节省约 100 兆字节的内存。

Unity 中 Skinned Mesh Renderer 是一个性能消耗较高的组件，但在 MMO 类游戏中又必不可少。小游戏平台 CPU 性能大约只有 APP 的三分之一，因此需要尽可能减轻 CPU 的压力。为应对此挑战，我们将场景中可进行合批的角色通过“Instancing + VAT”的方式进行绘制，取得了较为理想的效果。

在骁龙 660 设备上，开发团队分别使用 GPU 和 CPU 两种方法为 140 个角色进行随机动画播放测试。结果显示，完全依赖 CPU 播放的帧率仅能达到 21 帧，而采用 GPU 播放动画则能稳定保持在 30 帧。

在 2023 年中旬开始小游戏移植时，缺少团结引擎和 gpu skinning，因此 VAT（vertex animation texture）是一个相对性价比很高的解决方案。 目前，团结引擎已经能够通过 GPU skinning 在 GPU 端实现蒙皮计算，同样可以减轻 CPU 压力，并达到理想的性能标准。 因此，我们已经用 GPU skinning 替代了原有的 VAT 方案，也节省了额外的工作量。

从上图中可以看出，在 108 个角色同屏的情况下，通过 GPU skinning 能够稳定达到 30 帧。而在相同场景下，使用 CPU skinning 的帧率只能维持在 10 帧以下。

WASM 调用 WebGL API 需遵循浏览器的安全模型和策略，每次调用 API 都会产生一定的开销。这部分对开发者来说是黑盒的，我们唯一的办法就是降低 dc 和 setpass，也就是降低游戏的复杂度。

在团结引擎下，可以对 Shader 进行优化，包括直接通过引擎层面减少对 WebGL API 的调用。这种方法对于某些低系统设备效果非常显著。我们在 iOS 16.4 系统上进行了不限帧测试，包括野外团战和副本。开启上图所示选项后，帧率能够提升大约 8 到 10 帧。

在合批方面，SRP Batcher 能够通过排序，将使用相同 Shader 的物体放到一起去绘制，从而使每个批次仅调用一次 ApplyShaderPass，减少了重复设置 Shader 的时间消耗。

目前，项目主要采用的合批方式仍是 SRP Batcher。运行时相比 StaticBatch 会有一定的消耗，因为引擎每帧会根据可见的 renderers 生成 render nodes。然而经过大量测试发现，在我们项目中，SRP Batcher 和 static batch 对于帧率的影响是相近的。鉴于静态合批会额外增加内存或包体大小，因此我们仍将 SRP Batcher 作为主要的合批方式。

后续团结引擎将推出一种更高效的合批方式，即 GPU Resident Drawer。目前团队正配合团结的同学进行性能测试。理论上 GPU Resident Drawer 的执行效率将高于 SRP Batcher，主要通过 BRG（Batch Renderer Group）进一步提高渲染效率，并且根据小游戏的特性，在单线程上做了特定的优化。只要场景中的物体是静态的，它的 buffer 就不需要更新，会长期驻留在 GPU 上。因此，与 SRP Batcher 相比，GPU Resident Drawer 在运行时也能减少一定的计算消耗。

GPU Resident Drawer 的主要目的是对于复杂场景的优化，尤其适用于场景中存在大量可以实例化合批的分散物体的情况。如果直接使用实例化进行合批，由于缺乏剔除，反而可能导致负优化。同样，若在 CPU 端自己实现剔除后再调用 Graphic DrawInstance 进行绘制，也会加重 CPU 端的计算压力，同样可能造成负优化。

而 GPU Resident Drawer 的一个重要特性就是解决了剔除问题。上方的表格是主城的测试结果，在 Drawcall、Setpass 以及功耗方面都有了非常明显的降低。

以上就是我今天的分享 谢谢大家。

Unity 官方微信

第一时间了解Unity引擎动向，学习进阶开发技能

每一个“点赞”、“在看”，都是我们前进的动力