腾讯和鸿蒙系统（腾讯朱煌技术赋能）

11月20日-22日，QQJOY嘉年华在上海举办。而在20日当天的QQ开发者大会，腾讯公司QQ小程序/小游戏平台技术负责人朱煌，带来了一场关于技术赋能——小程序小游戏最佳实践的演讲。

对玩家来说，小程序/小游戏在体验上一定是点开即用、点开即玩的，这对性能也提出了更高的要求。目前大多数用户反馈的问题，也都集中在启动速度和运行性能等方面。

朱煌提到：“在Loading界面等待超过三秒的用户流失率升得很快，如果首次启动速度能在三秒内，能减少百分之七十五的流失。”对于如何优化小游戏加载速度，朱煌给出了具体的答案。

而为了服务好小游戏开发者，腾讯也准备了一个大招：CrossEngine，这款QQ和IEG 去年一起开始联合开发的CrossEngine，为小游戏和手游同时提供3D引擎能力和工具的支持。并且一次开发能够支持手游、QQ平台和微信小游戏平台多平台运行，也计划支持原生云游戏。

以下是演讲实录

朱煌：各位开发者们，大家下午好，我是来自QQ小程序小游戏团队hank。

今天很高兴能在这里，以技术的角度，分享小程序小游戏平台的最佳实践和思考。

首先来简单回顾一下，平台能力开放的过程。从去年7月份开始开放接入以来，凭借着较低的接入成本和快速迭代的生态能力，吸引开发者加入，已经创造了不少优质的小程序和小游戏。

那我们从最早基础建设，到不断开发的新能力，比如云开发和实时音视频的能力，去帮助直播类的小程序快速上线。

同时，QQ把自己的关系链通过子域的方式开放给开发者，可以开发出基于好友和群关系的玩法，提高用户粘性。

除了关系链以外，QQ特有的生态，包括群和彩签能力，以及加好友加群等私域流量也以API的方式开放出来。

小程序小游戏和平台的结合越来越紧密。在这个过程中，我们一直是开发者的帮手，来生产更多优质的内容。

最近几个月，我们一直在思考两个问题，第一个是，平台还能提供哪些能力，尤其在QQ强大的社交背景下。那这里也做了一些尝试，比如对战游戏在用户数据上的确有更好的表现。

另外一个方面，小程序小游戏在体验上一定是“点开即用、点开即玩”的方式，对性能也有更高的要求。那我们也一直在思考性能有没有进一步提升的空间，哪些是可以一起来优化。

首先，我们发现的一个趋势是，越来越多的虚拟形象在游戏中的使用，可以提高游戏的沉浸感和趣味性。比如snapgames通过bitmoji带来更多高品质的游戏。回到我们的平台，也有非常多的3D形象在游戏中使用，只是大部分都是骨骼小人和灰皮小人，缺少精细的运营。那带来的游戏体验感也会差一些。主要的原因是素材制作的成本还是比较高的。

虚拟形象一直都是QQ的社交资产，从PC时代的QQ秀，到移动时代的厘米秀，已经是一套体系，并且积累了非常多的用户。

这里的玩法，从厘米秀选择，2D/3D主页，到AIO的动作/表情玩法，以及最近我们上线的自动捏脸和装扮，可以满足更多个性化的需求。厘米秀已经活跃在QQ的各个场景。

厘米秀有没有可能和小游戏结合到一起呢？随着平台和产品的开放，答案是肯定的。我们把这部分能力做成厘米秀Kit，放到小游戏生态中。也能带来不少效率的提升，原来在一个游戏团队，需要设计师、前端、后台一起协作，几个星期甚至到数月才能做出来的效果。那现在只需要一位前端做一下API的接入，几天就能完成。那这里的设计原理和接入方法具体是怎么样的。

首先看一下现有的小游戏架构，初步分为三个部分：上部是游戏业务JS逻辑，中间是第三方引擎；底部是平台的native引擎。

厘米秀kit实现的是平台和引擎在模型标准和加载能力的对齐。

开发商只需要简单的代码接入，其他的可以交给我们，就可以把用户个性化的形象带入到游戏中。目前厘米秀kit已经有部分游戏在接入，欢迎大家来使用。除了能力建设外，作为开发商和用户的连接者，我们也一直在倾听用户的声音。

