如何开发一款小游戏

小游戏目前的火爆程度已毋庸置疑，从全民“跳一跳”到如今的“星途 WeGoing”，小游戏已逐渐渗入消费者日常，成为老少皆宜的娱乐产品之一。腾讯微信高级工程师邹伟现场结合《星途 WeGoing》的底层架构和研发设计，分享了如何更好的利用微信的开放能力开发一款小游戏。

什么是小游戏？

从普通用户的视角看，小游戏是小程序的一个子类目，可在微信内被便捷的获取和传播，即点即玩，具备出色的用户体验。小游戏是小程序，普通用户分不清也无需分清。

同时，从开发者的视角，它可以看作是基于 Canvas/WebGL +  微信社交开放能力的一个新平台。下图是一个小游戏的一个架构概览：

这是一个典型的分层架构。最上层蓝色部分，是游戏代码，分为游戏逻辑，游戏引擎、weapp-adapter三部分。大部分游戏开发会用到一些引擎的工具、工作流，以及利用引擎封装的高层 API去实现游戏逻辑。其次是 weapp-adapter，因为小游戏的底层一方面不是 webview，可以简单看成是 webview经过精简、优化过后的平台；另一方面核心能力的实现上却参考了 webview。所以这里如果有一个适配器，把小游戏的底层 API——wx API适配到一个接近 webview的接口，对上层引擎、已存在的游戏接入微信小游戏平台则会更加容易，这个就是 weapp-adapter的作用。其中只有游戏逻辑是必要的。

中间层红色部分是微信以及小游戏 Runtime，Runtime对外暴露的能力叫 wx API，有一个基础库的。有一个 jsvm用于执行游戏的 Javascript代码，在安卓上是用 V8Core，iOS则是 JavaScriptCore。再下面一层是核心的渲染能力的实现，包括 Canvas 2d以及 WebGL，当然还有微信开放能力相关 API的实现。

可以看到，在架构上小游戏和小程序是有差别的，小游戏没有页面概念的，wxss/wxml不再存在。其次，底层实现也不是 webview，小游戏和 webview的关系只能说是渲染相关的核心能力可以通过 weapp-adapter的简单适配保持接口一致，但同时很多 webview上存在的功能并没有对等的实现，比如小游戏就没有 DOM/BOM的概念，也没有全局的 document/window对象。

小游戏的入口为 game js文件，语言为 Javascript，但有一些限制，比如禁止执行动态代码，因此 eval、new Function等能力是不支持的。配置为 game.json，可以配置横竖屏、接口超时等参数。js里面可以组合 wx API的能力来实现游戏逻辑， 非代码类的资源应该尽量放到 cdn，减少整个代码包打包后的大小，以加快用户首次进入时的速度，微信对首包的大小目前限制为 4MB。

小游戏能力概览（小游戏能力在不断扩充中，最新、完整能力可关注我们的开发文档）：

小游戏的核心逻辑的开发过程和传统的端游、页游以及现在的手游，并没有多大区别。这里会着重介绍一下怎么更好的利用微信小游戏的平台开放能力，包括选择小游戏引擎选择、设备 /环境适配、微信登录、缓存、开放数据域、分享、支付、性能、版本更新机制、运维这几个部分。

选择小游戏引擎

微信跟引擎商也有比较密切的合作，一般现在的游戏引擎都会支持发布到多个平台，对微信小游戏这个新平台而言，已经有一部分引擎做了适配，比如 Cocos Creator、Egret Engine以及 LayAir Engine。适配的主要工作，类似之前提到的 weapp-adapter，把 wx API的能力，和引擎衔接起来。比如引擎一般会把小游戏平台和 webview平台对标，适配过程就是把 wx API对应到 webview的能力，同时把只存在于 webview能力的依赖去除，比如不再依赖 BOM、DOM。

设备 /环境适配

微信本身运行在不同 OS平台，如 iOS、Android，而不同平台又运行于不同的物理设备。运行于微信之上的小游戏，自然就面对不同类型设备和环境的适配。当然能力上，小游戏平台已经尽量消除了它们的区别。但仍然有一些工作需要开发者去针对性的优化，比如高分辨率屏幕，可以提供更高清的画质。小游戏会有 API提供获取屏幕的宽高、设备像素比等能力。小游戏开发完成后，在开发者工具也可以发起真机测试的请求，微信提供了不同设备的测试集群，帮助开发者提前去发现问题。基础库提供的 wx API本身是一个不断迭代更新的过程，对于使用了新能力的小游戏，需要做低版本兼容。比如在检测到不支持新 API的低版本允许有损服务用户。同时，如果某个低版本的用户占比较少，可以考虑在 mp.weixin.qq.com管理后台直接配置小游戏要求的基础库最低版本，当然也意味着这一部分用户在接触到这个小游戏时，微信客户端会弹出一个要求用户更新到微信新版本才可使用该小游戏的提示，如果他不更新，你就可能失去了这个用户。

