在微信小程序/小游戏的开发中，网络传输主要是依靠http的短连接和webSocket 长连接来完成的。 在一般web服务中，大多使用短连接来向服务器请求资源，与服务器的交互频率低，次数少。而在一些需要与服务器交互频繁，需要及时收到服务器推送的场景，比如直播、多人实时游戏，更适合使用 webSocket 进行通讯。 这次的小故事主要分享 webSocket 在微信小程序/小游戏开发上的一些经验。 长连的生命周期介绍 webSocket的生命周期一共有4个状态：connecting、open、closing、closed。我们可以通过 socketTask 的 readyState 属性来获取当前 webSocket 长连的状态。webSocket 的生命周期过程和 API 间的调用关系可以简单的入下图所示。 [图片] 注意：只有长连处在 open 状态，才能够正常的收发消息，其他状态均会报错。 客户端长连的断开机制 当小游戏进入到后台运行超过5秒时，客户端会禁止小游戏的所有网络连接。这是一个非常频繁的断线逻辑，十分考验程序断线错误处理逻辑。建议大家可以在用户点击右上角按钮退出小程序/小游戏时，主动帮用户断线，待用户切回时再重接上去。   当 webSocket 长连超过一段时间没有任何网络传输时，客户端会主动关闭这条长连，以节省资源。开发者可以设置业务心跳，每隔一段时间与后台进行一次通讯，维持长连。 如何选择长连的接口 API接口主要有两类，一类是前缀为 “wx” 的接口，一类 “socketTask” 的接口。举例，同样是连接长连后发送一条消息，两种写法区别如下。 [图片] 最初小游戏只允许存在1个 webSocket 连接时，并没开放 socketTask 的管理方式。随着小游戏的能力提升，可支持同时存在的 webSocket 连接个数变多，在使用 wx.connectSocket 创建 webSocket 连接时会返回 socketTask 任务对象，便于去管理每一条连接链路。   推荐开发者尽量使用 socketTask 的方式去管理 webSocket 链接，每一条链路的生命周期都更加可控。同时存在多个 webSocket 的链接的情况下使用 wx 前缀的方法可能会带来一些和预期不一致的情况。例如：当存在多条连接时，wx.onSocketOpen、wx.sendSocketMessage、wx.onSocketMessage 等接口会只作用于第一条连接的长连。且wx.onSocketOpen 接口不能多次注册 webSocket 长连的回调函数，仅最后一次生效。使用 socketTask 任务的方式则不会出现上述问题。 开发与调试的建议 01微信提供了 webSocket 最基础的接口能力，开发者可以在其基础上进行封装，根据业务需要扩展能力。比如封装一个 offSocketOpen 的方法来取消注册 socketOpen 的回调函数。 02 长连并没有像短连那样“一问一答”的交互形式。在某些场景下，开发者需要这种与服务器的交互。建议前端与后台协议，每条客户端上行的信息，服务器都下发一个对应的回包，去“模拟短连”。比如开发者向服务器询问1+1和1+2等于多少，服务器返回了3和2，便可清晰知道哪一个数字对应着哪一个请求的答案。此外，还可以设置业务超时逻辑，便于判断上传是否丢包 03 在 webSocket 发送数据时，数据格式可以选择string或者ArrayBuffer。这里要注意的是，由于小游戏禁止了 Function() 和 eval()语法。所以像 protobufjs 这类用了这些语法的库是不能直接拿来用的。 04 在测试调试长连的时，目前开发者工具不支持通过设置 offline 模拟长连断网的情况（短连是支持的），所以在测试断线重连的一些情况时，可以辅助一些第三方工具，或者用真机调试以及“拔网线”的方式来测试。 05 在进行多人游戏测试时，在开发者工具中熟练使用“自定义编译条件”，以及“多账号调试”这两个功能可以极大的提升开发测试效率。 06 长连占用的系统资源，会导致手机发热比较明显。所以在不需要使用 webSocket 的场景下，建议及早断开长连，需要时再连接。 异常断线的监控 监控长连是否异常断线，在长连的使用中，尤其在小游戏多人对战中是尤为重要的。socketError 事件并不能认为是异常断线。 首先 socketError 事件并不一定会导致断线，其次若是由客户端机制断开的长连，是不会触发 socketError 事件的。   最简单的方式可以通过 onClose 回调函数触发时系统传入的 code 是否为1000来判断。当然开发者自身也可以通过代码判断是否是自身调用的 close 函数触发的 onclose 事件，监控异常断线。 希望大家在实际应用中能帮助到到大家。

