作者：jrainlau 原文：在小程序中实现 Mixins 方案 Fundebug经授权转载，版权归原作者所有。 在原生开发小程序的过程中，发现有多个页面都使用了几乎完全一样的逻辑。由于小程序官方并没有提供 Mixins 这种代码复用机制，所以只能采用非常不优雅的复制粘贴的方式去“复用”代码。随着功能越来越复杂，靠复制粘贴来维护代码显然不科学，于是便寻思着如何在小程序里面实现 Mixins。 什么是 Mixins Mixins 直译过来是“混入”的意思，顾名思义就是把可复用的代码混入当前的代码里面。熟悉 VueJS 的同学应该清楚，它提供了更强大了代码复用能力，解耦了重复的模块，让系统维护更加方便优雅。 先看看在 VueJS 中是怎么使用 Mixins 的。 [代码]// define a mixin object var myMixin = { created: function () { this.hello() }, methods: { hello: function () { console.log('hello from mixin!') } } } // define a component that uses this mixin var Component = Vue.extend({ mixins: [myMixin] }) var component = new Component() // => "hello from mixin!" [代码] 在上述的代码中，首先定义了一个名为 [代码]myMixin[代码] 的对象，里面定义了一些生命周期函数和方法。接着在一个新建的组件里面直接通过 [代码]mixins: [myMixin][代码] 的方式注入，此时新建的组件便获得了来自 [代码]myMixin[代码] 的方法了。 明白了什么是 Mixins 以后，便可开始着手在小程序里面实现了。 Mixins 的机制 Mixins 也有一些小小的细节需要注意的，就是关于生命周期事件的执行顺序。在上一节的例子中，我们在 [代码]myMixin[代码] 里定义了一个 [代码]created()[代码] 方法，这是 VueJS 里面的一个生命周期事件。如果我们在新建组件 [代码]Component[代码] 里面也定义一个 [代码]created()[代码] 方法，那么执行结果会是如何呢？ [代码]var Component = Vue.extend({ mixins: [myMixin], created: function () { console.log('hello from Component!') } }) var component = new Component() // => // Hello from mixin! // Hello from Component! [代码] 可以看运行结果是先输出了来自 Mixin 的 log，再输出来自组件的 log。 除了生命周期函数以外，再看看对象属性的混入结果： [代码]// define a mixin object const myMixin = { data () { return { mixinData: 'data from mixin' } } } // define a component that uses this mixin var Component = Vue.extend({ mixins: [myMixin], data () { return { componentData: 'data from component' } }, mounted () { console.log(this.$data) } }) var component = new Component() [代码] [图片] 在 VueJS 中，会把来自 Mixins 和组件的对象属性当中的内容（如 [代码]data[代码], [代码]methods[代码]等）混合，以确保两边的数据都同时存在。 经过上述的验证，我们可以得到 VueJS 中关于 Mixins 运行机制的结论： 生命周期属性，会优先执行来自 Mixins 当中的，后执行来自组件当中的。 对象类型属性，来自 Mixins 和来自组件中的会共存。 但是在小程序中，这套机制会和 VueJS 的有一点区别。在小程序中，自定义的方法是直接定义在 Page 的属性当中的，既不属于生命周期类型属性，也不属于对象类型属性。为了不引入奇怪的问题，我们为小程序的 Mixins 运行机制多加一条： 小程序中的自定义方法，优先级为 Page > Mixins，即 Page 中的自定义方法会覆盖 Mixins 当中的。 代码实现 在小程序中，每个页面都由 [代码]Page(options)[代码] 函数定义，而 Mixins 则作用于这个函数当中的 [代码]options[代码] 对象。因此我们实现 Mixins 的思路就有了——劫持并改写 [代码]Page[代码] 函数，最后再重新把它释放出来。 新建一个 [代码]mixins.js[代码] 文件： [代码]// 保存原生的 Page 函数 const originPage = Page Page = (options) => { const mixins = options.mixins // mixins 必须为数组 if (Array.isArray(mixins)) { delete options.mixins // mixins 注入并执行相应逻辑 options = merge(mixins, options) } // 释放原生 Page 函数 originPage(options) } [代码] 原理很简单，关键的地方在于 [代码]merge()[代码] 函数。[代码]merge[代码] 函数即为小程序 Mixins 运行机制的具体实现，完全按照上一节总结的三条结论来进行。 [代码]// 定义小程序内置的属性/方法 const originProperties = ['data', 'properties', 'options'] const originMethods = ['onLoad', 'onReady', 'onShow', 'onHide', 'onUnload', 'onPullDownRefresh', 'onReachBottom', 'onShareAppMessage', 'onPageScroll', 'onTabItemTap'] function merge (mixins, options) { mixins.forEach((mixin) => { if (Object.prototype.toString.call(mixin) !== '[object Object]') { throw new Error('mixin 类型必须为对象！') } // 遍历 mixin 里面的所有属性 for (let [key, value] of Object.entries(mixin)) { if (originProperties.includes(key)) { // 内置对象属性混入 options[key] = { ...value, ...options[key] } } else if (originMethods.includes(key)) { // 内置方法属性混入，优先执行混入的部分 const originFunc = options[key] options[key] = function (...args) { value.call(this, ...args) return originFunc && originFunc.call(this, ...args) } } else { // 自定义方法混入 options = { ...mixin, ...options } } } }) return options } [代码] Mixins 使用 在小程序的 [代码]app.js[代码] 里引入 [代码]mixins.js[代码] [代码]require('./mixins.js') [代码] 撰写一个 [代码]myMixin.js[代码] [代码]module.exports = { data: { someData: 'myMixin' }, onShow () { console.log('Log from mixin!') } } [代码] 在 [代码]page/index/index.js[代码] 中使用 [代码]Page({ mixins: [require('../../myMixin.js')] }) [代码] [图片] 大功告成！此时小程序已经具备 Mixins 的能力，对于代码解耦与复用来说将会更加方便。

