从7月10日微信团队在微信公开课中公布的数据看出，微信小游戏在其公布的100天中已发布了超过2000款游戏，广告流水超千万。各路开发者们现已陆续加入到微信小游戏的生态之中。

在微信小游戏开发中会遇到什么样的问题和情况，微信公开课讲师许斌在“小游戏开发之道”中分别从社交玩法、性能优化和运营监控三个方面分享了制作小游戏的经验。

以下演讲内容经葡萄君整理发布：

作为小游戏开发的实践者，今天很高兴站在这里和大家分享一些小游戏开发的经验和开发者比较关注的一些问题。

小游戏的社交玩法

（1）登录

用户登录是大家在开发游戏时普遍遇到的第一个问题。登录与授权接口是小游戏的两个不同接口，开发者对这两个能力存在误解，我会结合一些实际的案例和大家分享一下，怎么样合理使用这两个接口。

大家玩游戏的时候对这个图片应该不陌生，会看到这么一个授权的提示，没有玩过的用户会一脸懵逼。这就是游戏开发者把登录接口与授权接口一起当成登录使用，尽管他可能需要的只是登录。

小游戏的前端通过wx.login获取code，发送给小游戏的服务端，小游戏的服务端和微信的服务端做一个交换，拿到用户的openid和session_key，等到这些拿到了以后，小游戏的服务端就可以生成用户的登录票据，传输给小游戏的前端，就完成了用户登录。

登录之后，我们开发者可以存储玩家的一些游戏信息，包括玩家的关卡或者角色信息。首先当玩家不小心删了游戏，可以保证玩家重新下载或者换了一个设备后仍然可以继续玩，第二点就是可以完成支付购买道具的能力。

（2）授权

在小游戏中，有些游戏还是需要用户授权。我们发现它的一个世界排行和好友对战需要用到用户的头像，在微信平台这是属于用户的隐私，当我们的游戏需要拿用户的隐私信息的时候，需要用户做一个授权确认，但我们发现这个游戏的核心用法是不需要用到用户的头像的。

开发者需要合理的分析游戏的模块和场景，如果在需要用到玩家头像昵称的时候再调用授权，可能用户会担心他的隐私会遭到泄露而拒绝授权。那么怎么优雅的处理用户拒绝授权呢？比如说提供一个更好的说明来说服用户必须授权他的隐私信息才能玩游戏，或者是给用户一个游客登录的模式来体验游戏。

（3）关系链数据

我们可以加入一些超越好友、好友排行、群排行的玩法，让我们的用户之间有一个互动和攀比，还有一种游戏玩法可以让玩家之间的互动更加强烈一点，然而关系链数据的安全性非常的重要，我们开放关系链数据的背后是怎样做一个思考和设计的？

在设计时，我们把游戏的主场景叫做主域，关系链数据所在的地方叫开放数据域。两个域是相互隔离的，具备单向通信能力。主域可以通过postMessage把玩家的分数传给开放数据域，这个数据可以存储到微信的后台，开发者可以拿到好友的关系链以及托管数据进行一个场景的绘制，包括好友排行榜等，排行榜会被绘制到一个离屏的sharedCanvas上，通过绘制接口把离屏canvas绘制到游戏的主场景。这样的设计，保证关系链数据的安全性，同时又可以做到数据开放。

结合《星途》小游戏中的例子来说明，其他的玩家通过会话点进来，就可以对我进行一个挑战，这种场景的具体的实现是怎么样的呢，游戏的前端，调用后端的接口创建一个房间的ID，通过微信的小游戏分享接口，可以把我们的房间微信的会话中，其他的好友通过我分享的会话，就会加入到一起来玩这个游戏了，当然为了分享出去，卡片消息的内容需要更加丰富。

我们可以通过自定义分享接口，设置卡片的内容，它可以是一个静态的图片，也可以利用canvas绘制和游戏、用户相关的内容，让我们的卡片的内容更具有吸引力，吸引新用户可以点进来。除此之外我们还在规划动态卡片消息的能力，丰富小游戏的使用场景。

小游戏的开房间玩法是把我们的好友拉到一个房间里来玩，也有玩家希望和陌生人一起玩游戏。

那我们也做了一个尝试，比如说这一款小游戏答题类的，玩家可以和陌生人进行一个匹配，把他们两个人匹配到一个房间里，做一个互动的答题PK，那么这个匹配功能的具体实现是什么？

我们的游戏前端可以发起一个匹配的请求到我们的游戏的后台，我们的游戏的后台可以根据等级，段位等做一个匹配的需求。匹配成功之后，就可以把用户加入到一个房间里面，用户就可以在这个房间里面有一些互动，这种互动就依赖回合消息的同步服务，为了保证消息的及时性并达到比较好的游戏体验，可以使用平台提供的websocket协议。