在「小程序 · 小故事」的第一期，我们曾和大家一起分享过「分包加载」的故事。随着小程序功能越来越多样，页面也越来越多，但不同页面的访问频率是有一定差异的。 分包加载允许开发者将小程序划分为主包和若干个分包，将较少用到的页面或功能划分到若干个分包中，主包内只保留最频繁使用的页面和公共的代码。小程序启动时默认只加载主包，再按需加载分包。这一机制保证了在小程序包大小增加的情况下，依然能保持良好的启动速度。 为满足小程序承载的功能不断丰富的需要，小程序的代码包大小上限已提高到 8M。随着小程序应用场景和使用范围的扩大，在实践中，我们发现分包加载仍有一定的局限性。尤其是越来越多的 H5 服务迁移到小程序后，对于小程序的启动速度有更高要求。为了更好的提升小程序的加载速度和使用体验，小程序近期开放了「独立分包」和「分包预下载」两个新的能力，进一步丰富了分包加载的功能和使用场景。 01独立分包 1  技术背景 由于技术实现的差异，小程序首次启动时需要进行代码包的下载，因此在启动性能上与网页相比有一定劣势。通过对小程序启动耗时的分析，我们发现代码包大小对小程序启动速度是有最直接的影响。 一方面，代码包越大，下载时间就越长； 另一方面，代码包越大，通常意味着小程序页面结构和代码逻辑复杂，启动时代码注入执行的时间越长。 采用分包加载一定程度上解决了代码包下载耗时过长的问题。但小程序中的某些场景（如广告页、活动页、支付页等），通常功能不是很复杂且相对独立，对启动性能有很高的要求。在现有方案中，启动这一页面需要依赖整个主包的下载，如果页面在分包中，还需等待分包的下载，启动性能有严重的瓶颈。此时如果依赖开发者进行代码重构，重新分包，不仅工作量大，而且会影响其他分包的使用体验。为了解决这一问题，我们提出了「独立分包」方案。 2  功能简介 独立分包是小程序中一种特殊类型的分包，可以独立于主包和其他分包运行。从独立分包中页面进入小程序时，不需要下载主包。当用户进入普通分包或主包内页面时，主包才会被下载。 开发者可以将部分对启动性能要求很高的页面放到特殊的独立分包中。当小程序从独立分包页面启动时，只需要下载分包就可以直接运行，可以很大程度上提高分包页面的启动速度，实现小程序的秒开。 [图片] 由于小游戏中没有页面的概念，也没有小程序中多种入口的使用场景，因此小游戏目前没有支持独立分包。 3  配置方法 独立分包的配置方法十分简单，只需要在原有分包配置的基础上定义 independent 字段，即可将一个分包设置为独立分包，例如： [图片] 4  使用限制 独立分包虽然属于分包的一种，但其不依赖主包独立使用，因此在加载流程和运行环境上与普通分包相比有一些差异。除了分包本身的限制外，独立分包还有以下限制： ● 独立分包中不能依赖主包和其他分包中的内容，包括 js 文件、模板、wxss、自定义组件等； ● App 只能在主包内定义，独立分包中不能定义 App，会造成无法预期的行为； ●  独立分包中暂时不支持使用插件。 为了小程序有更好的使用体验，我们不建议开发者把过多的小程序逻辑放置到独立分包中，也不建议在小程序中过度的使用独立分包，例如把每个页面都放到一个独立分包中。 关于独立分包的详细内容请参见 独立分包 · 小程序 02 分包预下载 1  技术背景 在使用「分包加载」后，虽然能够显著提升小程序的启动速度，但是当用户在使用小程序过程中跳转到分包内页面时，需要等待分包下载完成后才能进入页面，造成页面切换的延迟，影响小程序的使用体验。分包预下载便是为了解决首次进入分包页面时的延迟问题而设计的。如果能够在用户进入分包页面之前就预先将分包下载完毕，那么进入分包页面的延迟就能够尽可能降低。 此前，小游戏中已经提供了「基于API」的分包预下载能力。在设计小程序分包预下载能力时，我们设计了「基于配置」和「基于API」两种分包预下载形式，「基于配置」的方式使用简单，且便于对预下载的使用情况进行控制，防止开发者滥用；「基于API」的方式使用起来更灵活，能够动态的调整预下载策略。综合考虑用户的使用感受和内测阶段第三方开发者的反馈后，我们最终决定首先推出「基于配置」的分包预下载能力。 2  功能简介 开发者可以预先配置某个页面可能会跳转到的分包（对于独立分包，也可以预下载主包），在进入小程序某个页面时，由基础库在后台自动预下载可能需要的分包。用户在进行页面跳转时，分包通常已经下载完成，不需要额外等待，可以有效提升进入后续分包页面时的启动速度。此外，考虑到用户的流量和存储空间，小程序也会对预下载的大小和网络进行一定的限制。 [图片] 3  配置方法 开发者可以通过在 app.json 中增加 preloadRule 字段，控制进入某个页面时进行预下载的分包，并设置触发预下载的网络环境。 [图片] [图片] 4  使用限制 对于手机用户而言，数据流量和存储空间是非常重要的资源。一方面，分包预下载能够提升小程序用户的使用体验；另一方面，过度的预下载也会破坏分包按需使用的原则，过度的占用用户的存储空间，消耗数据流量。如果开发者每次启动小程序时都将所有分包进行下载，会消耗很多不必要的流量和存储空间。 为了在分包预下载的效果和对用户资源的消耗上取得平衡，我们限制了同一个分包中的页面预下载总大小不得超过2M，并鼓励开发者按需设置分包预下载的网络条件。 关于独分包预下载详细内容请参见 分包预下载 · 小程序 03 小结 独立分包与分包预下载进一步丰富了分包加载的功能，大大拓展了分包加载的使用场景。同时，独立分包和分包预下载是相辅相成的，配合使用可以获得更好的效果。 例如，开发者可以将一个活动推广页放到一个独立分包中，利用独立分包的特性能够提升活动页面的加载速度，提升转化率。在页面中开发者可以引导有需要的用户跳转到小程序其他页面，使用小程序的更丰富的功能。在这一过程中，可以利用分包预下载能力，将主包或相关分包进行预下载，降低页面跳转的延迟，留住更多用户。 开发者在使用这两个新能力的过程中，如果遇到问题或者有什么建议，欢迎在微信开放社区（https://developers.weixin.qq.com）进行反馈，我们会根据开发者的反馈，不断的优化和丰富分包加载功能，减少功能限制，提升小程序的加载性能和使用体验。

