【ashkeling专稿，未经授权不得转载!】

ashkeling报道/6月16日，第十二季微信公开课“让创造产生价值”微信小游戏开发者大会在成都召开，在上午的小游戏团队宣讲环节，来自微信小游戏团队的林育新以《ob电竞》为题做了分享。

林育新围绕微信小游戏团队为小游戏开发提供的全新基础能力与Unity快适配工具进行了介绍。林育新指出，开发者需注重小游戏在启动与运行环节的性能优化，推荐开发者活用微信小游戏提供的一系列新功能。同时，Unity快适配工具可帮助开发者大幅压缩App转换小游戏所需的移植流程。

以下是ashkeling整理的分享实录：

大家好，欢迎各位来到微信公开课的现场，我是来自微信小团队的的林育新。接下来，将由我为大家分享小游戏技术与性能升级。这次分享的主题主要分为两个部分，第一个部分是介绍小游戏的基础能力升级。第二部分是介绍Unity的快适配工具。关于第一部分，我将从平台新能力和调优工具两个方面去介绍小游戏平台的基础能力升级。

首先要为大家介绍的是我们去年下半年推出的高性能模式。社区里曾这么说过，顶配iPhone的运行性能表现甚至不如一些安卓的千元机。在iOS平台下运行中重度游戏时往往会伴随着发热卡顿的问题。为了提升小游戏的运行性能，优化游戏的体验问题，我们推出了高性能模式，对小游戏的框架和JS逻辑层进行优化，尤其是在ios平台下，JS的执行也可以享受JIT的加持，执行效率提高了三到五倍。性能表现是对齐到安卓的中高档机型。

那么，我们也通过了物理系统的测试用例来验证高性能模式的性能效果。通过右边两张效果图我们可以发现，在相同的支持设备稳定30帧运行的测试条件下，高性能模式的立方体数量是普通模式的八倍以上，物理性能得到大幅的提升。

最近的半年以来，接入高性能模式的游戏越来越多。我们从这些游戏的性能数据上来看，游戏的帧率表现基本都能提升20到45%。如果游戏在iOS平台下的性能表现不佳的话，建议大家接入高性能模式来优化游戏在iOS平台下的性能表现，具体可以参考我们屏幕左下角的方式进行开通。

除了高性能模式的支持之外，小游戏平台也一直在进行底层能力的优化和提升。在过去的一段时间内，平台主要着眼于以下三个方面的提升。首先是我们对iOS的文件读写进程逻辑进行了优化，实现读写接口耗时下降80%以上。这大幅减少了游戏运行时资源加载卡顿的问题。第二方面，在游戏的运行过程中，经常会大量调用微信平台的接口，典型的场景像广告接口的调用。而如果平台接口被线程的占用耗时比较长的话，将会影响游戏的实际帧率表现。我们对微信平台的接口逻辑执行效率进行了一轮全面的优化。目前是实现了接口的整体逻辑执行耗时下降50%以上，留下了更多的时间来给到开发者去处理游戏自身的业务逻辑。

其次，我们也对音频的底层的也进行了调优。主要是优化了其内存的占用，降低播放时延、降低失败率等等。优化后的音频播放成功率达99%，较优化前提升了3%。后续我们也会对平台的底层能力进行持续提升。这部分能力的提升是不需要开发者去做相关的适配工作的。

刚才介绍的能力更多是关注小游戏的运行时的性能提升，而开发者同样也需要关注小游戏的启动性能。缩短小游戏的整体启动时长，对于用户的新进留存具有非常重要的价值。在过去我们提供的启动流程的优化手段主要是围绕启动流程中的每个环节进行优化的。比如分包能力，尽可能地去减少每个环节的时间，来达到整体启动速度的提升。在这些优化手段当中，我们会考虑是否可以将某些启动流程提前进行，以达到运行的目的，从而实现进一步的优化。

通过线上的数据我们也会发现，在启动阶段，用户的网络带宽并没有得到充分的利用，我们完全可以用这部分带宽去提前下载一些游戏后续会用到的一些关键资源，也就是我们今天要介绍的并行下载能力。其原理是，在游戏的启动过程中，平台会在网络空闲时自动将开发者提前配置好、需要另行下载的代码分包，提前到和小游戏的主包同时下载。后续应用在加载分包资源时，如果并行下载已经完成了，那么则会直接从缓存中读取分包资源。如果并行下载的任务还没有完成，那么，平台会复用此并行下载的任务继续下载，而不会重复的去发起的网络请求。