这个是最近半年来提取的一些反馈关键字。可以看到一些赞许的，那更多的是用户反馈的问题，打不开、卡顿是经常出现的关键字。那我们从感性的反馈，去做一下理性和技术的分析。

首先是启动速度，启动耗时和留存有些密不可分的关联，有位研究人机交互的Jakob教授，发现响应时间有三个非常重要的时间点：

首先是100ms，如果超过100ms，人会感受到交互的不连续。大部分的native页面打开都是在100ms内。

第二个是1s，超过1s，会感受到思路被打断。这也是为什么很多性能优化的目标都是秒开。如果超过10s，大部分用户会选择关闭。那我们看一下，大盘首次打开流失分布图，也就是说在loading界面就关闭的用户关闭的时候等了多久。

其中可以看到，大于3秒，流失率升得很快，如果首次启动速度能优化到3s内，我们能减少75%的用户流失。那有没有什么办法？

首先简单看一下启动的流程，从点击到渲染出来，平均iOS需要3-4s，android需要5-6s，经过分析，大部分的耗时在业务包的下载。

而外网的首包平均大小是2.29M，虽然有压缩的办法，意味着光下载可能都需要几秒，这里有不少优化空间。另外加载数据也需要一个以上的RTT，可能有上百毫秒的延时。

针对这些场景/部分，我们建议一些优化办法。首先是分包，这个是最有效的优化手段，可以把启动逻辑放在首包，其他放分包延迟加载。

另外针对游戏，我们去年年底推出了引擎插件，只需要在game.json配置引擎信息，能做到跨游戏的引擎插件复用，实际测试平均能提速28%。

最后一个是数据预拉取的API，可以提前或者并行拉取启动需要的JSON数据或者对应的资源包zip。加快首帧的加载。

另外一方面，渲染性能也是体验非常重要的部分。一般小于30fps就可能有卡的感觉。那这个占比在外网接近36%。

那怎么发现卡顿点具体在哪，我们提供了FrameFrofile工具，可以通过真机调试看到每帧的函数调用和消耗，对应来优化。实际FPS低是有一些常见的原因：

（1）JS逻辑过于复杂，复杂的部分推荐用异步化和worker来解决。

（2）帧间隔设计不合理，比如实际的游戏复杂度每秒只能处理30帧，但是设置了60次回调，会导致处理不过来。这里可以采用动态帧率的API来设置合理的回调次数。

（3）纹理和物理效果复杂，可以通过一些降级、复用的方式优化。平台也做了GPU加速来优化这里的性能体验。

有了这些优化后，大部分游戏都可以流畅的跑起来。但是随着小游戏和硬件的发展，游戏的玩法越来越多样，尤其现在的大型3D游戏也尝试在小游戏平台跑起来。由于这些游戏模型顶点和面数非常多，drawcall也非常多，性能瓶颈比较明显。

尤其基于webgl渲染的框架，大部分逻辑都是在JS层，而且在iOS平台没有JIT性能会更差。当前框架已经不能满足这些游戏的要求，带着逻辑下沉到native的思路，和IEG游戏引擎团队的研究。

我们从去年开始一起联合开发CrossEngine，为小游戏和手游同时提供3D引擎能力和工具的支持。

CrossEngine主要包括全新设计的渲染接口，能使用最新的硬件能力，比如iOS的Metal。也使用了最新的ECS架构，并且一次开发能够支持手游、QQ平台和微信小游戏平台多平台运行，也计划支持原生云游戏。

CrossEngine目前已经完成了基本模块的开发，包括整个Core、runtime和UI系统。也完成了demo的验证。这里有一个在手机QQ iOS上跑的demo效果，开放的格斗场景，超过10W面的模型，已经有了流畅的效果。

CrossEngine目前已经也有深圳的游戏团队在接入和测试，也期待很快有更多游戏来使用。

总体上，平台以后会更开放，更多玩法和能力。同时也会在工具和引擎上提供给大家更强大的支持，以技术赋能。也期待在QQ平台上创造更多优质的小程序和小游戏。

谢谢大家。

,