各位开发者： 大家好 为了让开发者能够更方便的使用小程序·云开发。我们对云开发提供的基础资源配额进行了调整，具体调整内容包括： 存储上传次数由 2 万/天调整为 60 万/月 存储下载次数由 5 万/天调整为150 万/月 去除数据库 QPS 限制 数据库单集合索引调整为系统参数限制，由原有 10 个调整为 20 个 云函数数量调整为系统参数限制，由原有 20 个调整为 50 个 增加数据库流量说明，单次出包大小为 16 M 其余参数不做调整。调整后的配额信息可参考 小程序·云开发配额。 同时，由于近期小程序·云开发将上线付费功能（付费功能针对非基础资源配额，基础资源配额仍可免费使用）。为了给开发者更充足的时间进行调整，对于截止 2019-05-17 日前通过邮件申请调整的配额（非基础资源配额）的截止日期统一延长至 2019-06-30 。且对于已申请过配额调整的小程序帐号： 存储上传次数和存储下载次数调整为按月计算。如之前存储上传次数为 10 万/天，则调整后为 300 万/月 去掉数据库 QPS 限制 数据库单集合索引调整为系统参数限制，由原有 10 个调整为 20 个 云函数数量调整为系统参数限制，由原有 20 个调整为 50 个 增加数据库流量说明，单次出包大小为 16 M 云开发控制台新增详细的资源使用量统计 为了方便开发者了解资源使用情况，我们在云开发控制台的资源使用中增加了详细的资源使用量统计数据以及资源生命周期。开发者可通过下载最新 RC Build 版的开发者工具进行功能体验。 [图片] 小程序·云开发新增 HTTP API 为了进一步降低开发门槛并解决数据孤岛问题，小程序·云开发新增 HTTP API 支持。HTTP API 提供了小程序外访问云开发资源的能力，使用 HTTP API 开发者可在已有服务器上访问云资源，实现与云开发资源的互通。具体使用方法请参考 小程序·云开发HTTP API文档。 云调用支持开放数据调用 为了方便开发者更快速的进行功能迭代，云调用支持开放数据调用。对返回敏感开放数据的小程序端接口，从基础库 2.7.0 起，如果小程序已开通云开发，则可在开放数据接口的返回值中获取到唯一对应敏感开放数据的 cloudID，通过云调用可以直接获取到开放数据，具体使用方法请参考 云调用直接获取开放数据。 微信团队 2019.05.17