通过并行下载能够一定程度上的减少用户在启动流程中等待资源下载的时长，用户可以更快地与游戏进行交互。通过实验测试，使用了运行下载的能力之后，用户进入到游戏的加载耗时，时间大概能降低0.5秒到2秒左右，那么大家是可以通过左下角的路径去了解和使用我们的并行下载能力。

除了对性能端进行优化之外，我们也在小游戏代码保护方面去进行了探索。接下来要介绍的是小游戏的代码加固能力。其最主要的作用是降低代码被恶意抄袭和搬运的风险。具体来看，加固能力提供的代码混淆和代码水印两个方面的能力。在代码混淆方面，我们通过对关键词进行隐藏和替换，打乱源代码的上下文关系，能够让攻击者在动态静态分析都变得极具挑战性。通过对代码加上与平台绑定的代码水印，在小游戏的整个生命周期当中，我们都能确保游戏代码的唯一性，以及游戏产权的全链条追踪，能最大程度地去保护游戏的代码产权。

从测试效果上看，加固能力与开源的工具对比及主要有以下两个特点，首先是第一个，加固后的代码体积膨胀较小，第二，在保障代码加固的前提下，性能损失会比较少，能最大程度地保障游戏的运行性能。那么目前我们的代码加固能力是属于内测阶段，也欢迎大家通过小游戏助手来去进行内测申请。

前面主要都是介绍了平台在性能和安全上提供的一些新能力。在开发者进行小游戏调优的过程中，我们也会提供一些配套的工具，下面我会介绍一下自定义启动产品上报。
在小游戏的启动过程中，对于用户来说，主要有两个关键的流程，游戏首帧和游戏可交互。

ob电竞APP下载首帧，即用户看到的第一帧游戏画面，目前大部分的游戏都会接入平台提供的封面图插件，在游戏首帧上面都能做到了优秀的水平。游戏可交互指的是用户游戏真正发生交互的时间。通常意义上是指进入到游戏的核心玩法，比如游戏大厅等场景。那么，在用户真正与游戏发生交互之前，通常是还会包含许多游戏的业务资源下载的处理逻辑。

如何去主动地发现游戏可交互前的各个启动流程的性能和流程情况，推荐大家可以使用我们的自定义启动产品上报。他和开发者内部自有的数据上报平台对比，主要是有以下两个方面的特点，首先，我们对于开发者自主上报的启动场景，会与小游戏的框架启动时间进行关联。提供用户从启动点击开始到启动完成的全流程漏斗分析，能够帮助开发者去精确的分析启动流程中的问题。第二方面，我们默认提供了网络类型、入口场景等长期的播种维护的数据筛选。同时，我们也支持开发者上报自定义的维度来去更精细化的分析启动流程中的问题。具体的使用可以参考我们的访问路径进来进行体验。

在过去，我们也提供了面向小游戏的性能评测标准。评测标准建立的初衷是希望能够引导开发去优化相关的一些性能数据。那么标准是依据微信小游戏的整体的性能表现数据结合操作系统、机型分档等多种维度而建立起来的。评测标准一直以来也被许多开发者作为性能反馈和调优的参考标准。

但是随着游戏品类的增加，玩法复杂度的升级，我们会发现原有的评测标准是较为粗糙的。所以在过去的半年时间里，我们在原有的多维度，多指标的基础之上，新增了不同游戏品类的新的数据，进一步丰富了维度和指标数据，同时我们也补充完善了测试服务的标准。那么由于性能标准的数据比较多，我们可以通过左下角的路径去进行查看。我们也会定期依据大盘游戏的性能表现去动态更新现有的评测标准，让评测标准长期成为开发者的调优指引。

下面将进入本次分享的第二个部分，Unity快适配功能。

要为大家介绍一下快适配方案的诞生背景。在过去，一款Unity app游戏如果想要移植到小游戏平台里，基本上是需要将游戏转换为JS格式进行重写的。不过自Unity 2018开始，支持将构建目标设置为WebGL平台。构建的导出包是基于WebAssembly的技术运行在浏览器里。既然能够在浏览器上运行，那么我们只需要在小游戏的运行时支持WebAssembly技术就能够实现在无需更换Unity引擎与重写游戏逻辑代码逻辑的前提下，将原有的游戏项目适配到到微信游戏小平台中。

