这其实是一篇个人的2018年度总结。
整个2018年我基本都投身到小游戏的开发制作当中，游戏先后上线了 微信小游戏 ， QQ空间小游戏 ，同时预开发了 厘米游戏 版本。所以这篇总结我会站在开发的角度谈一谈在这三个平台开发的经验，以及趟过的坑。
上述的三个平台分别对应微信平台，QQ空间平台，手Q平台，对于详细介绍这里就不累述了，相信网上的很多文章肯定比我介绍的好。
小游戏C/S连接
这里谈的是客户端与开发者（自建）服务器的网络连接，三个平台都可以采用WSS连接方式，即在TLS之上的Websocket。
所以整个接入层方案可以做成统一的，具体实现可以采用：Nginx作Https解析代理，然后转发Websocket到自定义的接入服务。
优点是：
- 不用重新造WSS解析的轮子；
- Nginx可以方便的对域名、证书进行管理，并支持热加载和负载均衡；
缺点是：
- 对于延迟敏感的游戏有一定影响，毕竟网络包多传递了两次；
客户端资源存放
小游戏的客户端包一般分为二部分：一部分是编译后的打包包体（主要是代码逻辑、部分配置）、另外一部分就是各种素材资源（UI、动画、配置等）。
三个平台对资源的管理方案如下：
| 打包资源 | 素材资源 | |
| 微信小游戏 | 上传平台 | 自建CDN |
| QQ空间小游戏 | 自建CDN | 自建CDN |
| 厘米游戏 | 上传平台 | 自建CDN |
QQ空间小游戏比较特别，所有资源都是自己管理，担心页面并发大服务器撑不住可以采用CDN+COS（腾讯云COS、阿里云OSS）静态网站的方式，让用户直接通过CDN访问你的游戏，将页面负载的压力交给第三方。微信小游戏和厘米游戏则不用担心这个问题，平台都帮你处理好了。
微信小游戏有8M上传包的限制，厘米游戏是10M。如果你的游戏比较大、资源比较多，那么8/10M肯定是不够用的，可以把资源放入CDN。
小游戏登录鉴权
- 微信小游戏鉴权（Api：code2Session）是根据客户端code码，传递到服务端，服务端根据code和其他信息换取open_id与session_key，若能成功换回则登录有效；
- QQ空间小游戏（Api：/v3/user/is_login）和厘米游戏（Api：apollo_verify_openid_openkey）是客户端直接持有open_id，open_key，服务端去验证是否登录；
注意点：
微信小游戏的code码有效期，官方给的说明是：属性code，用户登录凭证（有效期五分钟）。开发者需要在开发者服务器后台调用 code2Session，使用 code 换取 openid 和 session_key 等信息。
在实际使用中，如果每次登录/重连，客户端都获取新的code，服务端调用code2Session会有小概率失败（无效的code）。失败流程都是走官方登录文档流程：客户端获取code，服务端校验，并且参数传递正确，至于为何出错失败官方未给出有意义的提示。
那么怎么解决？
微信小游戏还提供了一个接口checkSessionKey（客户端和服务端都有，但是在登录文档里未提及）
官方说明是：校验服务器所保存的登录态 session_key 是否合法。为了保持 session_key 私密性，接口不明文传输 session_key，而是通过校验登录态签名完成。
我们可以利用这个接口进行容错检查：
这里对code进行了double check， 主要是因为在客户端checkSession通过后，服务端仍有小概率会失败 ，所以为了进一步容错，右侧图多加了一个客户端过期更新流程。
小游戏核心逻辑
社交关系与排行
三个平台社交关系实现如下：
| 平台支持 | 数据上报 | 数据拉取 | |
| 微信小游戏 | 是 | 客户端 | 客户端 |
| QQ空间小游戏 | 是 | 服务器 | 服务器 |
| 厘米游戏 | 是 | 客户端 | 客户端 |
值得注意的是微信小游戏有 开放数据域 的概念，这个域和主游戏完全隔离，意思就是里面的数据不可能对其取出二次加工。
每个平台对社交榜单的种类有限制，如果需要世界榜，需要开发者服务器自行支持。
支付
三个平台支付方式相似，都是通过客户端拉起支付界面进行RMB支付换取游戏币。
不同的是，我以游戏中钻石（游戏币）为例：
- 微信小游戏和厘米游戏平台支持托管钻石数据；QQ空间小游戏托管的是星币/秀币（全局性游戏代币，在其平台上的每个游戏通用），开发者需要用自己的逻辑把星币/秀币再换成钻石。
- 微信小游戏和厘米游戏有接口支持支付回滚； QQ空间小游戏不支持支付回滚： 星币/秀币一旦换成钻石，这个就是不可逆的，这点需要特别注意。
微信的getAccessToken
access_token是微信特有的一个变量：
官方说明是：获取小程序全局唯一后台接口调用凭据（access_token）。 调调用绝大多数后台接口时都需使用 access_token，开发者需要进行妥善保存。
它会引发二个问题：
- 游戏开发一般会分为开发/测试环境，正式环境；不同环境间怎么共享一个access_token？
- access_token出问题怎么办，过期？平台侧异常？
首先解决第一个问题： 需要一个全局拉取access_token的模块 ，由正式环境负责与微信接口服务交互，拉取成功后落日志，开发/测试环境通过脚本把日志拉取到本地读取有效信息。模块功能与微信接口交互还是读取文件可以通过环境配置来实现。其他需要使用access_token的模块可以定期（30秒）去向全局拉取access_token模块同步一次access_token。
第二个问题比较麻烦，现在微信接口返回的expire_in=7200秒。在开始的使用中我们平均1小时主动刷新一次，但是发现偶尔会“提前过期”，于是乎把更新时间缩短到了15分钟，发现还是会偶尔“提前过期”。自身确认过逻辑，找不到原因（没有其他地方调用过接口导致提前过期），在社区寻求帮助也没有有效回复。 所以这里加了一层容错：在微信接口返回过期提示时，主动告诉全局拉取access_token模块触发更新，能够做到微信那边出了异常也能自动的进行容错。
当然这里做的好一点可以再加一个下发机制：由全局拉取access_token模块下发最新的access_token。
总结
总的来说三个平台对小游戏的接入大体相同，细节不同：
- 从微信小游戏来看，他们更注重用户数据的保护，利用开放数据域保护用户和社交的私有数据，游戏作弊成本会比较高；
- QQ空间小游戏则有些类似传统页游的做法，客户端不可信，绝大部分用户和社交信息通过开发者服务器拉取，支持PC web端直接访问，游戏作弊成本比较低；
- 厘米游戏则有点像微信小游戏和QQ空间小游戏的结合，一些地方像微信做法，一些地方像QQ空间的做法；
因为平台历史、文化、产品/技术侧重点等原因导致平台间存在差异，我们不好说孰好孰坏，比如微信小游戏更注重隐私，数据安全和程序安全，会限制开发方的部分想法；QQ空间小游戏则比较粗放，社交好友的数据你都可以直接取到，任意进行二次加工，对开发方想法限制会较少。
所以一切都是权衡，不仅仅体现在程序开发上经典思想 – 空间换时间，也体现在产品/平台属性 – 自由度与隐私的权衡，更体现在生活 – 过年怎么探亲访友：D。
最后，祝2019一切安好。
（全文结束）
转载文章请注明出处：漫漫路 - lanindex.com