小程序开发另类小技巧 --用户授权篇 getUserInfo较为特殊，不包含在本文范围内，主要针对需要授权的功能性api，例如：wx.startRecord，wx.saveImageToPhotosAlbum， wx.getLocation 原文地址：https://www.yuque.com/jinxuanzheng/gvhmm5/arexcn 仓库地址：https://github.com/jinxuanzheng01/weapp-auth-demo 背景 小程序内如果要调用部分接口需要用户进行授权，例如获取地理位置信息，收获地址，录音等等，但是小程序对于这些需要授权的接口并不是特别友好，最明显的有两点： 如果用户已拒绝授权，则不会出现弹窗，而是直接进入接口 fail 回调， 没有统一的错误信息提示，例如错误码 一般情况而言，每次授权时都应该激活弹窗进行提示，是否进行授权，例如： [图片] 而小程序内只有第一次进行授权时才会主动激活弹窗（微信提供的），其他情况下都会直接走fail回调，微信文档也在句末添加了一句请开发者兼容用户拒绝授权的场景, 这种未做兼容的情况下如果用户想要使用录音功能，第一次点击拒绝授权，那么之后无论如何也无法再次开启录音权限**，很明显不符合我们的预期。 所以我们需要一个可以进行二次授权的解决方案 常见处理方法 官方demo 下面这段代码是微信官方提供的授权代码, 可以看到也并没有兼容拒绝过授权的场景查询是否授权（即无法再次调起授权） [代码]// 可以通过 wx.getSetting 先查询一下用户是否授权了 "scope.record" 这个 scope wx.getSetting({ success(res) { if (!res.authSetting['scope.record']) { wx.authorize({ scope: 'scope.record', success () { // 用户已经同意小程序使用录音功能，后续调用 wx.startRecord 接口不会弹窗询问 wx.startRecord() } }) } } }) [代码] 一般处理方式 那么正常情况下我们该怎么做呢？以地理位置信息授权为例： [代码]wx.getLocation({ success(res) { console.log('success', res); }, fail(err) { // 检查是否是因为未授权引起的错误 wx.getSetting({ success (res) { // 当未授权时直接调用modal窗进行提示 !res.authSetting['scope.userLocation'] && wx.showModal({ content: '您暂未开启权限，是否开启', confirmColor: '#72bd4a', success: res => { // 用户确认授权后，进入设置列表 if (res.confirm) { wx.openSetting({ success(res){ // 查看设置结果 console.log(!!res.authSetting['scope.userLocation'] ? '设置成功' : '设置失败'); }, }); } } }); } }); } }); [代码] 上面代码，有些同学可能会对在fail回调里直接使用wx.getSetting有些疑问，这里主要是因为 微信返回的错误信息没有一个统一code errMsg又在不同平台有不同的表现 从埋点数据得出结论，调用这些api接口出错率基本集中在未授权的状态下 这里为了方便就直接调用权限检查了 ，也可以稍微封装一下，方便扩展和复用，变成： [代码] bindGetLocation(e) { let that = this; wx.getLocation({ success(res) { console.log('success', res); }, fail(err) { that.__authorization('scope.userLocation'); } }); }, bindGetAddress(e) { let that = this; wx.chooseAddress({ success(res) { console.log('success', res); }, fail(err) { that.__authorization('scope.address'); } }); }, __authorization(scope) { /** 为了节省行数，不细写了，可以参考上面的fail回调，大致替换了下变量res.authSetting[scope] **/ } [代码] 看上去好像没有什么问题，fail里只引入了一行代码， 这里如果只针对较少页面的话我认为已经够用了，毕竟**‘如非必要，勿增实体’，但是对于小打卡这个小程序来说可能涉及到的页面，需要调用的场景偏多**，我并不希望每次都人工去调用这些方法，毕竟人总会犯错 梳理目标 上文已经提到了背景和常见的处理方法，那么梳理一下我们的目标，我们到底是为了解决什么问题？列了下大致为下面三点： 兼容用户拒绝授权的场景，即提供二次授权 解决多场景，多页面调用没有统一规范的问题 在底层解决，业务层不需要关心二次授权的问题 扩展wx[funcName]方法 为了节省认知成本和减少出错概率，我希望他是这个api默认携带的功能，也就是说因未授权出现错误时自动调起是否开启授权的弹窗 为了实现这个功能，我们可能需要对wx的原生api进行一层包装了（关于页面的包装可以看：如何基于微信原生构建应用级小程序底层架构） 为wx.getLocation添加自己的方法 这里需要注意的一点是直接使用常见的装饰模式是会出现报错，因为wx这个对象在设置属性时没有设置set方法，这里需要单独处理一下 [代码]// 直接装饰，会报错 Cannot set property getLocation of #<Object> which has only a getter let $getLocation = wx.getLocation; wx.getLocation = function (obj) { $getLocation(obj); }; // 需要做一些小处理 wx = {...wx}; // 对wx对象重新赋值 let $getLocation = wx.getLocation; wx.getLocation = function (obj) { console.log('调用了wx.getLocation'); $getLocation(obj); }; // 再次调用时会在控制台打印出 '调用了wx.getLocation' 字样 wx.getLocation() [代码] 劫持fail方法 第一步我们已经控制了wx.getLocation这个api，接下来就是对于fail方法的劫持，因为我们需要在fail里加入我们自己的授权逻辑 [代码]// 方法劫持 wx.getLocation = function (obj) { let originFail = obj.fail; obj.fail = async function (errMsg) { // 0 => 已授权 1 => 拒绝授权 2 => 授权成功 let authState = await authorization('scope.userLocation'); // 已授权报错说明并不是权限问题引起，所以继续抛出错误 // 拒绝授权，走已有逻辑，继续排除错误 authState !== 2 && originFail(errMsg); }; $getLocation(obj); }; // 定义检查授权方法 function authorization(scope) { return new Promise((resolve, reject) => { wx.getSetting({ success (res) { !res.authSetting[scope] ? wx.showModal({ content: '您暂未开启权限，是否开启', confirmColor: '#72bd4a', success: res => { if (res.confirm) { wx.openSetting({ success(res){ !!res.authSetting[scope] ? resolve(2) : resolve(1) }, }); }else { resolve(1); } } }) : resolve(0); } }) }); } // 业务代码中的调用 bindGetLocation(e) { let that = this; wx.getLocation({ type: 'wgs84', success(res) { console.log('success', res); }, fail(err) { console.warn('fail', err); } }); } [代码] 可以看到现在已实现的功能已经达到了我们最开始的预期，即因授权报错作为了wx.getLocation默认携带的功能，我们在业务代码里再也不需要处理任何再次授权的逻辑 也意味着wx.getLocation这个api不论在任何页面，组件，出现频次如何，**我们都不需要关心它的授权逻辑（**效果本来想贴gif图的，后面发现有图点大，具体效果去git仓库跑一下demo吧） 让我们再优化一波 上面所述大致是整个原理的一个思路，但是应用到实际项目中还需要考虑到整体的扩展性和维护成本，那么就让我们再来优化一波 代码包结构： 本质上只要在app.js这个启动文件内，引用./x-wxx/index文件对原有的wx对象进行覆盖即可 [图片] **简单的代码逻辑： ** [代码]// 大致流程： //app.js wx = require('./x-wxx/index'); // 入口处引入文件 // x-wxx/index const apiExtend = require('./lib/api-extend')； module.exports = (function (wxx) { // 对原有方法进行扩展 wxx = {...wxx}; for (let key in wxx) { !!apiExtend[key] && (()=> { // 缓存原有函数 let originFunc = wxx[key]; // 装饰扩展的函数 wxx[key] = (...args) => apiExtend[key](...args, originFunc); })(); } return wxx; })(wx); // lib/api-extend const Func = require('./Func'); (function (exports) { // 需要扩展的api（类似于config） // 获取权限 exports.authorize = function (opts, done) { // 当调用为"确认授权方法时"直接执行，避免死循环 if (opts.$callee === 'isCheckAuthApiSetting') { console.log('optsopts', opts); done(opts); return; } Func.isCheckAuthApiSetting(opts.scope, () => done(opts)); }; // 选择地址 exports.chooseAddress = function (opts, done) { Func.isCheckAuthApiSetting('scope.address', () => done(opts)); }; // 获取位置信息 exports.getLocation = function (opts, done) { Func.isCheckAuthApiSetting('scope.userLocation', () => done(opts)); }; // 保存到相册 exports.saveImageToPhotosAlbum = function (opts, done) { Func.isCheckAuthApiSetting('scope.writePhotosAlbum', () => done(opts)); } // ...more })(module.exports); [代码] 更多的玩法 可以看到我们无论后续扩展任何的微信api，都只需要在lib/api-extend.js 配置即可，这里不仅仅局限于授权，也可以做一些日志，传参的调整，例如： [代码] // 读取本地缓存(同步) exports.getStorageSync = (key, done) => { let storage = null; try { storage = done(key); } catch (e) { wx.$logger.error('getStorageSync', {msg: e.type}); } return storage; }; [代码] 这样是不是很方便呢，至于Func.isCheckAuthApiSetting这个方法具体实现，为了节省文章行数请自行去git仓库里查看吧 关于音频授权 录音授权略为特殊，以wx.getRecorderManager为例，它并不能直接调起录音授权，所以并不能直接用上述的这种方法，不过我们可以曲线救国，达到类似的效果，还记得我们对于wx.authorize的包装么，本质上我们是可以直接使用它来进行授权的，比如将它用在我们已经封装好的录音管理器的start方法进行校验 [代码]wx.authorize({ scope: 'scope.record' }); [代码] 实际上，为方便统一管理，Func.isCheckAuthApiSetting方法其实都是使用wx.authorize来实现授权的 [代码]exports.isCheckAuthApiSetting = async function(type, cb) { // 简单的类型校验 if(!type && typeof type !== 'string') return; // 声明 let err, result; // 获取本地配置项 [err, result] = await to(getSetting()); // 这里可以做一层缓存，检查缓存的状态，如果已授权可以不必再次走下面的流程，直接return出去即可 if (err) { return cb('fail'); } // 当授权成功时，直接执行 if (result.authSetting[type]) { return cb('success'); } // 调用获取权限 [err, result] = await to(authorize({scope: type, $callee: 'isCheckAuthApiSetting'})); if (!err) { return cb('success'); } } [代码] 关于用户授权 用户授权极为特殊，因为微信将wx.getUserInfo升级了一版，没有办法直接唤起了，详见《公告》，所以需要单独处理，关于这里会拆出单独的一篇文章来写一些有趣的玩法 总结 最后稍微总结下，通过上述的方案，我们解决了最开始目标的同时，也为wx这个对象上的方法提供了统一的装饰接口（lib/api-extend文件），便于后续其他行为的操作比如埋点，日志，参数校验 还是那么一句话吧，小程序不管和web开发有多少不同，本质上都是在js环境上进行开发的，希望小程序的社区环境更加活跃，带来更多有趣的东西