微信小程序的开发者们在发布小程序之前，需要给每个小程序起好一个名称，设置好logo、简介及类目信息，然后才能进行代码提审。 这些账号的基础信息是用户对一个小程序的初步认知，平台希望这些信息能够给予用户准确预期每个小程序的功能和内容，也希望每个小程序的名称是具有独特性的，减少误导、混淆用户理解的可能性。 因此有以下几点名称规则调整及优化建议，希望开发者可以了解并遵循，后续可能会在名称审核、代码审核或已发布运营时，收到平台的审核通知或建议修改通知。 l 微信小程序的名称建议是品牌、商标或具有辨识度的短词 在微信小程序发布后，用户会通过搜索、传播等场景使用小程序的功能和服务。选择品牌、商标或具有辨识度的短词作为小程序的名称，可以帮助用户快速建立与小程序的记忆与关系。 名称为“印象笔记”会比“笔记”能更好的让用户记忆和理解，并使用“印象”品牌词进行搜索或传播。 [图片] l 不能直接使用功能性描述、广义归纳类的词汇作为名称 功能性描述的词汇虽然可传达出小程序所要提供的相关功能，但直接使用此类词汇，缺乏显著性且不具有识别、区分小程序的作用。 如名称为“牙科”的账号，用户能直接理解小程序的内容可能与“牙科”相关，但对这个小程序账号是没有建立认知和关系的。  [图片]  l 不能同时使用地域性词汇与广义归纳类词汇进行命名 使用“地域+广义归纳类”词汇进行命名，同样存在指向性过于宽泛的问题。 如以下案例， 名称包含的地域词：“四川”、归纳类词：“系统门窗”，并不会让用户对账号的功能产生有效的预期。以下示例是不允许的： [图片] 但在政务民生类服务场景，“广州地铁”、“广州公积金”可以被用户理解并接受属于政府或相关机构提供的服务和资讯，因此“地域+广义归纳类”词汇可被政府民生场景使用。 l 不建议使用具有营销属性的词汇进行命名 营销属性词汇如：免费、促销、清仓、打折等，鉴于活动规则普遍附有限制条件，在名称中使用，通常带有过于夸大的表达效果，并非是小程序的核心功能和用户的全部认知，存在误导的可能性。以下示例是不允许的： [图片] l 商品销售类小程序，需要包含品牌名称，不直接使用产品分类进行命名 商品销售类小程序，若仅使用产品分类进行命名，无法建立易于记忆、易于传播的品牌形象。如名称为“女鞋男鞋女包批发生产”，用户并不会因“女鞋”“男鞋”“女包”就会进行选择，反而“品牌+女装”才是用户真正需要的。以下示例是不允许的。 [图片] l 不在名称中堆砌热门搜索关键词 名称中堆砌多个关键词，过于冗长的热门搜索关键词堆砌名称无法建立品牌记忆，目的普遍是在搜索结果上获得更多的曝光。以下示例是不允许的： [图片] 结语 此次名称规则的调整和优化建议，平台希望开发者们能相应地调整自己的小程序名称。如未满足名称规范，平台会在后续的小程序名称设置、名称审核、代码审核流程进行规则提示和修改要求。并会在搜索场景优化需求基础上，对无辨识度的账号名称进行搜索策略调整。 微信小程序完整的名称规则可具体参照《微信小程序平台运营规范》2. 基本信息规范，除以上规则与示例之外，当然还包括了不得使用违法违规的名称、不得使用侵权他人的品牌词进行命名、在命中敏感类目如医疗词时提交主体资质等规则。 平台希望小程序名称的优化调整，可以使得每个被开发者精心创造出来的小程序都能让用户在使用时、搜索时、传播时逐渐接受并建立对产品品牌的认知。

     小程序插屏广告指小程序在特定场景切换时以卡片方式弹出的广告形式。当用户触发流量主指定场景时，插屏广告就会自动向用户展现，目前向非游戏类目全量流量主开放，小游戏类目即将启动内测。       此外激励式视频广告也向非游戏类小程序流量主开放，详见《激励式视频广告开通指引》。 [图片] [图片][图片] [图片][图片][图片][图片][图片] [图片] [图片] [图片]