在实现的过程中，我们发现匹配服务和同步服务，和游戏的业务并没有太强烈的关系，所以我们可以把中间的这一块独立出来，专门的做一块匹配和同步的系统。我们在开发下一款小游戏的时候，我们的游戏前端只需关心输入和输出，后台关心业务逻辑，就不需要再去处理匹配和同步的逻辑。

小游戏的性能优化

（1）小游戏分包

开发者在开发游戏过程中常常反馈由于内容太多了，4M完全不够用，为了满足开发者的诉求，我们把代码包从4M提升到了8M，以便开发者们丰富游戏的内容的玩法。但是还有一点，因为我们并不是把主包直接升为8M，我们还是保持主包的4M上限不变，而总的上限是8M,不过我们支持了分包能力。

有了分包能力意味着我们的小游戏具备按需加载代码的能力，可以加快游戏的呈现速度。怎么加快游戏呈现速度呢？我们可以先来看一个对比，我们的代码包有4M的时候，下载的时间需要五秒以上，我们的代码包1M的时候，下载的时候只要1.5秒左右，用户进入游戏的等待时间等于代码包的下载时间，以及代码引擎解析代码的时间，这两块的时间是和代码包的大小是成正比的。

所以为了我们的游戏能够更快的打开，开发者可以做以下的几点优化：

1、保证主包尽量的小；

2、根据游戏业务的场景，比如说游戏中有一些商店、任务的模块、或是开房间的模块，根据这些模块把代码包配置成多个子包；

3、做到按需加载；

经过以上三点优化，就可以大大的减少用户进入游戏的等待时间。

（2）小游戏内存

开发者除了要关注游戏的打开速度，还要关注一下内存优化。

eg1：我们在绘制好友排行榜的时候，如果有上千个好友，我们把上千个好友的结点绘制出来，会导致比较高的内存的消耗。

eg2：在《星途》小游戏中，随着飞船前进，星球、轨道也是不断创建的，如果不断的创建和销毁这些轨道，也会带来不必要的消耗，所以要合理的利用对象缓存池，避免带来不必要的消耗。

1、内存释放：随着游戏的场景越来越多，内容越来越复杂，对内存的诉求会越来越高，所以有的游戏会有一个比较高的内存占用，但是在微信的这个平台下，不能做到一个小游戏无限制的使用内存，所以要关注小游戏的内存状态，在实际的应用中，开发者可以利用内存告警接口及时知道自己小游戏是不是已经快要达到一个比较高的值了，如果内存过高，游戏可能会被清退，所以要用垃圾回收的接口，及时的触发垃圾回收的时机，主动的回收内存。

2、图片压缩：在小游戏中图片资源是用的比较多的资源，针对图片的渲染优化，我们可以做哪一些优化呢？在《星途》小游戏中，我们在保证图片清晰度可接受的情况下，尽量压缩图片，以及将游戏中的一些碎小的图片合成大图，3、分景加载：因为我们的游戏场景非常的多，不需要集中的加载大量图片而是分场景加载。用户下载图片的资源成本也会降低，我们游戏中的渲染批次也会下降到比较合理的值，这个值越小，说明我们的游戏会更顺畅。

《星途》小游戏正式上线后，我们统计了用户的机型占比的情况，中低端机的占比还不少，低端机的内存比较小，CPU的运行性能也比较差，那我们可以做以下的三点降级的优化：

第一个是去掉一些非必要的动画特效；

第二点进一步降低图片的清晰度减少内存占用；

第三点简化一些复杂的逻辑计算，比如碰撞检测；

小游戏的运营监控

我们可以从三个方面来讲：一个是代码层面，一个是用户反馈的层面，以及一个客服组件。

1、代码：开发者可以实时的接收到小游戏报错的日志，以及我们平台的接口调用异常也可以被监控到。除此之外，开发者还可以自定义设置一些监控，比如游戏的登录模块由于用户的涌入而挂了，通过手机的预警，开发者及时发现问题并修复，保证给用户提供很好的游戏体验。

2、用户反馈：除了代码和接口之外，我们还提供了用户反馈的渠道，开发者可以在我们的平台上获取用户的反馈建议，我们提供了游戏圈组件，供开发者在游戏中接入，可以给玩家提供互动的社区，同时开发者收集到玩家的一些建议。

3、客服组件：通过组件可以让我们的开发者和用户做一个实时的一对一的沟通，通过以上的三个点，我们可以搜集到用户的反馈，持续帮助开发者改善游戏的表现。

总结

今天主要说了三个点：

1、借助小游戏的能力，怎么样给我们的游戏加入一些社交玩法？

2、在小游戏的性能优化方面有哪些方向？

3、还有等小游戏正式上线之后，又可以做哪些监控？

未来我们还会提供更多的能力和服务，供开发者使用，进一步降低小游戏的开发门槛，提高开发者的开发效率。包括我们即将要开放的提示语音能力，以及真机调试的能力，进一步优化开发者的开发体验，大家敬请期待，我的分享就到这里，谢谢！