小程序内置了[代码]wx.request[代码]，用于向后端发送请求，我们先来看看它的文档： wx.request(OBJECT) 发起网络请求。使用前请先阅读说明。 OBJECT参数说明： 参数名 类型 必填 默认值 说明 最低版本 url String 是 - 开发者服务器接口地址 - data Object/String/ArrayBuffer 否 - 请求的参数 - header Object 否 - 设置请求的 header，header 中不能设置 Referer。 - method String 否 GET （需大写）有效值：OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, CONNECT - dataType String 否 json 如果设为json，会尝试对返回的数据做一次 JSON.parse - responseType String 否 text 设置响应的数据类型。合法值：text、arraybuffer 1.7.0 success Function 否 - 收到开发者服务成功返回的回调函数 - fail Function 否 - 接口调用失败的回调函数 - complete Function 否 - 接口调用结束的回调函数（调用成功、失败都会执行） - success返回参数说明： 参数 类型 说明 最低版本 data Object/String/ArrayBuffer 开发者服务器返回的数据 - statusCode Number 开发者服务器返回的 HTTP 状态码 - header Object 开发者服务器返回的 HTTP Response Header 1.2.0 这里我们主要看两点： 回调函数：success、fail、complete； success的返回参数：data、statusCode、header。 相对于通过入参传回调函数的方式，我更喜欢promise的链式，这是我期望的第一个点；success的返回参数，在实际开发过程中，我只关心data部分，这里可以做一下处理，这是第二点。 promisify 小程序默认支持promise，所以这一点改造还是很简单的： [代码]/** * promise请求 * 参数：参考wx.request * 返回值：[promise]res */ function requestP(options = {}) { const { success, fail, } = options; return new Promise((res, rej) => { wx.request(Object.assign( {}, options, { success: res, fail: rej, }, )); }); } [代码] 这样一来我们就可以使用这个函数来代替wx.request，并且愉快地使用promise链式： [代码]requestP({ url: '/api', data: { name: 'Jack' } }) .then((res) => { console.log(res); }) .catch((err) => { console.log(err); }); [代码] 注意，小程序的promise并没有实现finally，Promise.prototype.finally是undefined，所以complete不能用finally代替。 精简返回值 精简返回值也是很简单的事情，第一直觉是，当请求返回并丢给我一大堆数据时，我直接resolve我要的那一部分数据就好了嘛： [代码]return new Promise((res, rej) => { wx.request(Object.assign( {}, options, { success(r) { res(r.data); // 这里只取data }, fail: rej, }, )); }); [代码] but！这里需要注意，我们仅仅取data部分，这时候默认所有success都是成功的，其实不然，wx.request是一个基础的api，fail只发生在系统和网络层面的失败情况，比如网络丢包、域名解析失败等等，而类似404、500之类的接口状态，依旧是调用success，并体现在[代码]statusCode[代码]上。 从业务上讲，我只想处理json的内容，并对json当中的相关状态进行处理；如果一个接口返回的不是约定好的json，而是类似404、500之类的接口异常，我统一当成接口/网络错误来处理，就像jquery的ajax那样。 也就是说，如果我不对[代码]statusCode[代码]进行区分，那么包括404、500在内的所有请求结果都会走[代码]requestP().then[代码]，而不是[代码]requestP().catch[代码]。这显然不是我们熟悉的使用方式。 于是我从jquery的ajax那里抄来了一段代码。。。 [代码]/** * 判断请求状态是否成功 * 参数：http状态码 * 返回值：[Boolen] */ function isHttpSuccess(status) { return status >= 200 && status < 300 || status === 304; } [代码] [代码]isHttpSuccess[代码]用来决定一个http状态码是否判为成功，于是结合[代码]requestP[代码]，我们可以这么来用： [代码]return new Promise((res, rej) => { wx.request(Object.assign( {}, options, { success(r) { const isSuccess = isHttpSuccess(r.statusCode); if (isSuccess) { // 成功的请求状态 res(r.data); } else { rej({ msg: `网络错误:${r.statusCode}`, detail: r }); } }, fail: rej, }, )); }); [代码] 这样我们就可以直接resolve返回结果中的data，而对于非成功的http状态码，我们则直接reject一个自定义的error对象，这样就是我们所熟悉的ajax用法了。 登录 我们经常需要识别发起请求的当前用户，在web中这通常是通过请求中携带的cookie实现的，而且对于前端开发者是无感知的；小程序中没有cookie，所以需要主动地去补充相关信息。 首先要做的是：登录。 通过[代码]wx.login[代码]接口我们可以得到一个[代码]code[代码]，调用后端登录接口将code传给后端，后端再用code去调用微信的登录接口，换取[代码]sessionKey[代码]，最后生成一个[代码]sessionId[代码]返回给前端，这就完成了登录。 [图片] 具体参考微信官方文档：wx.login [代码]const apiUrl = 'https://jack-lo.github.io'; let sessionId = ''; /** * 登录 * 参数：undefined * 返回值：[promise]res */ function login() { return new Promise((res, rej) => { // 微信登录 wx.login({ success(r1) { if (r1.code) { // 获取sessionId requestP({ url: `${apiUrl}/api/login`, data: { code: r1.code, }, method: 'POST' }) .then((r2) => { if (r2.rcode === 0) { const { sessionId } = r2.data; // 保存sessionId sessionId = sessionId; res(r2); } else { rej({ msg: '获取sessionId失败', detail: r2 }); } }) .catch((err) => { rej(err); }); } else { rej({ msg: '获取code失败', detail: r1 }); } }, fail: rej, }); }); } [代码] 好的，我们做好了登录并且顺利获取到了sessionId，接下来是考虑怎么把sessionId通过请求带上去。 sessionId 为了将状态与数据区分开来，我们决定不通过data，而是通过header的方式来携带sessionId，我们对原本的requestP稍稍进行修改，使得它每次调用都自动在header里携带sessionId： [代码]function requestP(options = {}) { const { success, fail, } = options; // 统一注入约定的header let header = Object.assign({ sessionId: sessionId }, options.header); return new Promise((res, rej) => { ... }); } [代码] 好的，现在请求会自动带上sessionId了； 但是，革命尚未完成： 我们什么时候去登录呢？或者说，我们什么时候去获取sessionId？ 假如还没登录就发起请求了怎么办呢？ 登录过期了怎么办呢？ 我设想有这样一个逻辑： 当我发起一个请求的时候，如果这个请求不需要sessionId，则直接发出； 如果这个请求需要携带sessionId，就去检查现在是否有sessionId，有的话直接携带，发起请求； 如果没有，自动去走登录的流程，登录成功，拿到sessionId，再去发送这个请求； 如果有，但是最后请求返回结果是sessionId过期了，那么程序自动走登录的流程，然后再发起一遍。 其实上面的那么多逻辑，中心思想只有一个：都是为了拿到sessionId！ 我们需要对请求做一层更高级的封装。 首先我们需要一个函数专门去获取sessionId，它将解决上面提到的2、3点： [代码]/** * 获取sessionId * 参数：undefined * 返回值：[promise]sessionId */ function getSessionId() { return new Promise((res, rej) => { // 本地sessionId缺失，重新登录 if (!sessionId) { login() .then((r1) => { res(r1.data.sessionId); }) .catch(rej); } } else { res(sessionId); } }); } [代码] 好的，接下来我们解决第1、4点，我们先假定：sessionId过期的时候，接口会返回[代码]code=401[代码]。 整合了getSessionId，得到一个更高级的request方法： [代码]/** * ajax高级封装 * 参数：[Object]option = {}，参考wx.request； * [Boolen]keepLogin = false * 返回值：[promise]res */ function request(options = {}, keepLogin = true) { if (keepLogin) { return new Promise((res, rej) => { getSessionId() .then((r1) => { // 获取sessionId成功之后，发起请求 requestP(options) .then((r2) => { if (r2.rcode === 401) { // 登录状态无效，则重新走一遍登录流程 // 销毁本地已失效的sessionId sessionId = ''; getSessionId() .then((r3) => { requestP(options) .then(res) .catch(rej); }); } else { res(r2); } }) .catch(rej); }) .catch(rej); }); } else { // 不需要sessionId，直接发起请求 return requestP(options); } } [代码] 留意req的第二参数keepLogin，是为了适配有些接口不需要sessionId，但因为我的业务里大部分接口都需要登录状态，所以我默认值为true。 这差不多就是我们封装request的最终形态了。 并发处理 这里其实我们还需要考虑一个问题，那就是并发。 试想一下，当我们的小程序刚打开的时候，假设页面会同时发出5个请求，而此时没有sessionId，那么，这5个请求按照上面的逻辑，都会先去调用login去登录，于是乎，我们就会发现，登录接口被同步调用了5次！并且后面的调用将导致前面的登录返回的sessionId过期~ 这bug是很严重的，理论上来说，登录我们只需要调用一次，然后一直到过期为止，我们都不需要再去登录一遍了。 ——那么也就是说，同一时间里的所有接口其实只需要登录一次就可以了。 ——也就是说，当有登录的请求发出的时候，其他那些也需要登录状态的接口，不需要再去走登录的流程，而是等待这次登录回来即可，他们共享一次登录操作就可以了！ 解决这个问题，我们需要用到队列。 我们修改一下getSessionId这里的逻辑： [代码]const loginQueue = []; let isLoginning = false; /** * 获取sessionId * 参数：undefined * 返回值：[promise]sessionId */ function getSessionId() { return new Promise((res, rej) => { // 本地sessionId缺失，重新登录 if (!sessionId) { loginQueue.push({ res, rej }); if (!isLoginning) { isLoginning = true; login() .then((r1) => { isLoginning = false; while (loginQueue.length) { loginQueue.shift().res(r1); } }) .catch((err) => { isLoginning = false; while (loginQueue.length) { loginQueue.shift().rej(err); } }); } } else { res(sessionId); } }); } [代码] 使用了isLoginning这个变量来充当锁的角色，锁的目的就是当登录正在进行中的时候，告诉程序“我已经在登录了，你先把回调都加队列里去吧”，当登录结束之后，回来将锁解开，把回调全部执行并清空队列。 这样我们就解决了问题，同时提高了性能。 封装 在做完以上工作以后，我们都很清楚的封装结果就是[代码]request[代码]，所以我们把request暴露出去就好了： [代码]function request() { ... } module.exports = request; [代码] 这般如此之后，我们使用起来就可以这样子： [代码]const request = require('request.js'); Page({ ready() { // 获取热门列表 request({ url: 'https://jack-lo.github.io/api/hotList', data: { page: 1 } }) .then((res) => { console.log(res); }) .catch((err) => { console.log(err); }); // 获取最新信息 request({ url: 'https://jack-lo.github.io/api/latestList', data: { page: 1 } }) .then((res) => { console.log(res); }) .catch((err) => { console.log(err); }); }, }); [代码] 是不是很方便，可以用promise的方式，又不必关心登录的问题。 然而可达鸭眉头一皱，发现事情并不简单，一个接口有可能在多个地方被多次调用，每次我们都去手写这么一串[代码]url[代码]参数，并不那么方便，有时候还不好找，并且容易出错。 如果能有个地方专门记录这些url就好了；如果每次调用接口，都能像调用一个函数那么简单就好了。 基于这个想法，我们还可以再做一层封装，我们可以把所有的后端接口，都封装成一个方法，调用接口就相对应调用这个方法： [代码]const apiUrl = 'https://jack-lo.github.io'; const req = { // 获取热门列表 getHotList(data) { const url = `${apiUrl}/api/hotList` return request({ url, data }); }, // 获取最新列表 getLatestList(data) { const url = `${apiUrl}/api/latestList` return request({ url, data }); } } module.exports = req; // 注意这里暴露的已经不是request，而是req [代码] 那么我们的调用方式就变成了： [代码]const req = require('request.js'); Page({ ready() { // 获取热门列表 req.getHotList({ page: 1 }) .then((res) => { console.log(res); }) .catch((err) => { console.log(err); }); // 获取最新信息 req.getLatestList({ page: 1 }) .then((res) => { console.log(res); }) .catch((err) => { console.log(err); }); } }); [代码] 这样一来就方便了很多，而且有一个很大的好处，那就是当某个接口的地址需要统一修改的时候，我们只需要对[代码]request.js[代码]进行修改，其他调用的地方都不需要动了。 错误信息的提炼 最后的最后，我们再补充一个可轻可重的点，那就是错误信息的提炼。 当我们在封装这么一个[代码]req[代码]对象的时候，我们的promise曾经reject过很多的错误信息，这些错误信息有可能来自： [代码]wx.request[代码]的fail； 不符合[代码]isHttpSuccess[代码]的网络错误； getSessionId失败； … 等等的一切可能。 这就导致了我们在提炼错误信息的时候陷入困境，到底catch到的会是哪种[代码]error[代码]对象？ 这么看你可能不觉得有问题，我们来看看下面的例子： [代码]req.getHotList({ page: 1 }) .then((res) => { console.log(res); }) .catch((err) => { console.log(err); }); [代码] 假如上面的例子中，我想要的不仅仅是[代码]console.log(err)[代码]，而是想将对应的错误信息弹窗出来，我应该怎么做？ 我们只能将所有可能出现的错误都检查一遍： [代码]req.getHotList({ page: 1 }) .then((res) => { if (res.code !== 0) { // 后端接口报错格式 wx.showModal({ content: res.msg }); } }) .catch((err) => { let msg = '未知错误'; // 文本信息直接使用 if (typeof err === 'string') { msg = err; } // 小程序接口报错 if (err.errMsg) { msg = err.errMsg; } // 自定义接口的报错，比如网络错误 if (err.detail && err.detail.errMsg) { msg = err.detail.errMsg; } // 未知错误 wx.showModal({ content: msg }); }); [代码] 这就有点尴尬了，提炼错误信息的代码量都比业务还多几倍，而且还是每个接口调用都要写一遍~ 为了解决这个问题，我们需要封装一个方法来专门做提炼的工作： [代码]/** * 提炼错误信息 * 参数：err * 返回值：[string]errMsg */ function errPicker(err) { if (typeof err === 'string') { return err; } return err.msg || err.errMsg || (err.detail && err.detail.errMsg) || '未知错误'; } [代码] 那么过程会变成： [代码]req.getHotList({ page: 1 }) .then((res) => { console.log(res); }) .catch((err) => { const msg = req.errPicker(err); // 未知错误 wx.showModal({ content: msg }); }); [代码] 好吧，我们再偷懒一下，把wx.showModal也省去了： [代码]/** * 错误弹窗 */ function showErr(err) { const msg = errPicker(err); console.log(err); wx.showModal({ showCancel: false, content: msg }); } [代码] 最后就变成了： [代码]req.getHotList({ page: 1 }) .then((res) => { console.log(res); }) .catch(req.showErr); [代码] 至此，一个简单的wx.request封装过程便完成了，封装过的[代码]req[代码]比起原来，使用上更加方便，扩展性和可维护性也更好。 结尾 以上内容其实是简化版的[代码]mp-req[代码]，介绍了[代码]mp-req[代码]这一工具的实现初衷以及思路，使用[代码]mp-req[代码]来管理接口会更加的便捷，同时[代码]mp-req[代码]也提供了更加丰富的功能，比如插件机制、接口的缓存，以及接口分类等，欢迎大家关注mp-req了解更多内容。 以上最终代码可以在这里获取：req.js。

[图片]                                            大家好，我是小打卡的前端负责人金轩正，今天分享的主题是如何基于微信原生构建应用级小程序底层架构，这个命题看上去好像有些大，不过不要紧，这次分享我把它拆一下，大致从 小程序原生开发面临的问题 小打卡整体架构演进 开发中摸索与实践 这三个方面来看这个讲一下 [图片]                                            小程序原生开发面临的问题[图片]                                            ok，首先第一个方面原生开发遇到的问题 小程序从17年诞生2年来一直处于互联网风口，不过对于开发者而言的整个开发体验不是特别友好，在17-18年之间我和很多开发小程序的小伙伴们聊过，大多数的反馈可能分为下面大致几类，当然还有更多: 没有父类，无法使用继承挂载全局方法，扩展生命周期没有父类，无法使用继承挂载全局方法，扩展生命周期 不支持跨页面/多页面通讯 setData的性能瓶颈 代码包大小限制 1/2/4/8 M，没有npm包 代码发布流程繁琐 其根本原因是将刚刚诞生的小程序与已经非常成熟的React，vue，angular作对比，而没有将小程序作为一个新的生态来看待，当然这个是一种看待事物的进步，并不是倒退，我在这里说这句话的意思是有更多的问题需要我们开发者主动去解决问题，推动整个生态的前进与发展 [图片]                                            其实这里可能有些朋友会问，已经有很多优秀的框架已经解决了这些问题，那么为什么还要使用原生开发？ 确实在这段时间内出现了很多优秀的解决方案，我们不用并不是因为情怀哈（当然还是有那么一丢丢） 更多的是下面几点： 历史包袱，改造成本过高  小打卡在小程序刚出现的时候就进入开发了，当时框架还不成熟，而且对创业公司来说时间和迭代效率高于一切，在人手不足，业务模式尚未形成，还处于探索阶段的情况下花费大量时间去做对产品影响较小, 甚至delay迭代速度事情不是很赚 减少与第三方沟通成本 高速迭代的情况下，将时间尽可能的覆盖于业务上，避免在整个开发-上线闭环上增加节点 避免开发黑盒，控制风险 虽然整个社区是非常活跃的，fixed一个问题同样是需要花费一定时间，但是很多时候需求是不会等你bug fixed 如非必要，勿增实体 即“简单有效原理”，这句话还是我去年刚来公司的时候和阿赖聊他所说过的 放在项目开发上我的理解是在架构层面要做的尽可能的薄，避免过度设计 这样才有足够的扩展性，灵活性，容错性 这些框架虽好，但是对我们当前业务来说可能过于复杂，比如跨端在之前的阶段还没有这方面需求，而像组件化小程序已经支持，自动化构建我们自己也是可以搭建的并不复杂 相信微信小程序团队 是真正的想把这件事情做好，而且做的是一个生态，不论是小程序对于反馈响应速度，和迭代速度非常给力，还是对开发者社区运营，比如是社区活跃与审核速度挂钩，社区周刊，优质个人和优质企业 对齐web标准，并且更加开放 [图片]                                            小打卡整体架构演进其实小打卡整个架构并非一蹴而就的，就像前面所说的如非必要，勿增实体，而是大量的实际开发中遇到的共同问题解决方案的集合题 [图片]                                            常规架构这个是微信小程序给出的快速开发模版的一个开发模式： server模块提供数据，App作为全局对象直连所有的业务模块，工具函数提供api处理业务模块的需求 优点： 整个模型非常简单，上手快，学习成本 低结构清晰，在业务不复杂的情况下可以快速开发 不瞒大家其实小打卡在最初的半年内基本都是这套模式。 当然是在业务不复杂的情况下，复杂情况下会出现哪些问题呢？ App作为全局对象在有大量业务模块连接的情况下，代码很容易膨胀，在多人开发的时候问题非常明显，无论是fixed bug还是正常的业务开发都会造成麻烦 页面之间独立，缺少公共模块，唯一的工具函数又要尽可能保持单一职责来提供服务（小打卡当时就是因为这个问题导致很多工具函数内部存储直接修改外部状态，导致大量强耦函数合无法拆分） 业务层直连server层，未拆分数据层的情况下，基本不存在复用性 上面所述的问题，从我接手这个项目到真正的调整持续了挺长一段时间，主要是缺乏一个契机来进行优化 优化的转折点 [图片]                                            然后突然有一天产品同学跑过来说： 我们要有自己的核心数据仓库，我们要看实时数据 ok，涉及到数据采集的问题了，我这边从浅到深大概列了几项： 最基础的多个页面pv，uv如何监控，不可能每个页面都要手动收集  为了统计页面和事件的分享和回流的数据，需要在分享事件携带大量的参数 微信的wx.previewImage, wx.chooseImage 等api对于用户session的收集造成很大麻烦 我们先解决第一个问题，如何收集页面pv，uv 容易陷入的误区 [图片]                                            在解决问题之前，我们先说一下开发小程序容易进入的误区 App 和 Page 等函数工厂是微信原生提供，不可修改 小程序项目结构是基于App, Page, 工具函数三个模块构建的 小程序的全局存储只有globalData和本地缓存 其实产生这些误区最根本的原因是小程序没有提供在复杂业务逻辑下的开发范式，比如vue，react有自己的通用开发模版 如果保持这些观念来进行开发的话，很容易将路子走窄，并且难以解决一些实际上的问题， 其实不论小程序和传统web有多少不同， 本质上还是在js环境下开发 小打卡架构图解 [图片]                                            为了更好的方便理解后面的具体实现，我提前放了一张目前小打卡的架构图 首先很熟悉的server这一边垫了一个数据层，主要将数据层和业务层解耦，提高复用性，并且提供一些通用功能，比如返回格式化数据问题，参数校验，日志监控... 在App对象和业务层同样增加了一个全局模块，提供独立于业务和工具类，只提供api之间双向通讯的渠道 工具模块的话其实就是对业务层的增强，比如常见的请求模块，上传模块，路由拦截等等 业务模块的话基本除了增加Component和中间层外没有太大变化 这个图上可能有两块可能大家觉得比较怪异，一个是global里面的函数重载，还有一个是业务模块的中间层是什么？ 函数重载其实就是修改微信提供的App, Page, Component函数，使其更符合我们的业务场景， 业务模块的中间层就是依赖于函数重载的扩展 其实小打卡的整套架构都是基于这两个模块，这两个模块赋予了更多的可能性，然而实现却十分的简单 点击查看：小打卡 | 如何基于微信原生构建应用级小程序底层架构（下）

#### 背景介绍 在各种小程序中，我们经常会遇到 这种情况 有一个 列表，点击列表中的一项进入详情，详情有个按钮，删除了这一项，这个时候当用户返回到列表页时, 发现列表中的这一项依然存在，这种情况，就是一个 `bug`，也就是数据不同步问题，这个时候测试小姐姐 肯定会找你，让你解决，这个时候，你也许会很快速的解决，但过一会儿，测试小姐姐又来找你说，我打开了 四五个页面更改了用户状态，但我一层一层返回到首页，发现有好几个页面数据没有刷新，也是一个 bug， 这个时候你就犯愁了，怎么解决，常规方法有下面几种 #### 解决方法     1. 将所有请求放到 生命周期 `onShow` 中，只要我们页面重新显示，就会重新请求，数据也会刷新     2. 通过用 `getCurrentPages` 获取页面栈，然后找到对应的 页面实例，调用实例方法，去刷新数据     3. 通过设置一个全局变量，例如 App.globalData.xxx，通过改变这个变量的值，然后在对应 onShow        中检查，如果值已改变，刷新数据     4. 在打开详情页时，使用 redirectTo 而不是 navigateTo，这样在打开新的页面时，会销毁当前页面，        返回时就不会回到这个里面，自然也不会有数据不同步问题    #### 存在的问题 1. 假如我们将 所有 请求放到 onShow 生命周期中，自然能解决所有数据刷新问题，但是 onShow 这个生命周期，有两个问题 第一个问题，它其实是在 onLoad 后面执行的，也就是说，假如请求耗时相同，从它发起请求到页面渲染， 会比 onLoad 慢 第二个问题，那就是页面隐藏、调用微信分享、锁频等等都会触发执行，请求放置于 `onShow` 中就会造成 大量不需要的请求，造成服务器压力，多余的资源浪费、也会造成用户体验不好的问题 2. 通过 `getCurrentPages` 获取页面栈，然后找到对应的 页面实例，调用实例方法，去刷新数据，这也 不失为一个办法，但是就如微信官方文档所说 > 不要尝试修改页面栈，会导致路由以及页面状态错误。 > 不要在 App.onLaunch 的时候调用 `getCurrentPages()`，此时 page 还没有生成。 同时、当需要通信的页面有两个、三个、多个呢，这里去使用 `getCurrentPages` 就会比较困难、繁琐 3. 通过设置全局变量的方法，当需要使用的地方比较少时，可以接受，当使用的地方多的时候，维护起来 就会很困难，代码过于臃肿，也会有很多问题 4. 使用 redirectTo 而不是 navigateTo，从用来体验来说，很糟糕，并且只存在一个页面，对于 tab 页面，它也无能为力，不推荐使用 #### 最佳实践 在 Vue 中， 可以通过 new Vue() 来实现一个 event bus作为事件总线，来达到事件通知的功能，在各大 框架中，也有自身的事件机制实现，那么我们完全可以通过同样的方法，实现一个事件中心，来管理我们的事件， 同时，解决我们的问题。iny-bus 就是这样一个及其轻量的事件库,使用 typescript 编写，100% 测试覆 盖率，能运行 js 的环境，就能使用 传送门 [源码](https://github.com/landluck/iny-bus) [NPM](https://www.npmjs.com/package/iny-bus) [文档](https://landluck.github.io/iny-bus/docs/) #### 简单使用 iny-bus 使用及其简单，在需要的页面 onLoad 中添加事件监听， 在需要触发事件的地方派发事件，使监 听该事件的每个页面执行处理函数，达到通信和刷新数据的目的，在小程序中的使用可以参考以下代码 [代码]   // 小程序[代码] [代码]   import bus from [代码][代码]'iny-bus'[代码]   [代码]   // 添加事件监听[代码] [代码]   // 在 onLoad 中注册, 避免在 onShow 中使用[代码] [代码]    onLoad () {[代码] [代码]      this[代码][代码].eventId = bus.on([代码][代码]'事件名'[代码][代码], (a, b, c, d) => {[代码] [代码]      // 支持多参数[代码] [代码]      console.log(a, b, c, d)[代码]   [代码]      this[代码][代码].setData({ a [代码]}) [代码]      // 调用页面请求函数，刷新数据[代码] [代码]      this[代码][代码].refreshPageData()[代码] [代码]    })[代码]   [代码]    // 添加只需要执行一次的 事件监听[代码]   [代码]    this[代码][代码].eventIdOnce = bus.once([代码][代码]'事件名'[代码][代码], () => {[代码] [代码]      // do some thing[代码] [代码]     })[代码] [代码]   }[代码]   [代码]   // 移除事件监听，该函数有两个参数，第二个事件id不传，会移除整个事件监听，传入ID，会移除该[代码] [代码]   // 页面的事件监听，避免多余资源浪费, 在添加事件监[代码][代码]/// 听后，页面卸载(onUnload)时建议移除[代码]   [代码]   onUnload () {[代码] [代码]     bus.remove([代码][代码]'事件名'[代码][代码], [代码][代码]this[代码][代码].eventId)[代码] [代码]   }[代码]   [代码]   // 派发事件，触发事件监听处更新视图[代码] [代码]  // 支持多参传递[代码] [代码]  onClick () {[代码] [代码]    bus.emit([代码][代码]'事件名'[代码][代码], a, b, c)[代码] [代码]  }[代码] 更详细的使用和例子可以参考 [Github iny-bus 小程序代码](https://github.com/landluck/iny-bus/tree/master/examples) #### iny-bus 具体实现 * 基本打包工具，这里使用非常优秀的开源库 [typescript-library-starter](https://github.com/alexjoverm/typescript-library-starter)，具体细节不展开 * 测试工具 使用 facebook 的 [jest](https://github.com/facebook/jest) * build ci 使用 [travis-ci](https://www.travis-ci.org/） * 测试覆盖率上传使用 [codecov](https://codecov.io/) * 具体的其他细节大家可以看源码中的 [package.json](https://github.com/landluck/iny-bus/blob/master/package.json)，这里就一一展开讲了 iny-bus 的核心代码，其实就这么多，总的来说，非常少，但是能解决我们在小程序中遇到的大量 通信 和 数据刷新问题，是采用 各大平台小程序 原生开发时，页面通信的不二之选，同时，100% 的测试覆盖率，确保了 iny-bus 在使用中的稳定性和安全性，当然，每个库都是从简单走向复杂，功能慢慢完善，如果 大家在使用或者源码中发现了bug或者可以优化的点，欢迎大家提 pr 或者直接联系我 最后，如果 iny-bus 给你提供了帮助或者让你有任何收获，请给 作者 点个赞，感谢大家 [点赞](https://github.com/landluck/iny-bus)

由于我们无法将小程序直接分享到朋友圈，但分享到朋友圈的需求又很多，业界目前的做法是利用小程序的 Canvas 功能生成一张带有小程序码的图片，然后引导用户下载图片到本地后再分享到朋友圈。相信大家在绘制分享图中应该踩到 Canvas 的各种（坑）彩dan了吧～ 这里首先推荐一个开源的组件：painter（通过该组件目前我们已经成功在支付宝小程序上也应用上了分享图功能） 咱们不多说，直接上手就是干。 [图片] 首先我们新增一个自定义组件，在该组件的json中引入painter [代码]{ "component": true, "usingComponents": { "painter": "/painter/painter" } } [代码] 然后组件的WXML (代码片段在最后) [代码]// 将该组件定位在屏幕之外，用户查看不到。 <painter style="position: absolute; top: -9999rpx;" palette="{{imgDraw}}" bind:imgOK="onImgOK" /> [代码] 重点来了 JS (代码片段在最后) [代码]Component({ properties: { // 是否开始绘图 isCanDraw: { type: Boolean, value: false, observer(newVal) { newVal && this.handleStartDrawImg() } }, // 用户头像昵称信息 userInfo: { type: Object, value: { avatarUrl: '', nickName: '' } } }, data: { imgDraw: {}, // 绘制图片的大对象 sharePath: '' // 生成的分享图 }, methods: { handleStartDrawImg() { wx.showLoading({ title: '生成中' }) this.setData({ imgDraw: { width: '750rpx', height: '1334rpx', background: 'https://qiniu-image.qtshe.com/20190506share-bg.png', views: [ { type: 'image', url: 'https://qiniu-image.qtshe.com/1560248372315_467.jpg', css: { top: '32rpx', left: '30rpx', right: '32rpx', width: '688rpx', height: '420rpx', borderRadius: '16rpx' }, }, { type: 'image', url: this.data.userInfo.avatarUrl || 'https://qiniu-image.qtshe.com/default-avatar20170707.png', css: { top: '404rpx', left: '328rpx', width: '96rpx', height: '96rpx', borderWidth: '6rpx', borderColor: '#FFF', borderRadius: '96rpx' } }, { type: 'text', text: this.data.userInfo.nickName || '青团子', css: { top: '532rpx', fontSize: '28rpx', left: '375rpx', align: 'center', color: '#3c3c3c' } }, { type: 'text', text: `邀请您参与助力活动`, css: { top: '576rpx', left: '375rpx', align: 'center', fontSize: '28rpx', color: '#3c3c3c' } }, { type: 'text', text: `宇宙最萌蓝牙耳机测评员`, css: { top: '644rpx', left: '375rpx', maxLines: 1, align: 'center', fontWeight: 'bold', fontSize: '44rpx', color: '#3c3c3c' } }, { type: 'image', url: 'https://qiniu-image.qtshe.com/20190605index.jpg', css: { top: '834rpx', left: '470rpx', width: '200rpx', height: '200rpx' } } ] } }) }, onImgErr(e) { wx.hideLoading() wx.showToast({ title: '生成分享图失败，请刷新页面重试' }) //通知外部绘制完成，重置isCanDraw为false this.triggerEvent('initData') }, onImgOK(e) { wx.hideLoading() // 展示分享图 wx.showShareImageMenu({ path: e.detail.path, fail: err => { console.log(err) } }) //通知外部绘制完成，重置isCanDraw为false this.triggerEvent('initData') } } }) [代码] 那么我们该如何引用呢？ 首先json里引用我们封装好的组件share-box [代码]{ "usingComponents": { "share-box": "/components/shareBox/index" } } [代码] 以下示例为获取用户头像昵称后再生成图。 [代码]<button class="intro" bindtap="getUserInfo">点我生成分享图</button> <share-box isCanDraw="{{isCanDraw}}" userInfo="{{userInfo}}" bind:initData="handleClose" /> [代码] 调用的地方： [代码]const app = getApp() Page({ data: { isCanDraw: false }, // 组件内部关掉或者绘制完成需重置状态 handleClose() { this.setData({ isCanDraw: !this.data.isCanDraw }) }, getUserInfo(e) { wx.getUserProfile({ desc: "获取您的头像昵称信息", success: res => { const { userInfo = {} } = res this.setData({ userInfo, isCanDraw: true // 开始绘制海报图 }) }, fail: err => { console.log(err) } }) } }) [代码] 最后绘制分享图的自定义组件就完成啦~效果图如下： [图片] tips： 文字居中实现可以看下代码片段 文字换行实现（maxLines）只需要设置宽度，maxLines如果设置为1，那么超出一行将会展示为省略号 代码片段：https://developers.weixin.qq.com/s/J38pKsmK7Qw5 附上painter可视化编辑代码工具：点我直达，因为涉及网络图片，代码片段设置不了downloadFile合法域名，建议真机开启调试模式，开发者工具 详情里开启不校验合法域名进行代码片段的运行查看。 最后看下面大家评论问的较多的问题：downLoadFile合法域名在小程序后台 开发>开发设置里配置，域名为你图片的域名前缀 比如我文章里的图https://qiniu-image.qtshe.com/20190605index.jpg。配置域名时填写https://qiniu-image.qtshe.com即可。如果你图片cdn地址为https://aaa.com/xxx.png, 那你就配置https://aaa.com即可。