有了这一技术原理的支持，我们看一下快适配方案整体的架构实现。相比于App的运行方式，小游戏是运行在操作系统之上的应用层。成为了能够让Unity游戏适配到微信小游戏平台当中，小游戏平台主要是提供了以下三个方面的支持。

首先是在开发阶段，我们为开发者提供了微信小游戏的SDK。它能够帮助开发者快速去对接微信平台的能力，比如登录、分享、支付。在工程的导出阶段，我们也提供了配套的优化和转换工具，能够帮助开发者将Unity项目导出为相应的小游戏代码包。最后，在底层能力上，我们在运行时实现了对Web3D等技术的支持，能够保障游戏的正常运行。通过对开发、转换和运行时的支持，一款Unity游戏就可以运行在微信小游戏的环境了。对原理和架构有了大致的了解之后，接下来，我们将介绍一下快适配方案的接入工作流程，它主要是分为以下四步。

首先是我们需要对游戏进行可行性的评估，那么这里我们会依据游戏的特点与平台差异去评估快适配方案的技术风险点。评估的时间和游戏的复杂度是有关联的。像轻度游戏一般是只需要半天左右就可以评估完成的。在确认方案可行，接下来是需要开发者去使用我们的转换工具将Unity游戏转化成基本可玩的微信小游戏版本。然后依据产品的需要去接入我们的平台能力，像分享、支付、广告等等。这一部分大概是耗费1-2周的时间。

最后，因为App和微信小游戏平台的差异，需要开发者针对小游戏去进行体验调优。这部分大概是需要1-2个月的时间。那么像大家熟悉的游戏，比如《ob电竞》、《ob电竞》、《ob电竞》等都是通过我们快适配方案接入到小游戏平台当中的。目前也已经有超过1000款的Unity游戏通过快适配方案接入到小游戏平台。

接下来我将针对部分接入流程的环节去展开具体的介绍。我们来看一下工具转换的具体转化流程。首先是需要开发者将我们的转换工具导入到Unity工程当中，在转换工具上设置好相应的转换选项。通过我们的一键转换能力，就能将Unity的游戏导出为能够在小游戏平台上运行的项目工程。这背后的各种工作，包括代码压缩、环境接口适配等等。都是由我们的转换工具来完成的。

我们来具体看下左边的示意图。左右分别是小游戏和Unity编辑器里的游戏界面图。可以看到，通过快适配方案转换的游戏在品质的还原度上还是非常高的。虽然转换工具也承接了Unity到小游戏平台的转换工作，但是，由于App和小游戏平台的差异，开发者还是需要针对游戏进行一定的性能调优，才能够使得游戏有一个较好的性能表现。这个调优的过程也是大多数中重度App手游移植到小游戏平台花费时间较多的一个步骤。

接下来我将从启动性能和运行性能两个方面去介绍一些常用的调优手段。首先我们来看一下启动的一些相关调优手段。一款轻度的休闲游戏，不做任何的优化，通过快适配工具转换出来的代码包大概是一百兆左右。按照用户2-3兆的一个网速也是需要大概四五十秒才能完成这个包体的下载。在小游戏即点即玩的场景下，这个时长用户肯定是不能接受的。

对于快适配方案转换的游戏，启动流程的优化关键是需要对包体做一个瘦身。这里的瘦身主要分为代码体积和资源两个方面。在代码体积方面除了使用常规的引擎裁剪、插件剔除、代码压缩等手段之外，小游戏还首创了WASM代码分包工具，它能够最大程度的去精简游戏的代码体积。

在资源优化方面开发者可以使用AssetBundles等的方式来去实现资源的一个拆分和按需加载。其次，开发者也可以依照我们的建议去精简游戏场景所需要用到的资源。我们可以看到，经过包体的瘦身完成之后，就可以完成在小游戏当中启动运行。

那么在用户的设备运行条件下，首次启动已经初始化完成的时间大概是6-8秒，二次启动是2-3秒就可以完成启动的。在开发者对启动流程的优化过程中，非常推荐大家去关注两个比较重要的指标，初始化完成时间和游戏可交互时间。前者是代表着开发者在包体体积优化层面是否达标，而后者是指用户游戏真正发生交互的时间，这两个指标项都应该在开发者的能力范围内尽可能的去进行优化，以提供较好的启动体验。解决了启动相关的问题后，运行时的话，游戏需要关注稳定性和游戏的流畅度。