为了优化用户的使用体验，平台将回收“使用 wx.getUserInfo 接口直接弹出授权框”以及“使用 wx.authorize 接口直接申请提前授权用户信息”的能力，开发者需要使用组件方式唤起登录授权弹窗。 2018年10月10日后发布新版本的小程序，将无法在线上版本中使用接口直接弹出授权框。开发者可结合平台设计建议，提前做好兼容，合理使用微信登录能力。 能力调整背景 怎么合理使用微信登录能力 小程序登录流程设计建议 01 能力调整背景 推出微信登录能力的初衷是希望：当用户使用小程序时，可以便捷地使用微信身份登录小程序。但在实际使用场景中，我们发现：很多开发者在打开小程序时直接弹出授权框，如果用户点击拒绝授权，无法使用小程序。 在用户无法获知当前小程序服务内容的情况下，很多用户就会选择拒绝授权并离开当前小程序。所以“一进入小程序就要求用户授权”的做法打断了用户正常使用小程序的流程，同时也不利于小程序获取新用户。 所以平台调整登录接口，回收“使用 wx.getUserInfo 接口直接弹出授权框”以及“使用 wx.authorize 接口直接申请提前授权用户信息”的能力，并鼓励开发者参照以下指引合理改造小程序内的登录流程。 02 怎么合理使用微信登录能力 平台分别提供多种方式实现微信登录： 1. 调用wx.login接口，静默获取openid 适用场景：无需使用用户头像、昵称、Unionid信息 2. 使用 open-data （小程序）或者开放数据域（小游戏）的方式展示用户信息（无需用户授权） 适用场景：需要在前端“展示”用户头像、昵称信息，但不需要获取Unionid 3.使用button（小程序）或UserInfoButton（小游戏）组件，用户点击后弹窗请求用户授权 适用场景：需要获取用户头像、昵称、Unionid等基本信息 开发建议 第一步：获取openID 当用户访问小程序时，先通过wx.login，获取用户openID 。这时无需弹框授权，开发者拿到 openID 可以建立自身的帐号 ID。 第二步： 使用open-data方式或开放数据域方式展示头像昵称 如需要在前端展示用户头像、昵称信息， 使用open-data 方式或者开放数据域的方式展示用户信息 第三步：根据实际使用场景，使用组件，引导用户登录 在关键操作中，如必须获取用户头像、昵称、UnionID信息，可根据第一步获取的openID判断是新用户还是旧用户：     如果是旧用户，可以直接登录，也可定期使用wx.getUserInfo更新用户的信息；     如果是新用户，使用button（小程序）或UserInfoButton（小游戏）组件，在用户点击后弹窗请求获取用户基本信息。 03 小程序登录流程设计建议 a. 在必须用到登录信息的环节引导用户登录 在用户必须登录时才引导用户登录（如：购买前需要获取会员信息，用于同步积分数据），而不是用户一进入小程序就弹窗要求用户授权。如只需要在前端展示用户头像、昵称，无需要求用户授权，可直接展示。 [图片] b.清晰、准确地引导用户登录 在登录页面中，清晰、准确地告知用户当前操作是登录，说明获取登录信息的目的（如：用于同步会员积分数据等） [图片] c. 不强制用户必须登录后才能使用小程序服务 提供游客模式，不强制用户必须登录后才能进入小程序。如要求必须授权头像昵称等信息才能继续使用小程序，会导致某些用户放弃使用该小程序。 [图片]

