千万级产品背后的技术逻辑：同趣科技 CEO 详解小游戏性能调优策略

小视作为轻量级内容载体，对性能要求非常高。同趣科技 CEO William 博士在今年的 Unite 大会上分享了团队在框架设计、启动优化、CPU/GPU 协调、内存与资源管理等方面的优化经验，并介绍如何借助对小游戏友好的团结引擎，实现性能和效率的突破。

William：各位开发者朋友们，大家早上好！很荣幸有机会在这里跟大家分享“小游戏平台性能调优策略”。大家都知道小游戏的用户对性能要求特别敏感，因为它受性能所限。无论是资源、还是空间，都比较有限。开始之前，先介绍一下我们公司。我们公司目前已经成立超过 10 年，在杭州，早期主要是做“出海”的，近两年有在聚焦做国内的一些小游戏，做过的产品目前也已经超过了 100 多款。

下图是近两年有登陆过各个榜单 TOP1 的部分产品，大部分都是益智休闲类，这些产品全部都是千万级以上，部分都是“亿”级别的一些产品。

第一款《箭头消消消》是 2023 年初做的一个产品，那时候整个市场环境都在用别的引擎在做 2D 类的产品。我们其实希望做出差异化的产品，当时 Unity 在适配小游戏上还不是很成熟，比如一款产品、一个游戏加载可能就需要 10 秒、有些甚至超过 20 秒，用户的体验非常差。但是我们依然坚信 Unity 的游戏在美术表现上会更细腻一些，其他方面会做得更好，所以当时 Unity，而且无论是微信团队或者抖音的团队，也给了我们大力的支持。所以在这里，也特别感谢 Unity 的团队。

第二款《打螺丝达人》是大家可能经常在朋友圈看到的。第三款是我们做的一个卡比巴拉元素的一个产品，当时在国内整个引起的一个卡比巴拉的一个热潮。最后一个是《猪了个猪》，今年上半年爆发的一个产品，目前用户已经过亿。在制作《猪了个猪》的过程中，我们在技术上也踩了很多坑。之前在其他平台的几次分享，我都是分享从立项到调优、到买量，都是去聊运营、聊产品，今天是第一次在这个平台去聊技术。我们也乐意把过程中积累的经验，今天毫无保留的分享给大家。

首先，我们得明确小游戏性能的核心痛点：内存受限，加载要求高，多平台适配难。针对这些痛点，我们总结了 5 大优化方向：

框架与资源管理优化

预制体：首先可以提高复用性，通过预制体，比如结算界面、皮肤商店界面，可以批量的生成实例，减少重复创建开销、提升加载效率；其次预制体可以统一管理，修改预制体参数能自动同步到所有实例，降低维护成本，提升开发效率；第三是性能优化，预制体支持安需加载，减少运行时资源占用，优化性能表现；最后是场景结构清晰，预制体可将复杂场景节点模块化，提升 Hierarchy 可读性，为后续优化的提供清晰的基础。

对象池：可避免频繁创建销毁，对象池可复用频繁生成与销毁的对象。以《猪了个猪》为例，角色、拖尾特效等，可以减少内存分配与回收。同时可以降低 GC 压力，减少垃圾回收触发的频率，降低内存的抖动与程序的停顿。从下图中可以看出来，它提升了游戏的稳定性和流畅度。此外，对象池可以有效降低 CPU 的负担，特别适用于微信小游戏或者抖音小游戏。这些对性能特别敏感的平台，也包括鸿蒙或者其他 OV 系统。因为现在的硬核渠道也增长迅猛，或者说像硬核联盟、小米渠道等等。

设计模式：合理使用设计模式，减少代码耦合度，方便阅读和维护。但过度使用，可能会增加代码量和影响性能。

代码层性能提升策略

这里面有两个“避坑指南”和一个“加分项”：

• 分帧加载/处理机制

分帧加载/处理核心思想：将原本集中在一帧内完成的密集任务，分摊至连续的多帧中执行。

• 启动速度与主包精简策略

大家都知道小游戏主包要求越小越好，主包越小首屏展示越快、用户流失越少。通过资源分包、压缩纹理与音频手段，可以精准主包。另外，就是首场景的异步加载，实现用户点击即进入游戏就能看到画面，降低流失率、提高启动的速度。

最后就是结合首场景异步加载策略，优化启动流程。这个也是微信小游戏提升留存的一个关键环节，大家都知道对于小游戏来说其实需要跟运营去结合、跟买量结合。我觉得性能应该对留存的帮助是特别大的。

刚才看到的几款产品其实基本上都已经调优超过三年，但是一直还在调，这些基本上都是两三年前的产品。我们为什么一直还在调？我们其实因为是买量结合，也能实时看到这个真正投放到底有没有效果，这些调优的反馈会比较及时。

切勿在 Awake 回调函数中执行复杂逻辑

在 Awake 中避免放置复杂逻辑是 Unity 开发中一条至关重要的性能优化准则，尤其是在微信小游戏中。所以如果 ScpritB 的 Awake 里有一段代码需要依赖 ScpritA 的初始化，而 ScpritA 的 Awake 还没执行，你就会得到一个 NullReferenceException。如果在 100 多个对象池的 Awake 做的耗时操作（如查找物体、加载资源、复杂计算），这些操作会叠加起来阻塞主线程，导致场景加载出现一个巨大的卡顿峰值，进度条停滞不前。对于微信小游戏来说，首场景加载时间就是生命线，因为用户如果卡顿 1 秒钟可能就丢失一大批。如果在关键节点卡顿，基本上这个用户就流失了，所以必须尽一切可能缩短这段时间。在 Awake 中过早地加载大量资源或实例化对象，会导致内存瞬间飙升，大量资源在场景加载初期就被塞入内存，无论你是否立刻需要它们，无法优雅地管理，就失去了按需加载和分帧初始化的机会。正确的做法就是 Awake 只做简单的初始化，在 Start/OnEnable 中去做一些逻辑。

