随着接入我们SDK的微信小游戏种类越来越多，遇到的问题也层出不穷，故写下此文，作为以往经验总结。

附上微信小游戏开发在线文档传送门：https://developers.weixin.qq.com/minigame/dev/api/base/system/wx.getSystemInfoSync.html

接下来我们围绕这些微信API做一次梳理

JS版本，微信提供了wx.request方法用于网络请求，此请求方法用以下注意点：

1、域名只支持 https 协议，域名必须经过 ICP 备案，服务器域名请在 「小程序后台-开发-开发设置-服务器域名」 中进行配置。

2、域名不能使用 IP 地址（小程序的局域网 IP 除外）或 localhost

3、对于 https 域名，可以配置端口，如 https://myserver.com:8080，但是配置后只能向 https://myserver.com:8080 发起请求。如果向 https://myserver.com、https://myserver.com:9091 等 URL 请求则会失败。如果不配置端口。如 https://myserver.com，那么请求的 URL 中也不能包含端口，甚至是默认的 443 端口也不可以。如果向 https://myserver.com:443 请求则会失败

4、对于 POST 方法且 header['content-type'] 为 application/x-www-form-urlencoded 的数据，会将数据转换成 query string （encodeURIComponent(k)=encodeURIComponent(v)&encodeURIComponent(k)=encodeURIComponent(v)...）

5、不支持配置父域名，使用子域名使用限制

6、使用限制

• 默认超时时间是 60s；

• wx.request、wx.uploadFile、wx.downloadFile 的最大并发限制是 10 个，超出部分会在队列中，依次进行执行。

• 小程序进入后台运行后，如果 5s 内网络请求没有结束，会回调错误信息 fail interrupted；在回到前台之前，网络请求接口调用都会无法调用。

SDK遇到的坑：

最近遇到的一个坑点就是：wx.request的最大并发限制是10个。

由于研发在加载游戏资源时，一瞬间发出近20个网络请求，而且每次请求的耗时都很长，当用户退出小游戏时，我们SDK质量上报“SDK登录成功”的请求还在请求队列中，还没上报。造成数据漏斗显示转化率异常，正常（图2）是95%，这次转化（图1）只有63.94%；

用下图时间轴来表示这次“SDK登录成功”请求丢失的流程

优化方案：

1、建议研发合并资源请求，减少请求资源加载并发量，同时提升接口响应速度，减少用户登录时间。

2、调整“SDK登录成功”的请求执行时机，避免资源请求并发过多，造成“SDK登录成功”的质量上报请求丢失。

unity微信小游戏，如果用C#开发，则不能使用wx.request方法（JS专用），需要自行实现https网络请求方法，下图是unity微信小游戏的network截图，即使不使用wx.request方法，微信开发者工具对https的请求并发量会进行控制，超出的请求量，会在请求队列中逐步处理。

wx.getLaunchOptionsSync()获取小游戏冷启动时的参数。

SDK只关注在冷启动时获取query属性，里面有投放同事生成的投放广告链接参数，我们SDK获取query属性里面的值后，都会透传至“数据部同事”进行数据归因，因此，SDK透传数据时候，需要保障。

1、数据不会因长度问题被截断（使用post请求）

2、上报的数据不存在编码问题，后端接口能正常解析。

SDK遇到的坑:

由于投放同事使用的投放平台各不相同，因此我们query对象的值，无法枚举，这次遇到比较棘手的问题是，从推广链接进游，数据部收到的referer字段与质量上报的referer不一致。本次推广的小游戏是用unity引擎C#语法开发的，经过近2个多小时的排查，最终把目光锁定在JS小游戏和unity小游戏的网络请求对比上。

可以看到，能够被后端接口正常解析的报文，是用"mid5"包裹字段传输的，而异常报文，则使用"\x22"包裹字段传输，导致后端无法正常解析字符串。

核心原因：

JS-api对于 POST 方法且 header['content-type'] 为 application/x-www-form-urlencoded 的数据，会将数据转换成 query string （encodeURIComponent(k)=encodeURIComponent(v)&encodeURIComponent(k)=encodeURIComponent(v)...）