文件系统能力 文件系统能力可便于用户在客户端保存文件资源，并在下次启动客户端之后可以使用已保存的文件。 只要用户不主动删除小程序或小游戏，并保持一定的使用频率，文件都可以一直被保留。 合理的使用文件系统能力来缓存资源文件，可以给开发者更好的使用体验。 今天，我们来分享文件系统能力的小故事。 1 文件系统的演进历史 小程序在最早发布的版本中就已提供了最基础的文件存储和删除接口：wx.saveFile、 wx.removeSavedFile ； 对于绝大部分的小程序来说，这两个接口已经能够满足开发者的需求。但对于小游戏来说，需要更完整的能力来做支撑。 因此，发布小游戏的时候我们便提供了一套更完整的文件管理系统：FileSystemManager，其中主要包含了目录管理、文件内容读写等能力。 2 文件系统的设计背景 文件系统能力是应小游戏开发需求的迭代而逐步增强的。在小程序的场景下，很多时候只是需要把一个图片或视频资源缓存起来便可继续使用，文件内容与文件存储的目录结构都不是开发者所关心的。 但是在小游戏场景下情况则不同—— 一方面，小游戏除了有图片和视频文件、还有游戏引擎生成的配置文件，游戏需要能够去读取并理解配置文件的具体内容； 另一方面，游戏使用的资源文件会比普通小程序更多，若没有内容目录管理的功能，维护成本会变高。 除此之外，由于小游戏代码包大小限制只有4MB (加上分包最多8MB)，对于一些偏重的游戏，资源甚至容易超100MB。 因此在此大背景下，我们给文件系统主要增加了目录管理、文件内容读写等两项接口—— 目录管理的需求场景是在使用游戏引擎时需要按目录来管理资源文件，文件内容读写的需求场景是在使用游戏引擎时需要读取配置文件；同时，我们对小游戏类目的本地存储容量的规范限制扩容到50MB。 开发者可能会疑惑，为什么在小程序的文件系统中会有一些功能相接近的接口？例如，想缓存一个文件，可以用 saveFile 或 copyFile ；再比如 removeSavedFile和 unlink 都可以用来删除一个文件。 上述情况的原因是我们在早期便提供了基础的文件存储接口 saveFile 和removeFile ，但不提供自定义目录相关的能力，开发者调用 saveFile 之后只能得到微信返回到的一个随机文件名。 小游戏应运而生的同时也增强了对文件系统能力扩展的需求，为了保证向后兼容，我们保留了这批基础接口，并在这个基础上增加了目录管理接口以及对应的文件操作接口。因此，便出现了上述一些相似接口的情况。 3 文件系统的优势—存储隔离 有不少开发者询问过关于文件存储的问题，他们担心文件内容被其他小程序读取到，也担心多个登录用户之间的文件内容会互相影响。为了保证用户的隐私安全，也为了保证小程序的数据安全，本地文件存储的一个重要规则便是保证隔离。 文件被存储到本地后，会以小程序账号和用户账号两个不同的维度来区分和隔离。即：同个微信用户使用不同小程序之间的文件存储会互相隔离；不同微信用户（在同一台手机中）使用同个小程序时，不同用户间的文件存储也会互相隔离。 [图片] 4 适当的存储容量 考虑到存储的问题，我们规范了小游戏文件存储的容量。普通小程序是10MB，小游戏则是50MB，当文件存储超出限制时，写入的文件会失败。 功能上线以后，我们曾收到过若干宝贵意见与反馈，希望能提高容量限制。但在经过反复论证与评估后，我们认为如果将文件存储的容量再往上提，就会有用户新增需要管理或清理手机存储空间的需求，小程序和小游戏将会变得不再“小”了。对于资源文件超过上述标准限制的小程序与小游戏，应该合理地管理本地文件，及时清理不常用的文件，这样在大多数情况下，手机存储空间便能保证顺畅。 更多关于小程序文件系统能力的信息，可查阅 接口文档 。

有时候我们使用一个小程序会遇到以下情形： 我们打开一个小程序，就看见提示“分享到5个群，可以获得一张20元的优惠券”，吸引我们去无脑分享到不同的群里； 打开某个小游戏，提示我“一定要分享到xx个群，才能继续玩游戏”； …… 而我们在群里打开这类小程序，仍然是提示我分享的信息，这类功能无疑打断了我们对小程序/小游戏正常的功能使用。 我们收到了很多用户对这类小程序/小游戏的抱怨。这类分享并非是用户主动自发的，而是受到了某类利益的诱惑，或是被迫分享。这样的内容充斥在群里、小程序里，对用户造成了骚扰，是对分享功能的滥用。 在原来的分享接口中，用户发起分享动作之后，可以通过 success 、fail、complete等回调来判断用户是否完成了最后的分享动作。通过这个能力，开发者是可以将产品交互在分享这个能力上做得比较自然和顺畅。但却被上述情形的小程序滥用。在我们权衡了分享功能带来的利弊后，我们打算回收这个能力。调整为：我们将不再支持分享回调参数 success 、fail 、complete 。即开发者无法判断用户最终是否完成了分享动作，也无法获取到分享成功后的回调参数shareTicket 。 接下来将与大家介绍此次分享功能调整后，小程序的调整建议。 对应小程序调整建议 此次调整可能影响到两种分享功能的用法。 第一种：通过判断用户最终是否有分享来做分支逻辑的小程序。 例如，通过判断 success 回调触发，来判断用户是否分享出去了，进而给奖励，如果用户没有分享出去则不给奖励。这类功能是我们平台不倡导的，后续将没有办法实现。 如果是需要在分享完成后变更当前页面的状态，可以适当调整交互方案。例如过去赠送代金券后显示“等待领取”等应用场景，可以改成在分享后继续保留“赠送”按钮，但提示用户一个代金券只能被一人领取，重复赠送无效。 第二种：获取用户分享之后的 shareTicket ，换取群唯一标识 openGId ，进而显示对应群的相关信息的小程序。 例如，部分小程序实现了群内的排行信息，通过分享小程序到某个群里，可以查看该群内成员的排行榜。 此次调整后，用户分享完成后无法立刻显示该群的排行榜信息，但仍可在用户从群消息点击进入小程序时显示该群的排行榜信息。 因此建议适当修改产品流程，在用户分享小程序之时，提示用户可进入群内查看群排行等信息。避免调整策略生效之后带来的交互不完整影响。 调整覆盖范围提示 近期新提交的版本中将会受到此策略的影响。 除此之外，调整策略在即将发布的基础库版本 2.3.0 生效，该基础库版本对应本月即将发布的微信客户端版本（暂定版本号 6.7.2）。即：近期提交审核的小程序版本，在基础库版本 2.3.0 以下的环境中仍不受此策略影响，仅在基础库版本 2.3.0 以上的环境受影响。 开发者需要注意，近期提交审核的版本都需要考虑兼容上述调整带来的影响，请各位开发者及时调整分享能力。

