背景 业务场景需要在小程序内生成活动的分享海报，图片中的某些数据需动态展示。可行的方案有️二： 服务端合成：直接返回给前端图片URL 客户端合成：客户端利用canvas绘制 在当前业务场景下，使用客户端合成会优于服务端合成，避免造成不必要的服务器CPU浪费。 下面主要谈谈**客户端（canvas）**合成的过程。 实现思路 小程序端发起请求，获取需动态展示的数据； 利用canvas绘制画布； 导出图片保存到相册。 小技巧&那些坑 理想很丰满，现实很骨感。 实现思路很简单，然而，在实现过程中，发现会趟一些坑，也有一些小技巧，遂记录下来，以供参考。 promise化 画布的绘制依赖系统信息（自适应和优化图片清晰度）和动态数据。故画布需要在所有前置条件都准备完成时，方可绘制。为了提高代码优雅度和维护性，建议用promise化，避免回调地狱（Callback Hell）。 [代码] let promise1 = new Promise((resolve, reject) => { this.getData(resolve, reject) }); let promise2 = new Promise((resolve, reject) => { this.getSystemInfo(resolve, reject) }); Promise.all([promise1, promise2]).then(() => { this.drawCanvas() }).catch(err => { console.log(err) }); [代码] 自适应 1、为了在各个机型下保持大小自适应，需要计算出缩放比： [代码] getSystemInfo(resolve, reject) { try { const res = wx.getSystemInfoSync() //缓存系统信息 systemInfo = res //这里视觉基于iPone6(375*667)设计，2x图视觉，可以填写750，1x图视觉，可以填写375 zoom = res.windowWidth / 750 * 1 resolve() } catch (e) { // Do something when catch error reject("获取机型失败") } } [代码] 2、绘制时进行按缩放比进行缩放，如： [代码]ctx.drawImage(imgUrl, x * zoom, y * zoom, w * zoom, h * zoom) [代码] 绘制网络图片 经测试，绘制CDN图片需要先将图片下载到本地，在进行绘制： [代码]wx.downloadFile({ url: imgUrl, success: res => { if (res.statusCode === 200) { ctx.drawImage(res.tempFilePath, 326 * zoom, 176 * zoom, 14 * zoom, 14 * zoom) } } }) [代码] 绘制base64图片 因为业务上某些原因，依赖的图片数据，后端只能以base64格式返回给前端，而小程序在真机上无法直接绘制（开发工具OK）。 解决思路（存在兼容性问题，fileManager**基础库 1.9.9 **开始支持）： 1、调用fileManager.writeFile存储base64到本地； 2、绘制本地图片。 实现代码如下： [代码]// 先获得一个文件实例 fileManager = wx.getFileSystemManager() // 把图片base64格式转存到本地，用于canvas绘制 fileManager.writeFile({ filePath: `${wx.env.USER_DATA_PATH}/qrcode.png`, data: self.data.qrcode, encoding: 'base64', success: () => { //此处需先调用wx.getImageInfo，方可绘制成功 wx.getImageInfo({ src: `${wx.env.USER_DATA_PATH}/qrcode.png`, success: () => { //绘制二维码 ctx.drawImage(`${wx.env.USER_DATA_PATH}/qrcode.png`, 207 * zoom, 313 * zoom, 148 * zoom, 148 * zoom) ctx.draw() } }) } }) [代码] 保存到本地相册 wx.saveImageToPhotosAlbum这个API需用户授权，故开发者需做好拒绝授权的兼容。此处实现对拒绝授权的场景进行引导。 [代码]canvas2Img(e) { wx.getSetting({ success(res) { if (res.authSetting['scope.writePhotosAlbum'] === undefined) { //呼起授权界面 wx.authorize({ scope: 'scope.writePhotosAlbum', success() { save() } }) } else if (res.authSetting['scope.writePhotosAlbum'] === false) { //引导拒绝过授权的用户授权 wx.showModal({ title: '温馨提示', content: '需要您授权保存到相册的权限', success: res => { if (res.confirm) { wx.openSetting({ success(res) { if (res.authSetting['scope.writePhotosAlbum']) { save() } } }) } } }) } else { save() } } }) function save() { wx.canvasToTempFilePath({ x: 0, y: 0, width: 562*zoom, height: 792*zoom, destWidth: 562*zoom*systemInfo.pixelRatio, destHeight: 792*zoom*systemInfo.pixelRatio, fileType: 'png', quality: 1, canvasId: 'shareImg', success: res => { wx.saveImageToPhotosAlbum({ filePath: res.tempFilePath, success: () => { wx.showModal({ content: '保存成功', showCancel: false, confirmText: '确认' }) }, fail: res => { if (res.errMsg !== 'saveImageToPhotosAlbum:fail cancel') { wx.showModal({ content: '保存到相册失败', showCancel: false }) } } }) }, fail: () => { wx.showModal({ content: '保存到相册失败', showCancel: false }) } }) } [代码] 导出清晰图片 wx.canvasToTempFilePath有destWidth（输出的图片的宽度）和destHeight（输出的图片的高度）属性。若此处以canvas的宽高去填写的话，在高像素手机下，导出的图片会模糊。 原因：destWidth和destHeight单位是物理像素（pixel），canvas绘制的时候用的是逻辑像素（物理像素=逻辑像素 * density），所以这里如果只是使用canvas中的width和height（逻辑像素）作为输出图片的长宽的话，生成的图片width和height实际上是缩放了到canvas的 1 / density大小了，所以就显得比较模糊了。 这里应该乘以设备像素比，实现如下： [代码]wx.canvasToTempFilePath({ x: 0, y: 0, width: 562*zoom, height: 792*zoom, destWidth: 562*zoom*systemInfo.pixelRatio, destHeight: 792*zoom*systemInfo.pixelRatio, fileType: 'png', quality: 1, canvasId: 'shareImg' )} [代码] 特殊字体的绘制 研究发现，目前小程序canvas无法支持设置特殊字体，而业务生成的海报，又期望以特殊字体去呈现，最终取了个折中方案——保留数字部分的特殊样式。 实现方式为：把0-9这10个数字单独切图，用ctx.drawImage API，以图片形式去绘制。 [代码]drawNum(num, x, y, w, h) { return new Promise(function (resolve, reject) { //这里存储0-9的图片CDN链接 let numMap = [] wx.downloadFile({ url: numMap[num], success: res => { if (res.statusCode === 200) { ctx.drawImage(res.tempFilePath, x * zoom, y * zoom, w * zoom, h * zoom) resolve() } }, fail: () => { reject() } }) }) } [代码] 安卓机型图片绘制锯齿化问题 测试发现，同样的绘制方案，在安卓下，调用ctx.drawImage方法，图片会出现锯齿问题。测试还发现，原像素越高，锯齿化程度降低（但业务上使用太大像素的素材也不合理），这里需要客户端底层进行优化，目前没有找到合适的解决方案。 总结 个人觉得，目前小程序canvas就底层能力上相比web还有一些不足。所以应注意两点： 提前从业务出发，考虑当前实现的可行性，以便采取更优方案（如特殊字体，像素要求等）； 若绘制canvas导出图片是个高频场景，可参考html2canvas进行封装，以便提高效能（SelectorQuery节点查询需1.9.90以上）。 ps:之前有想过利用web-view方式，在传统网页去绘制，然后通过web-view和小程序的通信来实现的方式。时间原因，并未尝试，感兴趣同学可以尝试下。

背景 前段时间要做一系列的测试工具，需要在多平台：iOS、android、H5、公众号、小程序都实现。功能基本一样，就是在支付步骤需要区分平台，用对应的支付方式支付。本文讨论如何用一套小程序代码实现上述5个平台的开发。 效果图（左边为小程序，右边为浏览器）： [图片] omi-mp的介绍 omi-mp是腾讯前端框架omi的一个工具集，其目的是在于将小程序代码转成H5/Web，具体可以参见omi-mp的介绍Github。 omi-mp的转换并不是完全兼容小程序所有特性的，只支持了一小部分小程序API，并且存在了一些兼容特性，因此就需要开发者在开发小程序代码时，更多的以开发H5/Web的思路开发。 思路图和实现步骤 [图片] 先实现小程序代码 1.初始化omi-mp目录工程： [代码]npm i omi-cli -g omi init-mp {工程名称} cd {工程名称} npm install [代码] 2.把小程序项目拷贝到[代码]src-mp[代码]目录。 3.建议边实现小程序的过程中，不断的检验生成的H5的正确性，避免在最后阶段检验，否则如果出现问题，将不好定位，本地运行H5命令： [代码]npm start //开发 [代码] 再将小程序打包成H5/Web 打包H5/Web命令： [代码]npm run build //发布 [代码] 发布需要确认域名，修改[代码]package.json[代码]文件，修改[代码]"build": "PUBLIC_URL={发布域名} node scripts/build.js"[代码] 如果存在部分js文件丢失，可以尝试执行 [代码]gulp copyThen [代码] 公众号直接加载H5 公众号本质上也属于H5。 iOS/android App通过内嵌网页加载H5 iOS通过MKWebView加载H5。 android通过WebView加载H5。 H5和原生App的交互部分可以通过JSBridge或者URL拦截实现 小程序代码如何区分平台 综上所述，除去部分iOS/android的原生代码外，基本所有的逻辑都是放在小程序里，按不同平台实现不同逻辑，小程序可以通过UserAgent以及Dom区分： 如果Dom树不存在[代码]window[代码]或者[代码]document[代码]，为小程序平台； iOS/android App内嵌网页可以自定义特殊的UserAgent，小程序代码可以通过此来区分iOS/android App平台； 微信App内嵌浏览器的UserAgent会带入[代码]MicroMessenger/[代码]关键字，可以按此区分公众号平台； 其余为H5/Web平台； [代码]if (typeof window == 'undefined') { // 小程序 } else { if (navigator.userAgent.userAgent.indexOf('ios-app') != -1 || navigator.userAgent.userAgent.indexOf('android-app') != -1) { // iOS/android } else if (this.globalData.userAgent.indexOf('MicroMessenger/') != -1) { // 公众号 } else { // Web } } [代码] iOS/android原生代码如何桥接 1.iOS/android需要先设置特殊UserAgent让小程序代码知道是iOS/android平台 iOS: [代码]NSDictionary *dictionary = [NSDictionary dictionaryWithObjectsAndKeys:@"ios-app", @"UserAgent", nil]; [[NSUserDefaults standardUserDefaults] registerDefaults:dictionary]; [代码] android: [代码]webView.getSettings().setUserAgentString("android-app"); [代码] 2.以URL拦截为例，小程序代码在当处于iOS/android平台的情况下，可以发送特殊URL，让iOS/android原生代码处理： 小程序： [代码]if (navigator.userAgent.userAgent.indexOf('ios-app') != -1 || navigator.userAgent.userAgent.indexOf('android-app') != -1) { let url = 'app://pay?' + query; window.location.href = url; } [代码] 3.iOS/android拦截URL特殊处理 iOS: [代码]- (void)webView:(WKWebView *)webView decidePolicyForNavigationAction:(WKNavigationAction *)navigationAction decisionHandler:(void (^)(WKNavigationActionPolicy))decisionHandler { NSURL * url = navigationAction.request.URL; if ([url.absoluteString hasPrefix:@"app://pay"]) { // do something... decisionHandler(WKNavigationActionPolicyCancel); return; } decisionHandler(WKNavigationActionPolicyAllow); } [代码] android: [代码]webView.setWebViewClient(new WebViewClient(){ public boolean shouldOverrideUrlLoading(WebView view, String url) { if (url.startsWith("app://pay")) { // do something... return true; } return false; } }); [代码] omi-mp的部分缺陷和一些踩过的坑 1.目前omi-mp只支持部分小程序部分API： [代码]- wx.request - wx.navigateTo - wx.navigateBack - wx.getSystemInfo - wx.getSystemInfoSync - wx.setNavigationBarTitle - this.setData - this.triggerEvent [代码] 如果用了其他的API，那么将会在输出H5报错。 2.支持组件，但是不支持组件的函数直接调用，替代方案可以用mitt，在page和component之间用mitt消息传递。 3.如果需要同时输出H5和Web，那么需要同时绑定[代码]click[代码]和[代码]tap[代码]事件（小程序只能绑定tap，Web只能绑定click，H5两者都可以），但是同时绑定又将会造成在H5的情况下，[代码]click[代码]和[代码]tap[代码]都会回调，导致两次调用。解决办法是可以在[代码]click[代码]和[代码]tap[代码]的地方同时加上判断，避免两次调用： [代码]handleTap(e) { if (!((typeof window == 'undefined') && e.type === "tap")) { return; } else if (!((typeof window != 'undefined') && e.type === "click")) { return; } // do something... } [代码] 4.wxml不支持Object字段的遍历处理。 5.如果编译不过，那么确认下是不是wxml中存在了一些特殊关键字，与omi的重了，导致失败。 6.即便在H5的场景下也无法使用[代码]document.getElementById()[代码]。但是有替代方案，只是比较麻烦。 7.还有其它缺陷，有些忘了，待补充。 结语 omi-mp是一个不错的工具，在小程序不断变大变强的今天，能做到一套小程序代码，多端运行，降低开发成本。这里尤其感谢dntzhang的大力支持，希望omi越做越好。

技术 小程序云开发 NodeJS 开始 新建小程序云开发项目，开通云开发； 在cloudfunctions下新建Node.js云函数，命名download； 进入新建的云函数文件目录下（电脑磁盘download文件夹下），执行； 参考：https://www.npmjs.com/package/request-promise npm install request-promise 打开新建云函数index.js文件内容 [代码]// 云函数入口文件 const cloud = require('wx-server-sdk') const rp = require('request-promise'); cloud.init() // 云函数入口函数 exports.main = async(event, context) => { var options = { // 请求方式 method: 'POST', // 请求地址 uri: 'https://image.qq.com', // 请求header headers: { 'Content-type': 'application/json' }, // 是否返回完整response resolveWithFullResponse: true, // 发送的请求参数 body: { "text": event.text, "voice": event.voice }, json: true, // encoding 当请求出现问题时，可以设置此参数，尝试解决 encoding: null }; const response = await rp(options); var time = new Date(); // 请求成功返回结果，判断是否成功 // if (response.headers['content-type'] == 'audio/mpeg') { const upload = await cloud.uploadFile({ //保存文件路径 cloudPath: time.getTime() + '.jpg', //文件流 fileContent: response.body, }); return { event, upload } } [代码] 在miniprogram文件夹下的pages中新建Page，命名index，打开index.js，调用云函数 [代码]// miniprogram/pages/index/index.js Page({ /** * 生命周期函数--监听页面加载 */ onLoad: function(options) { this.downloadImg(); }, downloadImg() { wx.cloud.callFunction({ // 要调用的云函数名称 name: 'download', // 传递给云函数的参数 data: { text: that.data.text, voice: that.data.voice }, success: res => { console.log(res) } }); } }) [代码]

基本实现功能 1，小程序仿天猫超市大转盘 2，九宫格转盘抽奖 3，积分抽奖 4，抽到的积分随机生成 5，抽奖结果可以同步到服务器（小程序云开发后台） 老规矩先看效果图 [图片] 简单说一下实现原理. 我们借助js的定时器，来执行一个加法。比如我们设置一个上限300，每过一定时间执行一次，然后我们再做一个随机数，这个随机数不停的++，直到总数大于300.就代表抽奖结束。核心代码如下。 [代码] //开始抽奖 startGame: function() { if (this.data.isRunning) return this.setData({ isRunning: true }) var _this = this; var indexSelect = 0 var i = 0; var timer = setInterval(function() { indexSelect++; let randomNum = Math.floor(Math.random() * 10) * 10; //可均衡获取0到90的随机整数 i += randomNum; if (i > 300) { //去除循环 clearInterval(timer) //获奖提示 let jifen = 1; let selectNum = _this.data.indexSelect console.log("选号：" + selectNum ); if (selectNum===0) { jifen = 2; } else if (selectNum === 1) { jifen = 3; } else if (selectNum === 2) { jifen = 4; } else if (selectNum === 3) { jifen = 5; } else if(selectNum === 4) { jifen = 6; } else if(selectNum === 5) { jifen = 8; } else if (selectNum === 6) { jifen = 10; } wx.showModal({ title: '恭喜您', content: '获得了' + jifen + "积分", showCancel: false, //去掉取消按钮 success: function(res) { if (res.confirm) { _this.setData({ isRunning: false }) } } }) } indexSelect = indexSelect % 8; _this.setData({ indexSelect: indexSelect }) }, (200 + i)) } [代码] 完整源码可以加我微信，如果有关于小程序的问题，可以加我微信2501902696（备注小程序）

一、写作背景 接触小程序一年多，真实体验就是小程序开发门槛相对而言确实比较低。不过小程序的开发方式，一直是开发者吐槽的，如习惯了 Vue，React 开发的开发者经常会吐槽小程序一个 Page 必须由多个文件组成，组件化支持不完善或者说不能非常愉快的开发组件。在以前小项目中没太大感觉，从加入有赞，参与有赞微商城小程序的开发，是真切的体会到对于大型小程序项目开发的复杂性。 有赞从微信小程序内测就开始开发小程序，在不支持自定义组件的时代，只能通过 import 的形式拆分模块或实现组件。在业务复杂的页面，可能会 import 非常多的模块，而相应的 wxss 也需要 import 样式，除了操作繁琐，有时候也难免遗漏。 作为开发者，我们当然希望可以让工作更简单，更愉快，也希望改善我们的开发方式。所以希望能够更了解微信小程序框架，减少不必要的试错，于是有了一次对小程序框架的 debug 之旅。(基础库 1.9.93) 通过三周空余时间的 debug，也算对小程序框架有了一些浅显的认识，达到了最初的目的；对小程序启动，实例，运行等有了真切的体会。这篇文章记录了小程序框架的基本代码结构，启动流程，以及程序实例化过程。 本文的目的是希望把我看到的分享给对小程序感兴趣或者正在开发小程序的读者，主要解答“框架对传入的对象等到底做了什么”。 二、从启动流程一窥小程序框架细节 在开发者工具中使用 help() 方法，可以查看一些指令和方法。使用其中的 openVendor 方法可以打开微信开发者工具在小程序框架所在目录。其中以包括以基础库命名的目录和其他帮助文件，如其中有两个工具 wcc，wcsc。wcc 可把 wxml 转换为对应的 JS 函数 —— $gwx(path, global)，wcsc 可将 wxss 转换为 css。而基础库目录包括 WAService.js 和 WAWebview.js 文件。小程序框架在开发者工具中以 WAService.js 命名（WAWebview.js 不知其作用，听说在真机环境使用该文件）。 在开发中工具命令行使用 document.head 可以查看到小程序的启动流程大致如下： [图片] 以小节的方式分别介绍这些流程，小程序是如何处理的（小节编号与图中编号相同）。 1、初始化全局变量 下图是小程序启动是初始化的一些全局的变量： [图片] 那些使用“__”开头，未在文档中提及可使用变量是不建议使用的，wxAppCode 在开发者工具中分为两类值，json 类型和 wxml 类型。以 .json 结尾的，其 key 值为开发者代码中对应的 json 文件的内容，.wxml 结尾的，其 key 值为通过调用 $gwx(’./pages/example/index.wxml’) 将得到一个可执行函数，通过调用这个函数可得到一个标识节点关系的 JSON 树。 [图片] 2、加载框架（WAService.js） 使用工具对 WAService.js 进行格式化后进行 debug。可以发现小程序框架大致由： WeixinJSBridge、 NativeBuffer、 wxConsole、 WeixinWorker、 JavaScript兼容（这部分为猜测）、 Reporter、 wx、 exparser、 virtualDOM、 appServiceEngine 几部分组成。 其中除了 wx 和 WeixinJSBridge 这两个基础 API 集合， exparser, virtualDOM, appServiceEngine 这三部分作为框架的核心， appServiceEngine 提供了框架最基本的接口如 App，Page，Component； exparser 提供了框架底层的能力，如实例化组件，数据变化监听，view 层与逻辑层的交互等；而 virtualDOM 则起着链接 appServiceEngine 和 exparser 的作用，如对开发者传入 Page 方法的对象进行格式化再传入 exparser 的对应方法处理。 框架对外暴露了以下API：Behavior，App，Page，Component，getApp，getCurrentPages，definePlugin，requirePlugin，wx。 3、业务代码的加载 在小程序中，开发者的 JavaScript 代码会被打包为 [代码]define('xxx.js', function(require, module, exports, window, document, frames, self, location, navigator, localStorage, history, Caches, screen, alert, confirm, prompt, fetch, XMLHttpRequest, WebSocket, webkit, WeixinJSCore, Reporter, print, WeixinJSBridge) { 'use strict'; // your code }) [代码] 这里的 define 是在框架中定义的方法，在框架中提供了两个方法：require 和 define 用来定义和使用业务代码。其方式有些像 AMD 规范接口，通过 define 定义一个模块，使用 require 来应用一个模块。但是也有很大区别，首先 define 限制了模块可使用的其他模块，如 window，document；其次 require 在使用模块时只会传入 require 和 module，也就是说参数中的其他模块在定义的模块中都是 undefined，这也是不能在开发者工具中获取一些浏览器环境对象的原因。 在小程序中，JavaScript 代码的加载方式和在浏览器中也有些不同，其加载顺序是首先加载项目中其他 js 文件（非注册程序和注册页面的 js 文件），其次是注册程序的 app.js，然后是自定义组件 js 文件，最后才是注册页面的 js 代码。而且小程序对于在 app.js 以及注册页面的 js 代码都会加载完成后立即使用 require 方法执行模块中的程序。其他的代码则需要在程序中使用 require 方法才会被执行。 下面详细介绍了 app.js，自定义组件，页面 js 代码的处理流程。 4、加载 app.js 与注册程序 在 app.js 加载完成后，小程序会使用 require(‘app.js’) 注册程序，即对 App 方法进行调用，App 方法是对 appServiceEngine.App 方法的引用。 下图是框架对于 App 方法调用时的处理流程： [图片] App 方法根据传入的对象实例化一个 app 实例，其生命周期函数 onLaunch 和 onShow 因为使用不同的方式获取 options的参数。在有些需要根据场景值来实现需求的，或许使用 onShow 中的场景值更合适。 在实际开发过程中发现，在微信顶部唤起小程序和在小程序列表唤起的 options 也是不一样的。在该案例中通过点击分享的小程序进入后，关闭小程序，再通过不同方式进入小程序，通过顶部唤起的还是 options 的 path 属性还是分享出来的 path，但是通过列表中打开直接回到了首页，这里 App 中的 onShow 就会获取到不同的 options。 5、加载自定义组件代码以及注册自定义组件 自定义组件在 app.js 之后被加载，小程序会在这个过程中加载完所有的自定义组件（分包中自定义组件没有有测试过），并且是加载完成后自动注册，只有注册完成后才会加载下一个自定义组件的代码。 下图是框架对于 Component 方法处理流程： [图片] 图中介绍了框架如何对传入 Component 方法的对象的处理，其后面还有很多深入的对于组件实例化的步骤没有在图中表示出来，具体可以在文章最后的附件中查看。 自定义组件在小程序中越来越完善，其拥有的能力也比 Page 更强大，而后面会提到在使用自定义组件的 Page 中，Page 实例也会使用和自定义组件一样的实例化方式，也就是说，他拥有和自定义组件一样的能力。 6、加载页面代码和注册页面 加载页面代码的处理流程和加载自定义组件一样，都是加载完成后先注册页面，然后才会加载下一个页面。 下图是注册一个页面时框架对于 Page 方法的处理流程： [图片] Page 方法会根据是否使用自定义组件做不同的处理。使用自定义组件的 page 对象会被处理为和自定义组件的结构，并在页面实例化时使用不同的处理流程进行实例化。当然对于开发而言没任何不同。 从图中可以发现 Page 传入的（生命周期）代码并不会在这里被执行，可以通过下面小节了解 Page 实例化的详细过程。 7、等待页面 Ready 和 Page 实例化 还记得上面介绍的启动流程中最后一步等待页面 Ready？严格来讲是等待浏览器 Ready，小程序虽然有部分原生的组件，不过本质上还是一个 web 程序。 在小程序中切换页面或打开页面时会触发 onAppRoute 事件，小程序框架通过 wx.onAppRoute 注册页面切换的处理程序，在所有程序就绪后，以 entryPagePath 作为入口使用 appLaunch 的方式进入页面。 下图是处理导航的程序流程： [图片] 从图中可以看出页面的实例化是在进入页面时进行，下图是具体的实例化过程： [图片] 下图是最终可得到 Page 实例： [图片] 可以发现其中多了 onRouteEnd API，实际该接口不会被调用。其中以 component 标记的表示只有在使用了自定义组件时才会有的方法和属性。在前面第 5 小节提到了对于使用自定义组件的页面会按照自定义组件方式解析，这些属性和方法与自定义组件表现一致。 8、关于 setData 小程序框架是一个以数据驱动的框架，当然不能少了对他如何实现数据绑定的探索，下图是 Page 实例的 setData 执行流程： [图片] 其中 component:setData 表示使用自定义组件的 Page 实例的 setData 方法。 三、写在最后 这是一次不完全的小程序框架探索，是在微信开发工具中 debug 的结果。虽然对于实际开发没有什么太大的帮助，但是对框架如何对开发的 js 代码进行处理有了一个很明确的认识，在使用一些 js 特性时可以有明确的感知。如果你还疑惑“小程序框架对传入的对象等到底做了什么”那一定是我表达能力太差，说声对不起。 通过这一次 debug ，也给我引入了新的问题，还希望能够有更多的讨论： · 自定义组件太多启动时会耗时处理自定义组件 · 文件太多会耗时读文件 · 合理的设计分包很重要 当然最后对于框架中已有的能力，还是非常希望微信可以开放更多稳定的接口，并在文档中告知开发者，让开发变得简单一些。

今天写代码时突发奇想我要把一个列表页的，onShow，onPullDownRefresh，和onReachBottom里加载数据的事件写成一个共同的方法来调用。而三个方法的不同之处在于onShow是每次页面显示时要刷新数据，取得最新的n条数据，而onPullDownRefresh是页面下拉时也是要刷新，但不同之处在于数据刷新完成后应该停止下拉执行wx.stopPullDownRefresh();而onReachBottom是页面上拉触底时应该去取跳过已经加载到页面里的数据外的下一个n条数据。 云函数 [代码]const cloud = require('wx-server-sdk') cloud.init(); const db = cloud.database() const _ = db.command // 云函数入口函数 exports.main = async (event, context) => { const wxContext = cloud.getWXContext() switch (event.acType) { case 'add': { //插入记录固定增加操作人的openid和unionid和创建时间，其它字段由传数值来确定 event.addData.OPENID = wxContext.OPENID; event.addData.UNIONID = wxContext.UNIONID; var _createTime = db.serverDate(); event.addData.createTime = _createTime; return db.collection(event.tableName).add({ data: event.addData }); } //通用所有记录 case 'alllist': {//取跳过m条数据后的n条数据 return db.collection(event.tableName).orderBy('createTime', 'desc').skip(event.m).limit(event.n).get(); } //单个详细 case 'doc': { return db.collection(event.tableName).doc(event._id).get(); } //创建者列表 case 'mylist': { var openid = wxContext.OPENID; return db.collection(event.tableName).where({ OPENID: openid }).orderBy('createTime', 'desc').skip(event.m).limit(event.n).get(); } //删除单条 case 'remove': { return db.collection(event.tableName).doc(event._id).remove(); } default: {//保留原示例代码以供参考基础 return { event, openid: wxContext.OPENID, appid: wxContext.APPID, unionid: wxContext.UNIONID, } } } } [代码] 页面统一加载方法 [代码]loaddata: function (m = 0, comac = null) { var that = this; wx.showLoading({ title: '数据加载中...', }) wx.cloud.callFunction({ name: 'schoolHander', data: { acType: 'alllist', tableName: 'Schools', m: m, n: 20 } }).then(res => { if (m == 0) {//如果跳过记录数为0寻么认为是刷新或首次加载，直接把结果赋值 that.setData({ alllist: res.result.data }) } else {//跳过行不为0，应该是追加记录 that.setData({ alllist: that.data.alllist.concat(res.result.data) }) } wx.hideLoading(); if (comac) { comac();//如果执行完成后要附加什么方法就执行 } }).catch(err => { wx.hideLoading(); if (comac) { comac();//如果执行完成后要附加什么方法就执行 } }) } [代码] 调用方法 [代码] /** * 生命周期函数--监听页面显示 */ onShow: function () { this.loaddata();//因为所有参数都有默认值所以不传自动按默认值首次加载处理 }, /** * 页面相关事件处理函数--监听用户下拉动作 */ onPullDownRefresh: function () { //刷新数据，但完成后应该要停止下拉事件，不然经常会出现页面不自动收上去的情况 this.loaddata(0,() => { wx.stopPullDownRefresh(); }); }, /** * 页面上拉触底事件的处理函数 */ onReachBottom: function () { 所跳过数据行的值设置成当前页只已经存在的数据条数 this.loaddata(this.data.alllist.length,null); } [代码] 小小分享，献丑了_

接着上篇文章《小程序架构设计(一)》 前边我们说到采用Web+离线包的方式可以解决很多问题，但是遗留了一个安全问题有待解决。 经过了一番讨论，我们决定把开发者的JS逻辑代码放到单独的线程去运行，因为不在Webview线程里，所以这个环境没有Webview任何接口，自然的开发者就没法直接操作Dom，也就没法动态去更改界面，“管控”的问题得以解决。 还存在一个问题：开发者没法操作Dom，如果用户交互需要界面变化的话，开发者就没办法动态变化界面了。所以我们要找到一个办法：不直接操作Dom也能做到界面更新。 其实Facebook早有方案解决这个问题，就是上篇文章提到的React。React引入了Virtual Dom的概念（后文简称VD），业务侧只需要改变数据即可引起界面变化，相关原理后边再写篇文章来分享。 至此小程序双线程的模型就定下来了：渲染层(Webview)+逻辑层(JSCore) [图片] 其中渲染层用了Webview进行渲染，开发者的JS逻辑运行在一个独立的JSCore线程。 渲染层提供了带有数据绑定语法的WXML，逻辑层提供了setData等等API，开发者需要进行界面变化时，只需要通过setData把变化的数据传进去，小程序框架就会进行Dom Diff等流程最后把正确的结果更新在Dom树上。 [图片] 可以看到在开发者的逻辑下层，还需要有一层小程序框架的支持（数据通信、API、VD算法等等），我们把它称为基础库。 我们在两个线程各自注入了一份基础库，渲染层的基础库含有VD的处理以及底层组件系统的机制，对上层提供一些内置组件，例如video、image等等。逻辑层的基础库主要会提供给上层一些API，例如大家经常用到的wx.login、wx.getSystemInfo等等。 解决了渲染问题，我们还要看一下用户在和界面交互时的问题。 [图片] 用户在屏幕点击某个按钮，开发者的逻辑层要处理一些事情，然后再通过setData引起界面变化，整个过程需要四次通信。对于一些强交互（例如拖动视频进度条）的场景，这样的处理流程会导致用户的操作很卡。 对于这种强交互的场景，我们引入了原生组件，这样用户和原生组件的交互可以节省两次通信。 [图片] 正如上图所示，原生组件和Webview不是在同一层级进行渲染，原生组件其实是叠在Webview之上，想必大家都遇到过这个问题，video、input、map等等原生组件总是盖在其他组件之上，这就是这个设计带来的问题。 我们也很重视这个问题，经过了一段时间的努力，我们攻克了这个难题，把原生组件渲染到Webview里，从而实现同层渲染。目前video组件已经完成同层渲染的全量发布，详细可以看我们之前的公告：同层渲染公测。 为了让开发者可以更好的开发小程序，我们在后来还引入了自定义组件和插件的概念，我们后续会有相关的文章再介绍这两块的设计，希望大家关注我们社区的文章板块。 [图片] 以上就是小程序架构设计的历史。