unity C# 由于自行实现网络请求，则不会对每个请求字段都进行url编码

解决方案：

改造unity的网络post请求方法， header['content-type'] 为 application/x-www-form-urlencoded 的数据，进行url编码

由于微信侧已经停止维护wx.getSystemInfoSync方法，拆分成多个API进行系统参数获取，因此，我们SDK文件，未来也需要做wx.getSystemInfoSync方法的兼容处理，以下是改造升级的示例代码

SDK遇到的坑:

1、wx.getSystemInfoSync方法本身有返回空对象的偶发问题，如果进一步访问空对象属性里的属性，例如访问空对象.a.b属性，就会出现js代码报错，因此，我们SDK内部会使用 try-catch进行兼容处理

2、未来wx.getSystemInfoSync方法改造，也会出现其他方法不存在的情况，我们前端代码需要做好兼容处理。

wx.showShareMenu设置右上角点开的详情界面中的分享按钮是否可用

SDK遇到的坑:

1、微信官方提供的unity C# 转js小游戏的unity插件,里面展示分享按钮的逻辑，与我们SDK冲突，导致SDK未拿到分享图信息，已经提前激活用户的分享按钮，对话框造成分享图加载黑屏。

解决方法：unity的SDK在完成分享信息注册前，禁止用户分享，图二为SDK加载中，用户无法分享，图三为SDK注册分享消息后，用户可使用分享功能，总体等待时间，1秒内。

wx.onShareAppMessage 监听用户点击右上角菜单的「转发」按钮时触发的事件

当用户手动点击右上角「转发」按钮时，SDK再发出网络请求，拉取当前小游戏的分享信息，以promise的形式返回给微信小游戏，达到分享图文由运营在后台编辑，SDK无需实时更新的效果。

同时，为了防止出现请求分享图文接口超出3秒的场景，SDK会内置一个兜底的分享图文，保证分享图文不会出现，当前游戏截图的画面。

SDK遇到的坑:

1、请求当前小游戏的分享信息后，SDK内部会根据分享图片链接，发送一个head请求，校验图片正常响应（响应状态码为200代表正常），由于没有将图片地址的域名添加到mp后台的服务器域名白名单内，导致请求被拦截，用户只能看到兜底图文。

wx.shareAppMessage  主动拉起转发，进入选择通讯录界面

针对游戏研发侧，有精细化分享的场景，SDK也提供了share方法，让研发传入自定义的分享参数，满足游戏内，点击不同分享按钮，生成不同的分享图文。

SDK遇到的坑：

1、对于研发传入的自定义分享参数，为了防止用户点击分享卡片进游后，由于编码问题，导致分享数据丢失，SDK内部在生成query参数时，会对所有字段值进行url编码处理。

wx.showModal 显示模态对话框

SDK内部使用“模态对话框”的场景，大部分是接口返回异常状态码，用作“温馨提示”。

在SDK以外的场景，特别是提示玩家，进行版本强更时wx.showModal就很重要了，特别是showCancel参数，最好设置为false，保证不显示取消按钮,，让玩家更新为最新的游戏版本。

以下是之前调研部分微信小游戏的强更提醒弹窗（以下截图，仅代表当时版本，真实效果，以当前游戏最新版本效果为准）

wx.showToast  显示消息提示框

SDK当前使用wx.showToast的场景，在用户支付异常时，用作弹窗处理

1、微信小游戏SDK前端遇到的大部分异常场景，主要是网络请求（请求阻塞，请求丢失）和url编码问题

2、JS开发的小游戏(laya,cocos)和C#开发的unity小游戏，底层使用的api也会有差异，因此，我们的SDK当前是维护 JS-SDK和C#-SDK 两套。

遇到异常问题，除了聚焦解决问题外，还需要培养定时群里同步解决问题进度的习惯，小游戏SDK是整个游戏上线的其中一个环节，后续还有游戏推广，游戏投放数据归因等环节，因此，如果小游戏SDK问题无法及时解决，必须立即同步给大家，商量是否调整上线时间，保障各个部门按计划，顺利地做好每个小游戏的发行工作。

END