开发者在开发小程序的时候可能会碰到一些这样的问题： 问题1  开发者工具上看效果没问题，但是在真机上测试不行？ 问题2  有用户遇到小程序功能无法使用的问题，但无法快速定位解决？ 今天我们的小故事与大家分享一些真机定位的技巧，可以解决上面两个问题。 1 vConsole开发利器和远程调试功能 针对问题1，我们提供了 vConsole 开发利器和远程调试功能，可以协助开发者在定位真机上的问题。 vConsole 的有四个Tab面板，可以先看下 Log 面板，看是否有异常信息，异常类型 thirdScriptError 是框架捕捉到的开发者的代码执行的异常，可以优先处理异常信息看是否可以解决问题。Log 面板可以看到异常出现的文件和行数。 [图片] 除了异常日志，开发者还可以通过 console.log 接口在一些关键执行路径上打日志来定位问题，这些日志会呈现在 Log 面板上。 vConsole 默认是不开启的，可以通过下面2个方法来开启： 1 开发版和体验版可以点击小程序页面右上角的...按钮打开的菜单项“打开调试”来开启 vConsole。 2 正式版没有“打开调试”的菜单项，可以先通过开发版和体验版来开启 vConsole，然后再打开正式版。或者可以预埋一个隐藏操作，比如连续点击某个 Button 多次，然后调用 API 接口 wx.setEnableDebug 来打开。 vConsole 虽然强大，但在手机上查看大量的日志信息不方便，此外，vConsole 没有断点调试、无法修改样式，定位复杂问题需要花费比较多的时间。 小程序的业务逻辑运行在 AppService 层，页面渲染在 WebView 运行，并通过微信客户端通信，因此，我们想到了可以让 AppService 运行在开发者工具，页面渲染还是在手机 WebView，两者通过网络来通信，这样借助开发者工具的调试能力，就可以实现远程调试功能。 远程调试窗口通过手机客户端扫描开发者工具上生成的二维码来打开，无需像普通手机 H5 页面调试一样，需要在手机端进行一些设置。 [图片] 打开的远程调试界面和开发者工具的模拟器的调试界面很像，需要注意的是，要在 Console 里对小程序进行调试，需要将调试的上下文切换到 VM Context 1 。 [图片] 更多的远程调试的使用方法请参考使用文档。 2 意见反馈能力 对于问题2，小程序的使用反馈来自用户投诉，这种情况用户无法联系到开发者。我们遇见过有小程序功能出现问题，用户无法使用，但投诉无门的情况，而这些问题，开发者也没有途径去收集以及处理，这就导致了小程序服务质量下降，用户流失。 为此，我们开发了“意见反馈”功能，当出现问题时，开发者可以引导用户使用“意见反馈”进行反馈，并上传日志来辅助开发者定位问题。操作过程如下： 引导用户进入小程序帐号详情页面，具体可以在小程序界面点击右上角...按钮，选择关于菜单。接着在帐号详情页面点击右上角...按钮，选择意见反馈菜单进入页面。页面可以上传图片和日志，建议用户上传异常情况的截图，以及勾选允许开发者使用小程序日志选项上传日志，反馈信息越详细，越有助于定位问题。 [图片] [图片] 如果觉得上面的操作步骤太麻烦，开发者可以通过在页面 WXML 添加下面的按钮，用户点击按钮可以直接打开“意见反馈”页面。 [图片] 开发者需要定时处理用户的反馈，这样才能保证小程序的质量。开发者可以登录小程序管理后台，进入左侧菜单客服反馈，就可以看到用户的反馈内容以及下载日志来辅助定位问题。 [图片] 为了保证日志信息足够详细，开发者需要用下面的接口在代码的关键执行路径上写日志。 [图片] wx.getLogManager 接口的更详细使用请参考文档。 希望通过这些小技巧，可以帮助大家顺畅地开发小程序。