微信登录

小游戏的登录过程，跟小程序是类似的。需要用户自己去定义登录状态。appsecret/session_key代表的是小游戏开发者和微信平台之间的一种信任约定，比如支付、上报托管数据，平台方需要验证 access_token(只有 appsecret才能换得到)，和用户相关的还要验证 session_key的签名，才能保证请求来自于小游戏开发者 /用户，而不是恶意的第三方和随意捏造的用户。access_token是一种应用态的 access_token，和用户无关，需要保证全局维护一份，应该有一个中控的模块去保证 access_token有效，同时在有效期内直接使用本地 cache的 access_token，而不是每次使用都去生成新的 access_token，否则可能遇到调用频率限制的错误而影响服务。切记 appsecret/session_key不要放到前端代码中去，否则可能会被坏人利用损坏小游戏开发者 /用户的权益。

缓存

缓存类型包括数据缓存和文件缓存两类。数据缓存即 key-value存储，适合结构化类型的小数据存储，上限为 10MB。文件缓存提供了一个完整的文件系统 API，包括目录 /文件的增删改读，适合针对经常使用的网络资源做本地缓存，上限是 50MB。

和浏览器不同的是，微信只提供了基本的存储管理能力，并不对存储什么，和存储满时删除什么做一些操作。开发者自行灵活定义缓存以及淘汰策略，比如对经常访问的资源存储到文件系统以及在文件存储满时，清理一些最近不常访问的文件。

开放数据域

开放数据域是一个封闭、独立的 JavaScript 作用域，和执行游戏逻辑的环境——称为“主域”隔离。其目的是在保证用户隐私的前提下开放用户数据给第三方，提升小游戏的整体用户体验。以下为物理视图，主域的入口为 game.js，开放数据域则是一个独立的目录，其入口文件为 index.js：

主域和开放数据域的通信受到严格的管制，基本原则是只进不“出”。

只进：允许外部的数据进入开放数据域，即主域可以随时 postMessage到开放域，以及开放域引用主域准备好的本地资源

不“出”：不允许开放数据域的数据被上传到第三方服务器去。因为开放数据域里面，index.js是可以直接访问到用户敏感数据的，比如同玩好友数据。当然最终开放数据域需要 index.js在综合各种数据后把数据以图形图像的方式渲染到 sharedCanvas上，在主语 sharedCanvas允许 draw到主域的上屏 Canvas上，最终用户会在显示屏上看到 game.js画出来的好友排行榜、群排行榜或好友超越等社交互动信息。

目前开放数据域仅支持 2D渲染模式。

分享

包括自定义分享和系统菜单分享，可以分享到群聊、单聊。也可以把分享上下文与特定的群关联，实现一些群 PK、群排行榜的场景。分享是一把双刃剑，需要谨慎使用，一方面避免过度骚扰用户 /群聊，另一方面增强社交互动提供好的游戏体验，需要找到一个合适的平衡点。

支付

小游戏在安卓下支持虚拟支付，它的方式目前只有一种：即货币托管的方式。主要分为 2个流程：

1. 充值：RMB -> 游戏币，这里开发者只需要拉起支付的流程，平台负责把用户 RMB兑换成对应的游戏币，存储到用户对应的游戏帐号上

2. 使用游戏币购买道具：开发者可以扣除对应的游戏币，给用户发放游戏内道具，扣除游戏币的过程需要有一定的事务机制，去保证在网络异常的情况下交易正常。扣除游戏币的接口支持根据订单 id去重，意味着网络超时等情况下，开发者可用同样的订单 id去重试扣除，直至返回明确的响应。

以下为简单时序图，部分角色针对开发者无需关心的部分做了相应简化处理：

性能

小游戏常见的性能问题，一般是内存造成的。如果内存占用太多会被微信客户端主动关闭，因此开发者在用户游戏过程中要及时释放不再使用的内存（js代码去除引用，或主动调用对应资源的释放接口，如果有的话），特别是 Canvas和 Image类大型对象，同时可以主动调用 wx.triggerGC触发底层回收对应资源。

对于和游戏逻辑相对独立的工作，可以考虑在 worker中去实现，小游戏提供了独立的 worker线程执行 js逻辑的能力。

版本更新机制

小游戏启动的过程分为冷启动和热启动。冷启动是指内存中无该小游戏的运行实例的情况下，启动小游戏的过程；热启动是指小游戏的运行实例在内存中还存在，只是暂时切换到了后台，这时用户再次触发小游戏回到前台的过程。

小游戏会在冷启动时检查小游戏的版本，如有新版本，在下载回本地后，下一次冷启动即可使用最新版。当然，我们也提供了 API可以供开发者决策在有版本可用时，是否需要强制更新：