背景介绍 有赞微商城包括了 PC 端、H5 端和小程序端，每个端都有绘制分享海报的需求。最早的时候我们是在每个端通过canvas API来绘制的，通过canvas绘制有很多痛点，与本文要讲的海报渲染服务做了一个对比： [图片] 正是因为这些痛点问题，有同事就提出基于Puppeteer实现一个公共的海报渲染服务，使用方只需传入海报图片的html，海报渲染服务绘制一张对应的图片作为返回结果，解决了canvas绘制的各种痛点问题。 一、Puppeteer 是什么 Puppeteer是谷歌官方团队开发的一个 Node 库，它提供了一些高级 API 来通过DevTools协议控制Headless Chrome或Chromium。通俗的说就是提供了一些 API 用来控制浏览器的行为，比如打开网页、模拟输入、点击按钮、屏幕截图等操作，通过这些 API 可以完成很多有趣的事情，比如本文要讲的海报渲染服务，它用到的就是屏幕截图的功能。 二、Puppeteer 能做什么 Puppeteer几乎能实现你能在浏览器上做的任何事情，比如： 生成页面的屏幕截图或pdf 自动化提交表单、模拟键盘输入、自动化单元测试等 网站性能分析：可以抓取并跟踪网站的执行时间轴，帮助分析效率问题 抓取网页内容，也就是我们常说的爬虫 三、海报渲染服务 3.1方案设计 首先我们来看一下海报渲染服务的流程图： [图片] 其实整个流程还是比较简单的，当有一个绘制请求时，首先看之前是否已经绘制过相同的海报了，如果绘制过，就直接从Redis里取出海报图片的 CDN 地址。如果海报未曾绘制过，则先调用Headless Chrome来绘制海报，绘制完后上传到 CDN，最后 CDN 上传完后返回 CDN 地址。整个流程的大致代码实现如下： [代码]const crypto = require('crypto'); const PuppeteerProvider = require('../../lib/PuppeteerProvider'); const oneDay = 24 * 60 * 60; class SnapshotController { /** - 截图接口 * - @param {Object} ctx 上下文 */ async postSnapshotJson(ctx) { const result = await this.handleSnapshot(); ctx.json(0, 'ok', result); } async handleSnapshot() { const { ctx } = this; const { html } = ctx.request.body; // 根据 html 做 sha256 的哈希作为 Redis Key const htmlRedisKey = crypto.createHash('sha256').update(html).digest('hex'); try { // 首先看海报是否有绘制过的 let result = await this.findImageFromCache(htmlRedisKey); // 命中缓存失败 if (!result) { result = await this.generateSnapshot(htmlRedisKey); } return result; } catch (error) { ctx.status = 500; return ctx.throw(500, error.message); } } /** - 判断kv中是否有缓存 * - @param {String} htmlRedisKey kv存储的key */ async findImageFromCache(htmlRedisKey) { } /** - 生成截图 * - @param {String} htmlRedisKey kv存储的key */ async generateSnapshot(htmlRedisKey) { const { ctx } = this; const { html, width = 375, height = 667, quality = 80, ratio = 2, type: imageType = 'jpeg', } = ctx.request.body; this.validator .required(html, '缺少必要参数 html') .required(operatorId, '缺少必要参数 operatorId'); let imgBuffer; try { imgBuffer = await PuppeteerProvider.snapshot({ html, width, height, quality, ratio, imageType }); } catch (err) { // logger } let imgUrl; try { imgUrl = await this.uploadImage(imgBuffer, operatorId); // 将海报图片存在 Redis 里 await ctx.kvdsClient.setex(htmlRedisKey, oneDay, imgUrl); } catch (err) { } return { img: imgUrl || '', type: IMAGE_TYPE_MAP.CDN, }; } /** - 上传图片到七牛 * - @param {Buffer} imgBuffer 图片buffer */ async uploadImage(imgBuffer) { // upload image to cdn and return cdn url } } module.exports = SnapshotController; [代码] 3.2遇到的问题 2.3.1 Chromium启动和执行流程 最开始一个版本我们是直接Puppeteer.launch()返回一个浏览器实例，每次绘制会用单独的一个浏览器实例，这个在使用过程中发现绘制海报会很慢，后面优化时找到了这篇文章：Puppeteer性能优化与执行速度提升，这篇文章提到了两个优化点：1. 优化Chromium启动项；2. 优化Chromium执行流程。 先说优化Chromium启动项，这个就是为了我们启动一个最小化可用的浏览器实例，其他不需要的功能都禁用掉，这样会大大提升启动速度。 [代码]const browser = await puppeteer.launch({ args: [ '–disable-gpu', '–disable-dev-shm-usage', '–disable-setuid-sandbox', '–no-first-run', '–no-sandbox', '–no-zygote', '–single-process' ] }); [代码] 再来说说浏览器的执行流程，最开始我们是每次绘制都会用单独一个浏览器，也就是一对一，这个在压测的时候发现CPU和内存飙升，最后我们改用了复用浏览器标签的方式，每次绘制新建一个标签来绘制。 [代码]const page = await browser.newPage(); page.setContent(html, { waitUntil: 'networkidle0' }); const imageBuffer = await page.screeshot(options); [代码] 3.3.2 networkidle0 最开始我们的海报服务绘制海报时有时候会偶尔出现图片展示不出来的情况，我们排查后发现是因为我们setContent时，使用的是默认的load事件来判断设置内容成功，而我们期望的是所有网络请求成功后才算设置内容成功。 [代码]page.setContent(html); [代码] Puppeteer在setContent和goto等方法里提供了一个waitUntil的参数，它就是用来配置这个判断成功的标准，它提供了四个可选值： load：默认值，load事件触发就算成功 domcontentloaded：domcontentloaded事件触发就算成功 networkidle0：在500ms内没有网络连接时就算成功 networkidle2：在500ms内有不超过2个网络连接时就算成功 我们这里需要用到的就是networkidle0： [代码]page.setContent(html, { waitUntil: 'networkidle0' }); [代码] 当改成networkidle0后，使用方给我们反馈说整个绘制服务变慢了很多，随随便便都2s以上。变慢主要是因为加上networkidle0后，至少需要等待500ms以上，加上绘制的一些其他开销，基本上就需要2s了。所以我们期望这个500ms是可配置的，因为500ms实在太长了，我们的分享海报一般只有几张图片，不需要这么久。但是Puppeteer没有提供相关的参数，还好在issue中早已经有人提出了这个问题：Control networkidle wait time [代码]function waitForNetworkIdle(page, timeout, maxInflightRequests = 0) { page.on('request', onRequestStarted); page.on('requestfinished', onRequestFinished); page.on('requestfailed', onRequestFinished); let inflight = 0; let fulfill; let promise = new Promise(x => fulfill = x); let timeoutId = setTimeout(onTimeoutDone, timeout); return promise; function onTimeoutDone() { page.removeListener('request', onRequestStarted); page.removeListener('requestfinished', onRequestFinished); page.removeListener('requestfailed', onRequestFinished); fulfill(); } function onRequestStarted() { ++inflight; if (inflight > maxInflightRequests) clearTimeout(timeoutId); } function onRequestFinished() { if (inflight === 0) return; --inflight; if (inflight === maxInflightRequests) timeoutId = setTimeout(onTimeoutDone, timeout); } } // Example await Promise.all([ page.goto('https://google.com'), waitForNetworkIdle(page, 500, 0), // equivalent to 'networkidle0' ]); [代码] 利用这个函数我们就可以传入自己想要的超时时间了。 3.2.3 Chromium定时刷新机制 为什么需要定时刷新Chromium呢？总不可能一直用同一个Chromium实例吧，万一变卡或者crash了，就会影响海报的绘制。所以我们需要定时的去刷新当前的浏览器实例。 [代码]class PuppeteerProvider { constructor() { this.browserList = []; } /** - 初始化`puppeteer`实例 */ initBrowserInstance() { Array.from({ length: browserConcurrency }, () => { this.checkBrowserInstance(); }); // 每隔30分钟刷新一下浏览器 this.refreshTimer = setTimeout(() => this.refreshOneBrowser(), thrityMinutes); } /** - 检查是否还需要浏览器实例 */ async checkBrowserInstance() { if (this.needBrowserInstance) { this.browserList.push(this.launchBrowser()); } } /** - 定时刷新浏览器 */ refreshOneBrowser() { clearTimeout(this.refreshTimer); const browserInstance = this.browserList.shift(); this.replaceBrowserInstance(browserInstance); this.checkBrowserInstance(); // 每隔30分钟刷新一下浏览器 this.refreshTimer = setTimeout(() => this.refreshOneBrowser(), thrityMinutes); } /** - 替换单个浏览器实例 * - @param {String} browserInstance 浏览器promise - @param {String} retries 重试次数，超过这个次数直接关闭浏览器 */ async replaceBrowserInstance(browserInstance, retries = 2) { const browser = await browserInstance; const openPages = await browser.pages(); // 因为浏览器会打开一个空白页，如果当前浏览器还有任务在执行，一分钟后再关闭 if (openPages && openPages.length > 1 && retries > 0) { const nextRetries = retries - 1; setTimeout(() => this.replaceBrowserInstance(browserInstance, nextRetries), oneMinute); return; } browser.close(); } launchBrowser(opts = {}, retries = 1) { return PuppeteerHelper.launchBrowser(opts).then(chrome => { return chrome; }).catch(error => { if (retries > 0) { const nextRetries = retries - 1; return this.launchBrowser(opts, nextRetries); } throw error; }); } } [代码] 这里还有一个点，我们给replaceBrowserInstance这个方法加了个重试次数的限制，当超出这个限制后不管有没有任务在进行都会关闭浏览器。这个是防止在某些特殊情况不能关闭掉浏览器，导致内存无法释放的情况。 四、展望 目前海报渲染服务的问题就是qps比较低，因为Chromium消耗最多的资源是CPU，当并发数变高时，CPU也随之变高，就会导致后面的绘制变慢。在4核8G的情况，大概是20qps左右。后面的主要精力就是如何去提升单机的qps，应该还有比较大的空间。还有就是看看能不能增加定时任务，在凌晨机器比较闲的时候提前绘制好一些常用的海报，这样当需要海报时就是直接从redis里取出来了，充分利用了机器的性能，也可以减少海报服务白天的压力。 五、相关链接： Puppeteer 性能优化与执行速度提升：https://blog.it2048.cn/article-puppeteer-speed-up/ Control networkidle wait time：https://github.com/GoogleChrome/puppeteer/issues/1353

摘要： 小程序开发必备技能啊… 原文：小程序如何生成海报分享朋友圈 作者：小白 Fundebug经授权转载，版权归原作者所有。 项目需求写完有一段时间了，但是还是想回过来总结一下，一是对项目的回顾优化等，二是对坑的地方做个记录，避免以后遇到类似的问题。 需求 利用微信强大的社交能力通过小程序达到裂变的目的，拉取新用户。 生成的海报如下： [图片] 需求分析 1、利用小程序官方提供的api可以直接分享转发到微信群打开小程序 2、利用小程序生成海报保存图片到相册分享到朋友圈，用户长按识别二维码关注公众号或者打开小程序来达到裂变的目的 实现方案 一、分析如何实现 相信大家应该都会有类似的迷惑，就是如何按照产品设计的那样绘制成海报，其实当时我也是不知道如何下手，认真想了下得通过canvas绘制成图片，这样用户保存这个图片到相册，就可以分享到朋友圈了。但是要绘制的图片上面不仅有文字还有数字、图片、二维码等且都是活的，这个要怎么动态生成呢。认真想了下，需要一点一点的将文字和数字，背景图绘制到画布上去，这样通过api最终合成一个图片导出到手机相册中。 二、需要解决的问题 二维码的动态获取和绘制（包括如何生成小程序二维码、公众号二维码、打开网页二维码） 背景图如何绘制，获取图片信息 将绘制完成的图片保存到本地相册 处理用户是否取消授权保存到相册 三、实现步骤 这里我具体写下围绕上面所提出的问题，描述大概实现的过程 ①首先创建canvas画布,我把画布定位设成负的,是为了不让它显示在页面上,是因为我尝试把canvas通过判断条件动态的显示和隐藏,在绘制的时候会出现问题,所以采用了这种方法，这里还有一定要设置画布的大小。 [代码]<canvas canvas-id="myCanvas" style="width: 690px;height:1085px;position: fixed;top: -10000px;"></canvas> [代码] ②创建好画布之后，先绘制背景图，因为背景图我是放在本地，所以获取 <canvas> 组件 canvas-id 属性，通过createCanvasContext创建canvas的绘图上下文 CanvasContext 对象。使用drawImage绘制图像到画布，第一个参数是图片的本地地址，后面两个参数是图像相对画布左上角位置的x轴和y轴，最后两个参数是设置图像的宽高。 [代码]const ctx = wx.createCanvasContext('myCanvas') ctx.drawImage('/img/study/shareimg.png', 0, 0, 690, 1085) [代码] ③创建好背景图后，在背景图上绘制头像，文字和数字。通过getImageInfo获取头像的信息，这里需要注意下在获取的网络图片要先配置download域名才能生效，具体在小程序后台设置里配置。 获取头像地址，首先量取头像在画布中的大小，和x轴Y轴的坐标，这里的result[0]是我用promise封装返回的一个图片地址 [代码]let headImg = new Promise(function (resolve) { wx.getImageInfo({ src: `${app.globalData.baseUrl2}${that.data.currentChildren.headImg}`, success: function (res) { resolve(res.path) }, fail: function (err) { console.log(err) wx.showToast({ title: '网络错误请重试', icon: 'loading' }) } }) }) let avatarurl_width = 60, //绘制的头像宽度 avatarurl_heigth = 60, //绘制的头像高度 avatarurl_x = 28, //绘制的头像在画布上的位置 avatarurl_y = 36; //绘制的头像在画布上的位置 ctx.save(); // 先保存状态 已便于画完圆再用 ctx.beginPath(); //开始绘制 //先画个圆 前两个参数确定了圆心 （x,y） 坐标 第三个参数是圆的半径 四参数是绘图方向 默认是false，即顺时针 ctx.arc(avatarurl_width / 2 + avatarurl_x, avatarurl_heigth / 2 + avatarurl_y, avatarurl_width / 2, 0, Math.PI * 2, false); ctx.clip(); //画了圆 再剪切 原始画布中剪切任意形状和尺寸。一旦剪切了某个区域，则所有之后的绘图都会被限制在被剪切的区域内 ctx.drawImage(result[0], avatarurl_x, avatarurl_y, avatarurl_width, avatarurl_heigth); // 推进去图片 [代码] 这里举个例子说下如何绘制文字，比如我要绘制如下这个“字”，需要动态获取前面字数的总宽度，这样才能设置“字”的x轴坐标，这里我本来是想通过measureText来测量字体的宽度，但是在iOS端第一次获取的宽度值不对，关于这个问题，我还在微信开发者社区提了bug，所以我想用另一个方法来实现，就是先获取正常情况下一个字的宽度值，然后乘以总字数就获得了总宽度，亲试是可以的。 [图片] [代码]let allReading = 97 / 6 / app.globalData.ratio * wordNumber.toString().length + 325; ctx.font = 'normal normal 30px sans-serif'; ctx.setFillStyle('#ffffff') ctx.fillText('字', allReading, 150); [代码] ④绘制公众号二维码，和获取头像是一样的，也是先通过接口返回图片网络地址，然后再通过getImageInfo获取公众号二维码图片信息 ⑤如何绘制小程序码，具体官网文档也给出生成无限小程序码接口，通过生成的小程序可以打开任意一个小程序页面，并且二维码永久有效，具体调用哪个小程序二维码接口有不同的应用场景，具体可以看下官方文档怎么说的，也就是说前端通过传递参数调取后端接口返回的小程序码，然后绘制在画布上（和上面写的绘制头像和公众号二维码一样的） [代码]ctx.drawImage('小程序码的本地地址', x轴, Y轴, 宽, 高) [代码] ⑥最终绘制完把canvas画布转成图片并返回图片地址 [代码] wx.canvasToTempFilePath({ canvasId: 'myCanvas', success: function (res) { canvasToTempFilePath = res.tempFilePath // 返回的图片地址保存到一个全局变量里 that.setData({ showShareImg: true }) wx.showToast({ title: '绘制成功', }) }, fail: function () { wx.showToast({ title: '绘制失败', }) }, complete: function () { wx.hideLoading() wx.hideToast() } }) [代码] ⑦保存到系统相册；先判断用户是否开启用户授权相册，处理不同情况下的结果。比如用户如果按照正常逻辑授权是没问题的，但是有的用户如果点击了取消授权该如何处理，如果不处理会出现一定的问题。所以当用户点击取消授权之后，来个弹框提示，当它再次点击的时候，主动跳到设置引导用户去开启授权，从而达到保存到相册分享朋友圈的目的。 [代码]// 获取用户是否开启用户授权相册 if (!openStatus) { wx.openSetting({ success: (result) => { if (result) { if (result.authSetting["scope.writePhotosAlbum"] === true) { openStatus = true; wx.saveImageToPhotosAlbum({ filePath: canvasToTempFilePath, success() { that.setData({ showShareImg: false }) wx.showToast({ title: '图片保存成功，快去分享到朋友圈吧~', icon: 'none', duration: 2000 }) }, fail() { wx.showToast({ title: '保存失败', icon: 'none' }) } }) } } }, fail: () => { }, complete: () => { } }); } else { wx.getSetting({ success(res) { // 如果没有则获取授权 if (!res.authSetting['scope.writePhotosAlbum']) { wx.authorize({ scope: 'scope.writePhotosAlbum', success() { openStatus = true wx.saveImageToPhotosAlbum({ filePath: canvasToTempFilePath, success() { that.setData({ showShareImg: false }) wx.showToast({ title: '图片保存成功，快去分享到朋友圈吧~', icon: 'none', duration: 2000 }) }, fail() { wx.showToast({ title: '保存失败', icon: 'none' }) } }) }, fail() { // 如果用户拒绝过或没有授权，则再次打开授权窗口 openStatus = false console.log('请设置允许访问相册') wx.showToast({ title: '请设置允许访问相册', icon: 'none' }) } }) } else { // 有则直接保存 openStatus = true wx.saveImageToPhotosAlbum({ filePath: canvasToTempFilePath, success() { that.setData({ showShareImg: false }) wx.showToast({ title: '图片保存成功，快去分享到朋友圈吧~', icon: 'none', duration: 2000 }) }, fail() { wx.showToast({ title: '保存失败', icon: 'none' }) } }) } }, fail(err) { console.log(err) } }) } [代码] 总结 至此所有的步骤都已实现，在绘制的时候会遇到一些异步请求后台返回的数据，所以我用promise和async和await进行了封装，确保导出的图片信息是完整的。在绘制的过程确实遇到一些坑的地方。比如初开始导出的图片比例大小不对，还有用measureText测量文字宽度不对，多次绘制（可能受网络原因）有时导出的图片上的文字颜色会有误差等。如果你也遇到一些比较坑的地方可以一起探讨下做个记录，下面附下完整的代码 [代码]import regeneratorRuntime from '../../utils/runtime.js' // 引入模块 const app = getApp(), api = require('../../service/http.js'); var ctx = null, // 创建canvas对象 canvasToTempFilePath = null, // 保存最终生成的导出的图片地址 openStatus = true; // 声明一个全局变量判断是否授权保存到相册 // 获取微信公众号二维码 getCode: function () { return new Promise(function (resolve, reject) { api.fetch('/wechat/open/getQRCodeNormal', 'GET').then(res => { console.log(res, '获取微信公众号二维码') if (res.code == 200) { console.log(res.content, 'codeUrl') resolve(res.content) } }).catch(err => { console.log(err) }) }) }, // 生成海报 async createCanvasImage() { let that = this; // 点击生成海报数据埋点 that.setData({ generateId: '点击生成海报' }) if (!ctx) { let codeUrl = await that.getCode() wx.showLoading({ title: '绘制中...' }) let code = new Promise(function (resolve) { wx.getImageInfo({ src: codeUrl, success: function (res) { resolve(res.path) }, fail: function (err) { console.log(err) wx.showToast({ title: '网络错误请重试', icon: 'loading' }) } }) }) let headImg = new Promise(function (resolve) { wx.getImageInfo({ src: `${app.globalData.baseUrl2}${that.data.currentChildren.headImg}`, success: function (res) { resolve(res.path) }, fail: function (err) { console.log(err) wx.showToast({ title: '网络错误请重试', icon: 'loading' }) } }) }) Promise.all([headImg, code]).then(function (result) { const ctx = wx.createCanvasContext('myCanvas') console.log(ctx, app.globalData.ratio, 'ctx') let canvasWidthPx = 690 * app.globalData.ratio, canvasHeightPx = 1085 * app.globalData.ratio, avatarurl_width = 60, //绘制的头像宽度 avatarurl_heigth = 60, //绘制的头像高度 avatarurl_x = 28, //绘制的头像在画布上的位置 avatarurl_y = 36, //绘制的头像在画布上的位置 codeurl_width = 80, //绘制的二维码宽度 codeurl_heigth = 80, //绘制的二维码高度 codeurl_x = 588, //绘制的二维码在画布上的位置 codeurl_y = 984, //绘制的二维码在画布上的位置 wordNumber = that.data.wordNumber, // 获取总阅读字数 // nameWidth = ctx.measureText(that.data.wordNumber).width, // 获取总阅读字数的宽度 // allReading = ((nameWidth + 375) - 325) * 2 + 380; // allReading = nameWidth / app.globalData.ratio + 325; allReading = 97 / 6 / app.globalData.ratio * wordNumber.toString().length + 325; console.log(wordNumber, wordNumber.toString().length, allReading, '获取总阅读字数的宽度') ctx.drawImage('/img/study/shareimg.png', 0, 0, 690, 1085) ctx.save(); // 先保存状态 已便于画完圆再用 ctx.beginPath(); //开始绘制 //先画个圆 前两个参数确定了圆心 （x,y） 坐标 第三个参数是圆的半径 四参数是绘图方向 默认是false，即顺时针 ctx.arc(avatarurl_width / 2 + avatarurl_x, avatarurl_heigth / 2 + avatarurl_y, avatarurl_width / 2, 0, Math.PI * 2, false); ctx.clip(); //画了圆 再剪切 原始画布中剪切任意形状和尺寸。一旦剪切了某个区域，则所有之后的绘图都会被限制在被剪切的区域内 ctx.drawImage(result[0], avatarurl_x, avatarurl_y, avatarurl_width, avatarurl_heigth); // 推进去图片 ctx.restore(); //恢复之前保存的绘图上下文状态 可以继续绘制 ctx.setFillStyle('#ffffff'); // 文字颜色 ctx.setFontSize(28); // 文字字号 ctx.fillText(that.data.currentChildren.name, 103, 78); // 绘制文字 ctx.font = 'normal bold 44px sans-serif'; ctx.setFillStyle('#ffffff'); // 文字颜色 ctx.fillText(wordNumber, 325, 153); // 绘制文字 ctx.font = 'normal normal 30px sans-serif'; ctx.setFillStyle('#ffffff') ctx.fillText('字', allReading, 150); ctx.font = 'normal normal 24px sans-serif'; ctx.setFillStyle('#ffffff'); // 文字颜色 ctx.fillText('打败了全国', 26, 190); // 绘制文字 ctx.font = 'normal normal 24px sans-serif'; ctx.setFillStyle('#faed15'); // 文字颜色 ctx.fillText(that.data.percent, 154, 190); // 绘制孩子百分比 ctx.font = 'normal normal 24px sans-serif'; ctx.setFillStyle('#ffffff'); // 文字颜色 ctx.fillText('的小朋友', 205, 190); // 绘制孩子百分比 ctx.font = 'normal bold 32px sans-serif'; ctx.setFillStyle('#333333'); // 文字颜色 ctx.fillText(that.data.singIn, 50, 290); // 签到天数 ctx.fillText(that.data.reading, 280, 290); // 阅读时长 ctx.fillText(that.data.reading, 508, 290); // 听书时长 // 书籍阅读结构 ctx.font = 'normal normal 28px sans-serif'; ctx.setFillStyle('#ffffff'); // 文字颜色 ctx.fillText(that.data.bookInfo[0].count, 260, 510); ctx.fillText(that.data.bookInfo[1].count, 420, 532); ctx.fillText(that.data.bookInfo[2].count, 520, 594); ctx.fillText(that.data.bookInfo[3].count, 515, 710); ctx.fillText(that.data.bookInfo[4].count, 492, 828); ctx.fillText(that.data.bookInfo[5].count, 348, 858); ctx.fillText(that.data.bookInfo[6].count, 212, 828); ctx.fillText(that.data.bookInfo[7].count, 148, 726); ctx.fillText(that.data.bookInfo[8].count, 158, 600); ctx.font = 'normal normal 18px sans-serif'; ctx.setFillStyle('#ffffff'); // 文字颜色 ctx.fillText(that.data.bookInfo[0].name, 232, 530); ctx.fillText(that.data.bookInfo[1].name, 394, 552); ctx.fillText(that.data.bookInfo[2].name, 496, 614); ctx.fillText(that.data.bookInfo[3].name, 490, 730); ctx.fillText(that.data.bookInfo[4].name, 466, 850); ctx.fillText(that.data.bookInfo[5].name, 323, 878); ctx.fillText(that.data.bookInfo[6].name, 184, 850); ctx.fillText(that.data.bookInfo[7].name, 117, 746); ctx.fillText(that.data.bookInfo[8].name, 130, 621); ctx.drawImage(result[1], codeurl_x, codeurl_y, codeurl_width, codeurl_heigth); // 绘制头像 ctx.draw(false, function () { // canvas画布转成图片并返回图片地址 wx.canvasToTempFilePath({ canvasId: 'myCanvas', success: function (res) { canvasToTempFilePath = res.tempFilePath that.setData({ showShareImg: true }) console.log(res.tempFilePath, 'canvasToTempFilePath') wx.showToast({ title: '绘制成功', }) }, fail: function () { wx.showToast({ title: '绘制失败', }) }, complete: function () { wx.hideLoading() wx.hideToast() } }) }) }) } }, // 保存到系统相册 saveShareImg: function () { let that = this; // 数据埋点点击保存学情海报 that.setData({ saveId: '保存学情海报' }) // 获取用户是否开启用户授权相册 if (!openStatus) { wx.openSetting({ success: (result) => { if (result) { if (result.authSetting["scope.writePhotosAlbum"] === true) { openStatus = true; wx.saveImageToPhotosAlbum({ filePath: canvasToTempFilePath, success() { that.setData({ showShareImg: false }) wx.showToast({ title: '图片保存成功，快去分享到朋友圈吧~', icon: 'none', duration: 2000 }) }, fail() { wx.showToast({ title: '保存失败', icon: 'none' }) } }) } } }, fail: () => { }, complete: () => { } }); } else { wx.getSetting({ success(res) { // 如果没有则获取授权 if (!res.authSetting['scope.writePhotosAlbum']) { wx.authorize({ scope: 'scope.writePhotosAlbum', success() { openStatus = true wx.saveImageToPhotosAlbum({ filePath: canvasToTempFilePath, success() { that.setData({ showShareImg: false }) wx.showToast({ title: '图片保存成功，快去分享到朋友圈吧~', icon: 'none', duration: 2000 }) }, fail() { wx.showToast({ title: '保存失败', icon: 'none' }) } }) }, fail() { // 如果用户拒绝过或没有授权，则再次打开授权窗口 openStatus = false console.log('请设置允许访问相册') wx.showToast({ title: '请设置允许访问相册', icon: 'none' }) } }) } else { // 有则直接保存 openStatus = true wx.saveImageToPhotosAlbum({ filePath: canvasToTempFilePath, success() { that.setData({ showShareImg: false }) wx.showToast({ title: '图片保存成功，快去分享到朋友圈吧~', icon: 'none', duration: 2000 }) }, fail() { wx.showToast({ title: '保存失败', icon: 'none' }) } }) } }, fail(err) { console.log(err) } }) } }, [代码]

[图片] [图片] 我们最近在绘制canvas的时候，发现在安卓手机上有时候会出现canvas绘制出来的样式会错乱的问题。 在安卓手机上点多几次都会复现。在IOS手机下没有这个问题。 [图片] 文档中的setFontSize改成了ctx.font，但是在手机上无法展示效果，文档也找不到在哪里。 [图片] 通过搜索才发现是跳转到之前的文档。但是之前的文档也没找到fillStyle这个属性，只有setFillStyle。 希望官方能解答一下这个关于canvas的问题。

大家好，以下是《王者荣耀周边商城》小程序的一些经验总结，也许能帮到你，也许也帮不到，大家看着办哈，因为时间有点早，所以文中有些实现不是最新的，最终请以官方文档说明为准，废话不多说，直接上高清无码大图。 [图片] [图片] 以上截图是之前的版本，中间做了改版，大家可以直接扫码识别体验： [图片] 项目结构 我们都知道，小程序有自己的一套实现规范，下面我们看下小程序的项目结构，如下图： [图片] 一个入口文件：app.js 一个全局样式：app.wxss 一个全局配置：app.json 页面：pages下，每个页面再按文件夹划分，每个页面4个文件 index.js：实现页面整个生命周期的控制逻辑，置顶显示时的界面交互 index.json：页面配置，一个JSON对象，详细可配置字段见这里 index.wxml：UI结构渲染，可以理解为就是html，主要支持定制标签，更多标签见这里 index.wxss：UI样式渲染，可以理解为就是css，大部分css写法都支持。 当然在4个文件基础之下，还有一些通用的功能组件支撑它们的运行。每一个页面都是这么几个文件组成，非常规范统一，并且每一部分也都限定了内部实现框架和规范，所以在多人协作的时候，产出相对也就比较规范。 注：pages里面还可以再根据模块划分子目录，孙子目录，只需要在app.json里注册时填写路径就行 以上是必须的文件和目录，而实际中我们会增加别的目录，如lib，comm和utils等等目录。 框架设计 Web开发做得多了，你就会发现，大部分工作就是取数据，渲染UI，处理交互这三件事儿，小程序也不例外，所以按照这个框架逻辑，我们基于小程序本身的框架规范又扩展和细化了下，设计了下面的这套可直接应用于项目的开发框架。 [图片] 下面我们继续详细理一下设计时的一些思路、出发点和具体的实现方式，窥其面更要知其理。 注：这里我没有直接使用第三方的框架，因为我个人觉得要学习一套技术，还是需要从原生的模式开始着手，虽然前期会比较痛苦一点，但是这些付出都是值得的，因为你一旦搞明白了本来的逻辑架构和原理，你会发现什么框架都是信手拈来，而且你也更能理解框架这样设计的优点和缺点。 工具类库 Ajax 实现了promise的封装，支持GET POST PUT和DELETE，这里设计的时候就确定为仅满足单项目通用即可，所以实现的时候融入了部分业务层面的逻辑： 接口首次格式化，兼容标准的json和var形式接口（内部有大量var形式的接口） 直接判断返回值在逻辑上是成功还是失败 针对返回未登录的情况，自动跳转登录流程 所以省去了业务调用侧的反复判断处理通用逻辑，使用更简洁。 cache 其实，小程序自带了缓存接口，有同步wx.setStorageSync，异步wx.setStorage的方法，但是实际在使用缓存的场景里，我们一般都是需要设置缓存有效时间的，本cache工具就是对小程序缓存接口的封装，实现了对缓存有效期的支持。 Model实现 model层就不用多说了，主要是把数据处理部分独立出来，便于统一服务和维护，这里重点强调下model内部的实现细节，这里有一个实现技巧可以用在其它别的地方。下面直接上代码部分。 [图片] 上面的代码我们可以看到几个关键点 1.  把参数处理和返回结果处理拆出来放到单独的处理方法里，方法名称保持统一：formatParams，formatResult 2.  同时最外层定义好默认的formatParams，formatResult，如果不做特殊处理，直接使用默认即可（建议不处理也调用下默认方法，规范流程） 3.  还有一点，model里方法命令有统一规范都是已get，add，update，del开头 这个思路其实可以运用到任何场景，特别是在没有任何限定框架的场景，我们只需要按照这个模式去实现，代码一样很清晰漂亮，比如我后面实现LOL内置竞技场道具商店的时候，就是为了减少不必要的框架冗余代码，就直接徒手写的，同样是拆分为model和view层，然后model按上面的规范实现，代码同样很清晰，强烈建议大家实践下，简单实用。 组件模式 在实现王者周边小程序的时候，官方没有开放自定义组件规范，所以我们还不能按照内置组件的实现方式来实现我们业务侧自定义的组件，但是项目里又有公共组件的需求存在，那我们不管怎样还是需要把组件独立出来，不然重复代码很蛋疼，维护成本也比较高，实际我们这里的组件实现模式还是比较简单粗暴的，我们照样把组件拆分为JS，WXML，WXSS三部分（或者只有一部分也行），然后通过不同的import方式引入到需要使用组件的page里就行。 注：虽然这里没有使用官方的自定义组件规范，但是经过自己实现这个，也能大致了解到官方的自定义组件的实现方式和原理。 JS引入：import 或者 require（建议小程序这里引入都用import，跟wxml和wxss比较统一，我对代码有点小洁癖） WXML引入：和标签 WXSS引入：@import 组件很多时候也需要处理页面交互，相应事件，而小程序的事件绑定机制决定，事件处理方法必须是挂载到当前page对象下（实际是Page()方法定义的对象，内部引用是this），而组件的实现是单独的文件，不在Page()方法里定义，那怎么办呢？我这边的实现方式是组件初始化的地方，传递当前的page对象（this）给到组件，然后组件内部的接口方法全部一次性extend到page上，同样数据也是这个道理，WXML里面的数据方法只能是data对象，组件里的数据也需要挂载到这个对象上，这里强烈建议把组件内部的数据定义为一个单独的对象挂载到data上，而不要直接挂载，如我们这里的购物车组件，实现就是下面这样： [图片] 上面setData的时候，定义了shoppingCart对象，在它里面再定义具体的购物车组件需要的数据变量，而下面Object.assign一句就是把组件的方法挂载到当前使用组件的page上面去。 另外还要注意，在WXML里插入组件模块的时候，template标签的data属性里的名称请使用上面setData的名称，比如购物车这里就是shoppingCart。 请大家现在实现的时候，使用官方标准的自定义组件规范 数据共享 小程序开发也涉及到多页面间数据共享，这里针对不同的场景有几种实现方式： 1、基于页面的数据传递：直接在navigate的url后面增加参数即可，然后在接收的页面onLoad方法里，通过参数（对象）接收即可，如下： [图片] [图片] 2、基于内存的数据共享：getApp方法，获取全局的App实例对象，可以设置存取这个实例对象属性来实现数据共享，如下： [图片] 上面这种方式，适合与启动后的短期数据共享，关闭小程序数据会丢失。 3、基于本地缓存的数据共享：可以使用上面的cache组件，也可以使用原生的缓存接口实现，这种方式是可以在小程序关闭后还存在。 4、基于后台服务的接口缓存：这个不多说，就是保持数据到服务器，多页面通过接口调用。 开发规范 详细的JS实现规范这就不讲了，这里大致列一下我们在开发的时候，我们这边简单定义的一些规范，供大家参考。 JS模块引入请使用import关键字，而非require，WXML引入模板用标签，WXSS使用@import语法，三者统一 使用 let 代替var进行变量定义，使用const定义常量，如：let goods = 1，const SEX=’男’ 所有方法和变量名称都使用小写camel模式，一般是动词+名词形式，尽量不要超过5个单词，如：getList，setBackImage 所有用到的常量的地方都使用全大写，下划线分隔的形式，如：EGG_CHE 使用this转换的地方，统一使用that，如：let that = this; 尽量使用箭头函数，可保留this指向 所有自定义方法（onLoad，onShow等系统方法除外）必须使用规范注释语法进行注释 在page和model里定义方法的时候，直接使用getList(){} 即可，中间可以不用加function关键字 小程序声明周期函数里（onLoad，onReady，onShow，onHide，onUnload等）不要直接写复杂业务逻辑，复杂业务逻辑独立成方法，这里只负责方法调用。 所有数据处理必须封装到model里面，包括url地址，参数格式化，返回结果格式化都放到model里面，在page里使用的时候，基本不用做过多数据处理，一般都直接setData皆可,model规范请参考前面的说明。 如果1个功能在超过一个地方出现，那请实现为公用组件，组件实现请参考前面的说明。 在WXML模板里，如果同时有2个循环中都使用到了同样的代码片段，请使用template的方式定义，然后直接使用即可，不能重复写. 所有地方都需要有对接口返回空数据的处理，界面上要有相应的提示和引导。 其它的可以定义规范的loading，成功失败提示等，这里不多说了. 经验分享 大家开发前，可以大致浏览下小程序的官方文档，相对比较完善，遇到问题可以先查文档，然后再去小程序社区里搜索相关帖子，一般问题都能解决，下面是我遇到的一些问题和相应的解决方案，也许你也会碰到，仅供参考。 1、setData相关经验 设置多级对象值：this.setData({‘a.b.c.d’:value}); 设置可变索引的数组值： varkey="array["+index+"].text,    data ={key: 'changed data’}; this.setData(data); 2、swiper组件 current 问题 swiper组件切换数据源以后，current属性也需要手动重置，不会默认恢复到第一帧，就可能出现当前current大于新数据源的长度，显示会出问题 3、picker-view 初始值设置无效 picker-view初始化的时候，我们都会设置数据源和初始索引值，结果发现放到一次setData里既然不生效，分成2次setData就可以了，应该是设置数据源的时间点在初始值之后了，因为setData接收的是一个hash对象，而hash对象是没有先后顺序的，所以就可能存在初始值在数据源之前设置了，当然初始值不可能生效。 [图片] 4、android 兼容性问题 从原理上我们知道，小程序本身还是基于不同的JS容器的执行的，所以由于IOS（jscore）和android（v8）上容器不一致，还是需要小程序开发者自己处理两个平台的兼容性，不过新版的微信升级后，目前ios和android的不一致的兼容性问题已经很少了，不要这里需要理解的是小程序虽然有规范，但是并没有帮我们屏蔽底层的兼容问题，我们自己需要注意。 5、cookie 的问题 我们在开发web页面的时候，肯定会使用到cookie，传递登录信息等，但是小程序本身不支持cookie，所以需要应用到cookie的地方，可以转换为参数，放到请求后面，我们上面的小程序登录态就是放到了请求参数里。 但是在调用wx.request的时候，是可以设置cookie header头的，所以如果后台接口验证的需要cookie支持，可以直接在这里设置即可，但是需要注意：android的版本的小程序会把cookie键名自动改为小写，如果后台是通过大写读取的话，可能就取不到值了，暂时还不确认新版是否已修复这个问题。 [图片] 6、https 的问题 小程序要求所有请求接口都必须是https的，而且所有的域名都需要在小程序管理后台去添加，如果碰到没有添加的情况，开发调试阶段可以在小程序开发工具的项目一栏下，把下面这句勾选，不过上线之前是一定要添加的，不然会出现本地怎么调都是好的，到了手机上就是不行。 [图片] 7、关于支付 直接使用微信支付即可，不多讲。 8、关于设计 如果有条件，小程序需要独立的产品设计和规划，照搬App或者H5版本不是最好的方案，因为小程序有自己的一套设计，交互规范，有基于微信的账号体系，消息机制等基础能力，我们都可以充分利用。 写在最后 虽然版本有些老，但是还是希望对大家有些帮助，最后建议，大家如果在开发小程序的过程中遇到问题，可以第一时间在论坛里发帖求助哈，微信官方有开发同学直接回复大家。

- 当前 Bug 的表现（可附上截图） 2个问题： 1、删除小程序，再次进入小程序之前的缓存还存在（storage）。本来删除小程序之后，该小程序的本地storage的缓存就应该没有了，但是再次小程序助手进入之后还存在 2、如果使用了开发版的小程序，然后使用线上的小程序使用，线上的小程序会使用开发版小程序的缓存。必须先手动删除开发版的缓存才能正常使用 注：不需要代码片段就可以复现，环境一样就可以

自定义组件 why 代码的复用 在起初小程序只支持 Page 的时候，就会有这样蛋疼的问题：多个页面有相同的组件，每个页面都要复制粘贴一遍，每次改动都要全局搜索一遍，还说不准哪里改漏了就出翔了。 组件化设计 在前端项目中，组件化是很常见的方式，某块通用能力的抽象和设计，是一个必备的技能。组件的管理、数据的管理、应用状态的管理，这些在我们设计的过程中都是需要去思考的。当然你也可以说我就堆代码就好了，不过一个真正的码农是不允许自己这么随便的！ 所以，组件化是现代前端必须掌握的生存技能！ 自定义组件的实现 一切都从 Virtual DOM 说起 前面《解剖小程序的 setData》有讲过，基于小程序的双线程设计，视图层（Webview 线程）和逻辑层（JS 线程）之间通信（表现为 setData），是基于虚拟 DOM 来实现数据通信和模版更新的。 自定义组件一样的双线程，所以一样滴基于 Virtual DOM 来实现通信。那在这里，Virtual DOM 的一些基本知识（包括生成 VD 对象、Diff 更新等），就不过多介绍啦~ Shadow DOM 模型 基于 Virtual DOM，我们知道在这样的设计里，需要一个框架来支撑维护整个页面的节点树相关信息，包括节点的属性、事件绑定等。在小程序里，Exparser 承担了这个角色。 前面《关于小程序的基础库》也讲过，Exparser 的主要特点包括： 基于 Shadow DOM 模型 可在纯 JS 环境中运行 Shadow DOM 是什么呢，它就是我们在写代码时候写的自定义组件、内置组件、原生组件等。Shadow DOM 为 Web 组件中的 DOM 和 CSS 提供了封装。Shadow DOM 使得这些东西与主文档的 DOM 保持分离。 简而言之，Shadow DOM 是一个 HTML 的新规范，其允许开发者封装 HTML 组件（类似 vue 组件，将 html，css，js 独立部分提取）。 例如我们定义了一个自定义组件叫[代码]<my-component>[代码]，你在开发者工具可以见到： [图片] [代码]#shadow-root[代码]称为影子根，DOM 子树的根节点，和文档的主要 DOM 树分开渲染。可以看到它在[代码]<my-component>[代码]里面，换句话说，[代码]#shadow-root[代码]寄生在[代码]<my-component>[代码]上。[代码]#shadow-root[代码]可以嵌套，形成节点树，即称为影子树（Shadow Tree）。 像这样： [图片] Shadow Tree 拼接 既然组件是基于 Shadow DOM，那组件的嵌套关系，其实也就是 Shadow DOM 的嵌套，也可称为 Shadow Tree 的拼接。 Shadow Tree 拼接是怎么做的呢？一切又得从模版引擎讲起。 我们知道，Virtual DOM 机制会将节点解析成一个对象，那这个对象要怎么生成真正的 DOM 节点呢？数据变更又是怎么更新到界面的呢？这大概就是模版引擎做的事情了。 《前端模板引擎》里有详细描述模版引擎的机制，通常来说主要有这些： DOM 节点的创建和管理：[代码]appendChild[代码]/[代码]insertBefore[代码]/[代码]removeChild[代码]/[代码]replaceChild[代码]等 DOM 节点的关系（嵌套的处理）：[代码]parentNode[代码]/[代码]childNodes[代码] 通常创建后的 DOM 节点会保存一个映射，在更新的时候取到映射，然后进行处理（通常包括替换节点、改变内容[代码]innerHTML[代码]、移动删除新增节点、修改节点属性[代码]setAttribute[代码]） 在上面的图我们也可以看到，在 Shadow Tree 拼接的过程中，有些节点并不会最终生成 DOM 节点，例如[代码]<slot>[代码]这种。 但是，常用的前端模版引擎，能直接用在小程序里吗？ 双线程的难题 自定义组件渲染流程 双线程的设计，给小程序带来了很多便利，安全性管控力都拥有了，当然什么鬼东西都可以比作一把双刃剑，双线程也不例外。 我们知道，小程序分为 Webview 和 JS 双线程，逻辑层里是没法拿到真正的 DOM 节点，也没法随便动态变更页面的。那在这种情况下，我们要怎么去使用映射来更新模版呢（因为我们压根拿不到 Webview 节点的映射）？ 所以在双线程下，其实两个线程都需要保存一份节点信息。这份节点信息怎么来的呢？其实就是我们需要在创建组件的时候，通过事件通知的方式，分别在逻辑层和视图层创建一份节点信息。 同时，视图层里的组件是有层级关系的，但是 JS 里没有怎么办？为了维护好父子嵌套等节点关系，所以我们在 逻辑层也需要维护一棵 Shadow Tree。 那么我们自定义组件的渲染流程大概是： 组件创建。 逻辑层：先是 wxml + js 生成一个 JS 对象（因为需要访问组件实例 this 呀），然后是 JS 其中节点部分生成 Virtual DOM，拼接 Shadow Tree 什么的，最后通过底层通信通知到 视图层 视图层：拿到节点信息，然后吭哧吭哧开始创建 Shadow DOM，拼接 Shadow Tree 什么的,最后生成真实 DOM，并保留下映射关系 组件更新。 这时候我们知道，不管是逻辑层，还是视图层，都维护了一份 Shadow Tree，要怎么保证他们之间保持一致呢？ 让 JS 和 Webview 的组件保持一致 为了让两边的 Shadow Tree 保持一致，可以使用同步队列来传递信息。（这样就不会漏掉啦） 同步队列可以，每次变动我们就往队列里塞东西就好了。不过这样还会有个问题，我们也知道 setData 其实在实际项目里是使用比较频繁的，要是像 Component 的 observer 里做了 setData 这类型的操作，那不是每次变动会导致一大堆的 setDate？这样通信效率会很低吧？ 所以，其实可以把一次操作里的所有 setData 都整到一次通信里，通过排序保证好顺序就好啦。 Page 和 Component Component 是 Page 的超集 事实上，小程序的页面也可以视为自定义组件。因而，页面也可以使用[代码]Component[代码]构造器构造，拥有与普通组件一样的定义段与实例方法。但此时要求对应 json 文件中包含[代码]usingComponents[代码]定义段。 来自官方文档-Component 所以，基于 Component 是 Page 的超集，那么其实组件的渲染流程、方式，其实跟页面没多大区别，应该可以一个方式去理解就差不多啦。 页面渲染 既然页面就是组件，那其实页面的渲染流程跟组件的渲染流程基本保持一致。 视图层渲染，可以参考7.4 视图层渲染说明。 结束语 其实很多新框架新工具出来的时候，经常会让人眼前一亮，觉得哇好厉害，哇好高大上。 但其实更多时候，我们需要挖掘新事物的核心，其实大多数都是在原有的事物上增加了个新视角，从不一样的视角看，看到的就不一样了呢。作为一名码农，我们要看到不变的共性，变化的趋势。