据微信团队7月10日在微信公开课上公布的数据，微信小游戏上线100天以来，已发布游戏超过2000款，广告收入突破1000万，各类开发者现已加入微信小游戏生态。
微信小游戏开发中会遇到什么样的问题和情况？微信公开课讲师许斌在《小游戏开发之道》中从社交玩法、性能优化、运行监控三个方面分享了自己制作小游戏的经验。
以下演讲内容由葡萄君整理发布：
作为一名小游戏开发的从业者，很高兴今天能够在这里跟大家分享一下我在小游戏开发方面的一些经验以及开发者们最关心的一些问题。
小游戏的社交玩法
（1）登录
用户登录是大家在开发游戏时遇到的第一个问题。登录和授权接口对于小游戏来说是两个不同的接口。开发者对这两个能力存在误解。下面我将和大家分享一些如何合理使用这两个接口的实际案例。
大家在玩游戏的时候应该对这个画面很熟悉，会看到这样的授权提示，没玩过游戏的用户可能会一头雾水，这是因为游戏开发商把登录界面和授权界面合在一起当做登录，尽管他可能只需要登录。
小游戏前端通过wx.login获取到code，并发送给小游戏服务器，小游戏服务器与微信服务器进行交互，获取用户的openid和session_key，小游戏服务器获取到这些之后就可以生成用户的login ticket，并传输给小游戏前端，这样就完成了用户的登录。
登录之后我们开发者可以存储玩家的一些游戏信息，包括玩家的等级或者角色信息。一是当玩家误删游戏的时候，可以保证玩家重新下载或者换设备之后可以继续玩。二是可以完成道具支付的功能。
（2）授权
在小游戏中，有些还是需要用户授权的。我们发现世界排行、好友对战等都需要使用用户头像，而这些是微信平台上的用户隐私。当我们的游戏需要访问用户隐私信息时，用户需要进行授权确认，但我们发现这款游戏的核心使用方式并不需要使用用户头像。
开发者需要合理分析游戏模块和场景，如果在需要玩家头像昵称的时候调用授权，用户可能会担心自己的隐私被泄露而拒绝授权。那么如何优雅地处理用户拒绝授权的情况呢？比如提供更好的解释让用户相信在玩游戏之前必须授权自己的隐私信息，或者给用户一个游客登录的模式来体验游戏。
（3）关系链数据
我们可以增加一些超越好友、好友排行榜、群排行榜等玩法，让用户之间可以互动、可以比较，还有一个玩法可以让玩家之间的互动更加激烈，但是关系链数据的安全性非常重要，我们开放关系链数据的背后是什么样的思考和设计？
在设计时，我们将游戏的主场景称为主域，关系链数据所在的地方称为开放数据域。两个域相互隔离，具备单向通信能力。主域可以通过postMessage将玩家的成绩传递给开放数据域，这些数据可以存储在微信后台。开发者可以拿到好友的关系链和管理数据来绘制一个场景，包括好友排行榜等。排行榜会绘制到离屏的sharedCanvas上，离屏canvas通过绘制接口绘制到游戏的主场景上。这样的设计在数据开放的同时，保证了关系链数据的安全性。
用《星途》小游戏的例子来说明，其他玩家可以通过对话点进来挑战我。这个场景的具体实现是怎样的呢？游戏前端调用后端接口创建房间ID，通过微信小游戏分享接口，我们可以把自己的房间放到微信对话里游戏开发，其他好友就会通过我分享的对话加入进来玩游戏。当然，为了分享，卡牌信息的内容需要更丰富一些。
我们可以自定义分享界面，设置卡片的内容，可以是静态的图片，也可以用canvas绘制和游戏或者用户相关的内容，让我们的卡片内容更加吸引人，吸引新用户点进来。另外我们也在规划增加动态卡片消息的功能，丰富小游戏的使用场景。
小游戏的玩法是邀请好友到一个房间玩，也有玩家想和陌生人一起玩游戏。
我们也做了一些尝试，比如在这个问答小游戏中，玩家可以和陌生人进行匹配，把他们两人放在一个房间里，进行互动问答游戏。那么这个匹配功能的具体实现是怎样的呢？
我们的游戏前端可以向我们的游戏后端发起匹配请求，我们的游戏后端可以根据等级，段位等提出匹配要求。匹配成功之后，可以将用户添加到一个房间，用户可以在这个房间进行一些互动。这个互动依赖于回合消息的同步服务。为了保证消息的时效性，实现更好的游戏体验，可以使用平台提供的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.小游戏正式上线后可以做哪些监控？
未来我们还会提供更多的能力和服务给开发者使用，进一步降低小游戏开发门槛，提高开发者的开发效率。包括我们即将开放的提示语音能力、真机调试能力等，进一步优化开发者的开发体验，敬请期待。我的分享到此结束，谢谢！