《跳一跳》小游戏在 2017年12月28日正式发布，一周内 DAU 突破一亿，为小游戏开放生态赢得口碑。它操作简单，节奏轻快，凭借着快速复活机制以及强大的社交属性掀起了一股全民潮流。 其实，这个小游戏里仅有两个元素，黑色小人和各色基座。游戏规则也很简单，起跳前，小黑人压缩自己的身体来蓄力，根据蓄力时间决定距离来跳到下一个基座上。 今天的小故事，想要跟大家分享小游戏的渲染能力，我们以跳一跳唱片机为例，简要介绍一下如何展现一个三维物体~ ( 3D渲染引擎选用 Three.js ) [图片] 步骤一 创建一个场景 Scene 游戏的容器，用来放置光源，照相机和唱片机。 let scene = new THREE.Scene() 步骤二 选择合适的照相机 Camera 抽象来说，照相机定义了三维空间到二维屏幕的投影方式。 因投影方式不同，相机又分为透视投影相机和正交投影相机。 透视投影中的四棱柱和正交投影中的立方体被称为视景体，它是三维世界里屏幕上可见的区域，也就是照相机的视野。 视景体外的物体会被剪裁掉不参与渲染。透视投影更接近真实世界，有近大远小的感觉。而正交投影将物体以原比例平行投影到近剪裁面上，不会有大小缩放。 在跳一跳中我们使用了正交投影相机。 [图片] let camera = new THREE.OrthographicCamera( width / - 2, width / 2, height / 2, height / - 2, near, far ) 步骤三 创建光源 light let ambientLight = new THREE.AmbientLight(0xffffff, 0.8); let directionalLight = new THREE.DirectionalLight(0xffffff, 0.28); 创建一个环境光和直射光, 环境光没有特定光源，它将光线均匀照射在场景中。直射光模拟真实世界太阳光。 步骤四 定义几何体 Geometry， 材质 Material，合成 Mesh Geometry 几何体，定义了一个物体的形状，包含顶点，线，面和法向量等信息。 let boxGeometry = new THREE.BoxGeometry(2, 2, 2) 对于唱片机我们创建了三个几何体，两个长方体和一个圆柱体。 [图片] Material 材质，定义了一个物体的外观，例如颜色，透明度，光照属性，融合模式。 顶部透明盖子，底座和唱片的使用的Lambert材质，这种材质只考虑漫反射而不考虑镜面反射, 通常用于创建较暗淡无高光的物体, 其中 texture 是纹理贴图，我们通过纹理映射将这个二维图像贴到三维的方块上。 let transparentMaterial = new THREE.MeshLambertMaterial({ color: ‘white’, transparent: true, opacity: 0.5, map: texture }) 最后我们通过 Mesh 我们将材质应用到几何体上。 let box = new THREE.Mesh(boxGeometry, transparentMaterial) 步骤五 使用渲染器 Renderer 渲染整个场景 最后我们将 box，camera 设置合适的位置后加入到场景中，再使用 Three.js 的渲染器 renderer 之后就可以看到音乐盒了~ renderer.render(scene, camera) 至此，我们完成了一个 3D 场景渲染到 2D 屏幕的渲染流水线中的应用程序阶段，这个阶段我们将渲染所需的几何信息（点，线，面，法线等信息）传递到渲染流水线的后续阶段。后续的小故事我们会介绍调用渲染器 render 方法后 GPU 是如何处理几何信息并最终渲染图像到屏幕上的。 QA&共性问题 Q   一般的 3D 游戏 HUD 层（平视显示器）采用 DOM 来显示，例如排行榜，交互按钮。或者使用另一个 canvas 叠在游戏 canvas 上。但是小游戏只支持一个可见 canvas，并且不支持 DOM。这种情况在小游戏里面，应该如何处理呢？ A   可以封装 HUD 层并将其放在游戏 canvas 中，将整个HUD画在了一张离屏 canvas 中，然后将该 canvas 转化为纹理贴图，再将其贴在游戏的 3D 平面模型上。 后续的小故事会介绍如何将 HUD 分解为 3D 组件的形式来开发。