CPU 与 GPU 协同优化

下图是小游戏一帧的流程，技术人员应该都比较清楚。比如说我们从一开始执行游戏逻辑、物理，再到 CPU 的准备工作，之后 CPU 再将 DrawCall 的资源提交给 GPU 处理，以及最后到 GPU 的渲染，包括输出到屏幕上。

做小游戏，我觉得性能要求特别高，所以可以用一些 Unity 自带的 Profiler 的性能分析工具。如下图所示，左侧是性能分析器模块，右侧是帧图表。这些模块的作用，比如 CPU 可能会显示各个函数跟模块的 CPU 耗时，支持展开调用栈、定位耗时函数，以及包括 GPU 耗时的一些需要支持的平台和驱动、内存分布等等都有。所以我觉得在开发小游戏的过程中，这些工具可以用起来。

下图是我们 Profiler 上的一个截图，大家可以看一下。主流手机一般都是在 60 帧，一帧大概就是 16.66 ms。如果超过 16.66 ms，CPU 处理就过大，可以考虑把 CPU 部分功能分摊给 GPU，降低 CPU 的压力，比如存在大量动画节点时可以使用 GPU Skinning。例如：原来给 CPU 处理之前，可能就是基本上要到 20ms，部分工作交给 GPU 以后就能达到 16.6ms，帧率能够达到 60 帧以上。

下面介绍 GPU Skinning。对于需要极致性能或有特殊需求（如大规模人群、顶点动画）的项目，可以使用 Compute Shader 来手动实现 GPU Skinning。工作原理就是在 GPU 上并行计算所有顶点的最终位置，将结果写入一个 ComputeBuffer 中。然后在渲染时，标准的不含皮肤逻辑的顶点着色器直接从该 ComputeBuffer 中读取最终的顶点位置。优点是性能最高，灵活性最强，可以处理非常规的动画效果。缺点就是实现操作比较复杂。

下方是我们使用前后的对比图。未使用 GPU Skinning，可能 GPU 耗时就是 30 多 ms，用完后就可能达到 16.6ms，大概 60 帧率。使用过后的一个效果就是提升了帧率，游戏更加流畅，减少 CPU 的处理压力，有效降低发烫和发热。特别是对于 iPhone 来说，大家知道 iPhone 手机玩小游戏其实发烫就特别明显。所以这些对于规模上一定量级的小游戏，我觉得这一点处理特别重要。

另外一个模块，讲一下内存与资源的优化策略。纹理压缩可以采用 ASTC 等格式压缩纹理，贴图 maxsize 尽量不要超过 1024。音频处理，音频资源尽可能勾选强制单声道。大家都知道声音文件是很大的，在小游戏这种对内存要求极高的，所以你可能要稍微损失一点这个效果。尽量避免使用 RenderTexture，尽量减少 RenderTexture 的使用；同时要做到主动的释放资源，及时释放不使用的资源，比如使用对象池来频繁创建销毁的对象。还有就是合理地触发 GC，比如每局游戏的开始、结束或者场景切换时，主动触发垃圾回收。针对 iOS 跟平台，也要采取差异化不一样的 GC 控制策略。

高性能与 JIT

高性能模式下，内存可能要求更加严格，比如 iPhone 6s、7、8 等 2G RAM 机型的内存限制为 1G；对于 iPhone 7P/8P/11 等 3G 以上内存机型的内存限制为 1.4G。当内存紧张的时候，这时候需要引入代码分包。分包的作用在于优化启动时间。另外对于 iOS 的高性能模式，分包还有两个作用：一个是减少内存使用，以支持更多 iOS 低端机上运行高性能模式，另一个是减少编译时间，降低了游戏前期的发烫情况。大家都知道由于 iOS 平台系统限制的原因默认无法 JIT 解释执行，所以结果就会导致 JS 执行性能受限。那么高性能模式使用 Apple Web kit，间接获得了 JIT 的能力，就显著提升了 iOS 的性能。同时我觉得开发者的优化核心还应该是精简 JS 代码、减少循环和递归的使用，并精细内存管理、对象池的引用，避免泄漏。

最后我们聊一下团结引擎。给大家推荐一个利器就是团结引擎，它对于小游戏平台特别友好，支持微信、快手等平台的 MiniGame 构建，就不需要到处去查找插件。另外一个就是性能上，我们也做了一下对比，就是性能上也有较大的提升。下图是《猪了个猪》的内存对比。大家可以看到 Shader、粒子系统、字体等方面都有特别明显的提升。比如第一项，用 Unity 占用空间 40 多 MB，用了团结以后可能只有 4MB。

小游戏的性能调优不是一锤子买卖，而是细节堆出来的流畅。比如一个预制体的使用，一次二维逻辑的调整，一次 GPU 的协同，看似小事，却能决定用户是否留下来。希望今天的分享对大家有所帮助，也期待未来和大家一起探索出更多优化的方案。谢谢大家！

Unity 官方微信

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

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