稳定性最大的一个挑战是内存问题。在不做任何的优化的情况下，通常游戏的内存是会超过一个G的。在中低档的机器设备中很容易出现崩溃的问题，导致用户无法继续正常开始游戏。为此平台也提供一些优化手段来去帮助大家优化内存的问题。第一个推荐大家使用我们的WASM代码分包工具，它能够极大地降低由于编译WASM指令所造成的巨大内存消耗。其次，也可以使用我们的纹理压缩工具，它能实现多系统、自适应的压缩纹理格式支持，减少纹理资源的内存占用。经过这两个工具的优化之后，大部分的游戏是能够在中低档机器上稳定运行的。

除了稳定性之外，我们也非常建议游戏接入我们的高性能模式，并且依据游戏自身的一个特点，针对游戏脚本、引擎特性，以及渲染方面进行一个针对性的优化，来提升游戏运行时的流畅度。

除了上述的优化指南之外，小游戏平台也一直在不断的探索一些新的工具和优化手段来去帮助开发者更好的发现和解决性能问题，像最佳实践检测工具目前是已经集成在最新的转化工具当中的。在开发阶段，我们会依据平台的实践指南，主动去发现小游戏的一个优化事项，并且给予开发者相关的优化指引。关于新工具和优化手段的详细介绍。大家可以通过我们快适配的官方文档去进行查阅。刚才主要是针对接入流程中部分环节进行详细的介绍，接下来我将就两个具体的游戏案例去分享通过快适配方案接入的详细开发周期。

首先是第一款游戏，是一个卡牌类的游戏，《ob电竞》。大家可以扫码体验一下这款游戏。卡牌类的游戏通常整体接入周期是一个月左右时间。但是接入和调优的周期是需要由游戏需要改造的内容的决定的。具体到《ob电竞》这个案例来看，首先是我们用了两天的时间去评估游戏里面需要做的一些兼容性改造。确认好需要改造的内容之后，接下来开发者用了一周的时间去完成原生能力的调整，以及对游戏中使用到的一些第三方的插件进行平台的适配。

到这里基本已经能够得到一个基本可玩的小游戏版本。接下来是进行平台能力的接入。如果没有特殊的需求，通常是一周左右的时间就可以完成。最后一 步是需要针对小游戏进行体验调优，这里可以参照我们刚才介绍过的启动和运行性能的调优手段，去对游戏体验调优。一般是1-2周的时间完成，但是有的技术能力是可能需要比较多的时间才能去优化完成的。

第二款游戏是一个slg品类的游戏《ob电竞》。重度游戏的一个开发周期，相比于中轻度游戏来说，它的开发周期是会更长的。一般是需要两个月左右的时间在游戏转换上。除了对资源进行改造之外，重度游戏需要改造的能力可能会更多一些，比如多线程、网络相关的改造。并且由于重度类型的游戏，游戏内的系统会比较多，需要接入的平台能力肯定也会更多，所以在平台能力的接入通常时间也会更长。在体验调优阶段，因为游戏玩法相对复杂，所以是需要花费更多的时间和精力去进行运行性能的优化，一般是需要一个月左右的时间。大家也可以体验一下这款游戏的效果。付出时间的优化还是非常值得的。

那么按照以上两个分享案例，他们都是在投入1-2个人的人力情况下，中轻度游戏的一个研发周期大概是1-2个月，重度游戏大概是需要2-3个月。如果游戏可以投入更多人力的话，研发周期是会进一步缩短的。

虽然快适配方案最初是为了解决Unity APP游戏转换到小游戏平台而衍生的一套技术方案，但实际上快适配方案并不只能适用于Unity游戏。目前我们在开发者社区中也有发现，有使用通过Cocos 2dx引擎开发的游戏，通过快速配方案的配套工具和底层能力的支持也将游戏转换到小游戏平台上，并顺利运行了起来。所以如果有使用Cocos 2dx或者其他引擎的游戏厂商想要通过快适配方案来将游戏转换到小游戏平台之上的，欢迎联系我们一起攻坚快适配的通用方案。

最后分享一下，在我们配合游戏接入的过程中，我们也积累了非常多的一些经验，包括各种游戏品类的接入指引、优化指南、游戏最佳实践等。开发者在游戏的移植过程中，如果有遇到比较难解决的问题，欢迎大家到我们的官方文档去查阅相关的一些解决方案，或者是通过以下的联系方式与我们联系沟通。那么今天我的分享内容主要是这些，感谢大家的观看。