运维

mp.weixin.qq.com管理端提供了发布、灰度发布、回滚、停服等能力，可以充分利用平台已有的能力。

特别提醒，小游戏有完善的后端监控，可以通过“运维中心”开启，比如脚本错误监控（脚本错误主要由运行过程中未捕获的异常触发，需要重点关注。该类异常，可能会导致用户小游戏前端的 js逻辑暂停执行）：

有赞电商小程序的实践

黎贝卡小程序店铺“首次上新 7分钟破百万”、“二次上新 59秒破百万”，这些傲人的成绩背后离不开有赞技术团队的保驾护航，有赞电商小程序负责人施德来现场与大家分享有赞在电商小程序的发展历史与现状，以及有赞在小程序技术上的积累。例如小程序组件库的开源、在微页面里如何将 H5与小程序合二为一以及有赞在开发过程中遇到的一些问题，如何利用官方解决方案进行最优处理等。

在小程序出现之前，做移动开发一般有两个模式：第一种是 web应用如 H5，一种是原生应用。这两种模式的特点都是很鲜明的，比如 H5这类应用无需安装、跨平台、易开发、传播性比较好，但页面简单，打开速度慢、Native能力差，用户体验一般。而原生 APP体验流程、功能齐全，但则需要安装，开发速度慢、更新麻烦，对开发的专业要求也比较高。

小程序结合了两者的优点，很多 H5里面需要高阶能力才能解决的问题，被小程序用降维的方式解决了，比如说 H5里面原先要做异步加载等系列优化措施，才能让 H5页面打开更快但小程序通过打包提交、提前下载、Native 和 Web 混合渲染的方式很低门槛地解决了这些问题。总的来说，小程序集合了开发简单、功能多、体验好等系列特点，是现今主流的移动应用。

有赞从 17年开始介入小程序开发，随着微信小程序功能与接口的逐步完善和更新，在 17年下半年时有赞集中发力，并在 18年开始爆发。

在功能上，有赞将原先 H5里面大量的核心能力全部搬到小程序，同时也做了小程序特有的能力。包括店铺、商品、订单、客户管理、数据，营销工具，营销渠道等等，这里面有些是参考的，有些是有赞首创的。

这里面的功能可以说是非常齐全的，商家可以根据自己的需求进行功能选择。同时，有赞也为海量小程序商家提供小程序技术服务，确保商家小程序正常上线运营。

如何同时产出海量独立的微商城小程序？

虽然代码是同一套，但每个商家的小程序都是独立名字的，独立提交审核的，版本也不同。作为平台开发者，微信是提供这种能力的，帮商家提交新版本小程序的时候，使用相同的模板 ID的同时，每个商家的小程序额外提交一份 ext.json，里面包含这个商家的小程序特有的东西，比如 appid、底部导航配置等。有赞把这两个信息提交给微信，微信开始审核这个小程序。

一套代码两个马甲

像有赞的公共版小程序和专享版小程序，他们之间有大量的公共业务代码，代码都在同一个仓库里，专享版是公共版的一个子集。公共版有一个专门的“app.json”，我们把它命名为 app-youzan.json，专享版对应的就是默认的 app.json。我们自己写了个 webpack的插件，会在开始编译代码前把 app.json里的内容 merge到 app-youzan.json，然后在后续的编译过程里，针对 app-youzan.json(公共版)和 app.json(专享版)分别打两次，以输出 2个版本。

体积来越大，马上就突破 2M了

17年 11月份就已经 1.4M了，眼看按这个趋势很快要到 2M，有赞尝试了用第三方工具 wxapp—webpack—plugin，在它基础上二次开发了下，只打包有用到的模块，合并重复的模块。如上图，12月份包的大小降了下去了，后来微信开放了分包的功能，有赞 4月份也简单尝试了一下，推荐大家用起来。

如何提高开发效率？

1. 推荐有赞开源的 ZanUI-Weapp 组件库（ https://github.com/youzan/zanui-weapp ），Star 已经 4k多了。

2. Zan Proxy（https://github.com/youzan/zan-proxy） 是我们开源的代理、Mock工具，功能比较全面，可以很方便地做到本地代码调试线上页面线上接口。如果你还在用 nginx做这个事情，可以试试 ZanProxy。

3. 前店后厂与商家共建产品的模式，快速迭代往前跑，减少中间环节。

如何提高稳定性？

有赞的方法就是体验版、稳定版机制。每 2个星期发一个新版本，在更新所有小程序前，会先让 100+小程序先升级到新版本，至少内测一个星期。这 100+小程序对应的商家就是我们的内测商家。

另外一种方法是利用好回滚、撤销审核接口，这部分是腾讯提供的能力，当有赞发现某一个版本有问题，可以把所有或者部分商家的小程序都回滚到上一个版本。