在微信早期，我们内部就有这样的诉求，在微信打开的H5可以调用到微信原生一些能力，例如公众号文章里可以打开公众号的Profile页。所以早期微信提供了Webview到原生的通信机制，在Webview里注入JSBridge的接口，使得H5可以通过它调用到原生能力。 [图片] 我们可以通过JSBridge微信预览图片的功能： [代码]WeixinJSBridge.invoke('imagePreview', { current: https://img1.gtimg.com/1.jpg', urls: [ 'https://img1.gtimg.com/1.jpg', 'https://img1.gtimg.com/2.jpg', 'https://img1.gtimg.com/3.jpg' ] }) [代码] 早期微信官方是没有暴露这些接口的，都是腾讯内部业务在使用，很多外部开发者发现后，就依葫芦画瓢地使用了。 从另外一个角度看，JSBridge是微信和H5的通信协议，有一些能力可能要组合不同的能力才能完整调用。如果我们直接开放这套API，相当于所有开发者都要直接理解这样的接口协议，显然是很不合理的。 所以在2015年初的时候，微信就发布了JSSDK，其实就是隐藏了内部一些细节，包装了几十个API给到上层业务直接调用。 [图片] 前边的代码就变成了： [代码]wx.previewImage({ current: https://img1.gtimg.com/1.jpg', urls: [ 'https://img1.gtimg.com/1.jpg', 'https://img1.gtimg.com/2.jpg', 'https://img1.gtimg.com/3.jpg' ] }) [代码] 开发者可以用JSSDK来调用微信的能力，来完成一些以前H5做不到或者难以做到的事情。 能力上得到了更多的支持，但是微信里的H5体验却没有改善。 第一点是加载H5时的白屏。在微信里打开链接后会看到白屏，有一些H5的服务不稳定，这个白屏现象会更严重。 [图片] 第二点是在H5跳转到其他页面时，切换的效果也很不流畅，只能看到顶部绿色进度条在走。 [图片] 随着JSSDK的开放，还出现了更不好对付的问题。 微信上越来越多干坏事的人，有人做假红包，有人诱导分享，有伪造一些官方活动。他们会利用JSSDK的分享能力变相的去裂变分享到各个群或者朋友圈，由于JSSDK是根据域名来赋予api权限的，运营人员封了一个域名后，他们立马用别的域名又继续做坏，要知道注册一个新的域名的成本是很低的。 [图片] [图片] [图片] 龙哥在2016年微信公开课上提出了应用号的概念，我们要重新设计一个新的移动应用开发模式，同时我们要解决刚刚提到的一些问题。 至此，我们回顾一下目前移动应用开发的一些特点： Web开发的门槛比较低，而App开发门槛偏高而且需要考虑iOS和安卓多个平台； 刚刚说到H5会有白屏和页面切换不流畅的问题，原生App的体验就很好了； H5最大的优点是随时可以上线更新，但是App的更新就比较慢，需要审核上架，还需要用户主动安装更新。 我们更想要的一种开发模式应该是要满足一下几点： 像H5一样开发门槛低； 体验一定要好，要尽可能的接近原生App体验； 让开发者可以云端更新，而且我们平台要可以管控。 很多人可能会第一时间想到Facebook的React Native(下边简称RN)，是不是RN就能解决这些问题呢？ 是的，React Native貌似可以解决刚刚那些问题，我们也曾经想用RN来做。但是仔细分析了一下，我们发现了采用RN这个机制做开放平台还是存在一些问题。 RN只支持CSS的子集，作为一个开放的生态，我们还要告诉外边千千万万的开发者，哪些CSS属性能用，哪些不能用； RN本身存在一些问题，这些依赖RN的修复，同时这样就变成太过依赖客户端发版本去解决开发者那边的Bug，这样修复周期太长。 RN前阵子还搞出了一个Lisence问题，对我们来说也是存在隐患的。 [图片] 所以我们舍弃了这样的方案，我们改用了Hybrid的方式。简单点说，就是把H5所有代码打包，一次性Load到本地再打开。这样的好处是我们可以用一种近似Web的方式来开发，同时在体验上也可以做到不错的效果，并且也是可以做到云端更新的。 [图片] 现在留给我们的最后一个问题就是，平台的管控问题。 怎么理解呢？我们知道H5的界面结构是用HTML进行描述，浏览器进行一系列的解析最终绘制在界面上。 [图片] 同时浏览器提供了可以操作界面的DOM API，开发者可以用这些API进行一些界面上的变动，从而实现UI交互。 [图片] 既然我们要采用Web+离线包的方式，那我们要解决前边说过的安全问题，我们就要禁用掉很多危险的HTML标签，还要禁用掉一些API，我们要一直维护这样的白名单或者黑名单，实现成本太高了，而且未来浏览器内核一旦更新，对我们来说都是很大的安全隐患。 [图片] 这就是小程序一开始遇到的问题，在下篇文章《小程序架构设计(二)》，我们再详细展开一下小程序是如何解决以上这个问题的。

接着上篇文章《小程序架构设计(一)》 前边我们说到采用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组件已经完成同层渲染的全量发布，详细可以看我们之前的公告：同层渲染公测。 为了让开发者可以更好的开发小程序，我们在后来还引入了自定义组件和插件的概念，我们后续会有相关的文章再介绍这两块的设计，希望大家关注我们社区的文章板块。 [图片] 以上就是小程序架构设计的历史。

开门见山 工具地址 点我直达>>painter-custom-poster 由于挂载在github page上，打开速度会慢一些，请耐心等待或自行解决git网速问题 背景 在做小程序时候，我们经常会有一个需求，需要将小程序分享到朋友圈，但是朋友圈是不允许直接分享小程序，那我们还有其他的办法解决吗?答案肯定是有的，即 canvas 生成个性化海报分享图片到朋友圈 分析 小程序中有大量的生成图片需求，但是使用过 canvas 的人，都会发现一些难以预料的问题>>有关小程序的坑 直接在 canvas 上绘制图形，对于普通开发者来说代码会特别凌乱并且难以维护，经常会花费很久的时间去优化代码 不同的环境渲染问题，例如在开发者工具看起来好好的，一到 Android 真机，就出现图片不显示，位置不对应等等问题 解决 那可不可以开发一款生成海报的插件库呢? 首先，只需要提供一份简单的参数配置文件即可 解决掉小程序Canvas遇到的一些大大小小的坑 有严苛的测试环节，解决各种环境和各种机型遇到的问题，并提供稳定的线上版本 长期维护，并有专人更新迭代更新颖的功能 以上的要求当然是可以的，曾经的我也想尝试开发一款出来，但是后来尝试了几款现成的工具之后就放弃了，毕竟轮子这个东西，是需要不断维护更新的，另外已经有这么多优秀现成的插件了，我为何还要费力去写呢，贡献代码岂不更美哉，以下是我收集的几款 小程序生成图片库，轻松通过 json 方式绘制一张可以发到朋友圈的图片>>Painter 小程序组件-小程序海报组件>>wxa-plugin-canvas 微信小程序：一个 json 帮你完成分享朋友圈图片>>mp_canvas_drawer 我想干什么 唠了这么多，好像提供给大家插件就没我什么事情了…想走是不可能的 为了能够制作出更酷炫的海报，我思考了许久 虽然有了插件后，只需要提供配置代码就能够制作出一款海报来，但是我发现还是有些许问题 制作海报效率还是不够高，微调一个元素的大小和位置，就需要不断的修改保存代码，等待片刻，查看效果，真的烦 一个小小的位置调整可能就需要来回调整无数次，这种最简单的机械化劳动，这辈子是不可能的 拿着完美的稿子，递给设计师看，这个位置不对，这个线太粗，这个颜色太重…你信不信我打死你 对于一些精美复杂的海报，实现起来真的不太现实 那我需要怎么做呢，请点击这个链接体验>>painter-custom-poster 点击左侧例子展示中的任意一个例子，然后导入代码就能看到效果图，这下你应该能猜到了我的想法了 如何实现 刚开始我想用简单的html和css加拖动功能实现，通过简单尝试之后就放弃了，因为这个功能真的太复杂了，简单的工具肯定是不行的 中间这个计划停滞了很长时间，一度已经放弃 直到发现了这个库fabric.js，真的太太优秀了，赞美之词无以言表，唯一的缺点就是中文教程太少，必须生啃英文加谷歌翻译 fabric介绍，你可以很容易地创建任何一个简单的形状，复杂的形状，图像;将它们添加到画布中，并以任何你想要的方式进行修改：位置、尺寸、角度、颜色、笔画、不透明度等 How To Use 目前工具一共分成4部分 例子展示 用来将一些用户设计的精美海报显示出来，通过点击对应的例子并将代码导入画布中 画布区 显示真实的海报效果，画布里添加的元素，都可以直接用鼠标进行拖动，旋转，缩放操作 操作区 第一排四个按钮 复制代码 将画布的展示效果转化成小程序海报插件库所需要的json配置代码，目前我使用的是Painter库，默认会转化成这个插件的配置代码，将代码直接复制到card.js即可 查看代码 这个功能用不用无所谓，可以直观的看到生成的代码 导出json 将画布转化成fabric所需要的json代码，方便将自己设计的海报代码保存下来 导入json 将第3步导出的json代码导入，会在画布上显示已设计的海报样式 第二排五个按钮 画布 画布的属性参数 详解见下方 文字 添加文字的属性参数 详解见下方 矩形 添加矩形的属性参数 详解见下方 图片 添加图片的属性参数 详解见下方 二维码 添加二维码的属性参数 详解见下方 第三排 各种元素的详细设置参数 激活区 激活对象是指鼠标点击画布上的元素，该对象会被蓝色的边框覆盖，此时该对象被激活，可以执行拖动 旋转 缩放等操作 激活区只有对象被激活才会出来，用来设置激活对象的各种配置参数，修改value值后，实时更新当前激活对象的对应状态，点击其他区域，此模块将隐藏 快捷键 ‘←’ 左移一像素 ‘→’ 右移一像素 ‘↑’ 上移一像素 ‘↓’ 下移一像素 ‘ctrl + z’ 撤销 ‘ctrl + y’ 恢复 ‘delete’ 删除 ‘[’ 提高元素的层级 ‘]’ 降低元素的层级 布局属性 通用布局属性 属性 说明 默认 rotate 旋转，按照顺时针旋转的度数 0 width、height view 的宽度和高度 top、left 如 css 中为 absolute 布局时的作用 0 background 背景颜色 rgba(0，0，0，0) borderRadius 边框圆角 0 borderWidth 边框宽 0 borderColor 边框颜色 #000000 shadow 阴影 ‘’ shadow 可以同时修饰 image、rect、text 等 。在修饰 text 时则相当于 text-shadow；修饰 image 和 rect 时相当于 box-shadow 使用方法： [代码]shadow: 'h-shadow v-shadow blur color'; h-shadow: 必需。水平阴影的位置。允许负值。 v-shadow: 必需。垂直阴影的位置。允许负值。 blur: 必需。模糊的距离。 color: 必需。阴影的颜色。 举例: shadow:10 10 5 #888888 [代码] 渐变色支持 你可以在画布的 background 属性中使用以下方式实现 css 3 的渐变色，其中 radial-gradient 渐变的圆心为 中点，半径为最长边，目前不支持自己设置。 [代码]linear-gradient(-135deg, blue 0%, rgba(18, 52, 86, 1) 20%, #987 80%) radial-gradient(rgba(0, 0, 0, 0) 5%, #0ff 15%, #f0f 60%) [代码] ！！！注意：颜色后面的百分比一定得写。 画布属性 属性 说明 默认 times 控制生成插件代码的宽度大小，比如画布宽100，times为2，生成的值为200 1 文字属性 属性名称 说明 默认值 text 字体内容 别跟我谈感情，谈感情伤钱 maxLines 最大行数 不限，根据 width 来 lineHeight 行高（上下两行文字baseline的距离） 1.3 fontSize 字体大小 30 color 字体颜色 #000000 fontWeight 字体粗细。仅支持 normal， bold normal textDecoration 文本修饰，支持none underline、 overline、 linethrough none textStyle fill： 填充样式，stroke：镂空样式 fill fontFamily 字体 sans-serif textAlign 文字的对齐方式，分为 left， center， right left 备注: fontFamily，工具中的第一个例子支持文字字体，但是导入小程序为什么看不到呢，小程序官网加载网络字体方法>> 加载字体教程>> 文字高度 是maxLines lineHeight2个字段一起计算出来的 图片属性 属性 说明 默认 url 图片路径 mode 图片裁剪、缩放的模式 aspectFill mode参数详解 scaleToFill 缩放图片到固定的宽高 aspectFill 图片裁剪显示对应的宽高 auto 自动填充 宽度全显示 高度自适应居中显示 Tips（一定要看哦～） 本工具不考虑兼容性，如发现不兼容请使用google浏览器 painter现在只支持这几种图形，所以暂不支持圆，线等 如果编辑过程，一个元素被挡住了，无法操作，请选择对象并通过[ ]快捷键提高降低元素的层级 文字暂不支持直接缩放操作，因为文字大小和元素高度不容易计算，可以通过修改激活栏目maxLines lineHeight fontSize值来动态改变元素 如发现导出的代码一个元素被另一个元素挡住了，请手动调整元素的位置，json数组中元素越往后层级显示就越高，由于painter没有提供层级参数，所以目前只能这样做 本工具导出代码全是以px为单位，为什么不支持rpx， 因为painter在rpx单位下，阴影和边框宽会出现大小计算问题，由于原例子没有提供px生成图片方案，可以下载我这里修改过的demo>>Painter即可解决 文本宽度随着字数不同而动态变化，想在文本后面加个图标根据文本区域长度布局， 请参考Painter文档这块教程直接修改源码 由于本工具开发有些许难度，如出现bug，建议或者使用上的问题，请提issue，源码地址>>painter-custom-poster 海报贡献 如果你设计的海报很好看，并且愿意开源贡献，可以贡献你的海报代码和缩略图，例子代码文件在example中，按顺序排列，例如现在库里例子是example2.js，那你添加example3.js和example3.jpg图片，事例可以参考一下文件夹中源码，然后在index.js中导出一下 导出代码 代码不要格式化，会报错，请原模原样复制到json字段里 生成缩略图 刚开始我想在此工具中直接生成图片，但是由于浏览器图片跨域问题导致报错失败 所以请去小程序中生成保存图片，图片质量设置0.2，并去tinypng压缩一下图片 找到painter.js，替换下边这个方法，可以生成0.2质量的图片，代码如下 [代码] saveImgToLocal() { const that = this; setTimeout(() => { wx.canvasToTempFilePath( { canvasId: 'k-canvas', fileType: 'jpg', quality: 0.2, success: function(res) { that.getImageInfo(res.tempFilePath); }, fail: function(error) { console.error(`canvasToTempFilePath failed, ${JSON.stringify(error)}`); that.triggerEvent('imgErr', { error: error }); } }, this ); }, 300); } [代码] TODO 颜色值选择支持调色板工具 文字padding支持 缩放位置弹跳问题优化 假如需求大的话，支持其他几款插件库代码的生成 ~ 创作不易，如果对你有帮助，请给个星星 star✨✨ 谢谢 ~

Wxml2Canvas库，可以将指定的wxml节点直接转换成canvas元素，并且保存成分享图，极大地提升了绘制分享图的效率。目前被应用于微信游戏圈、王者荣耀、刺激战场助手等小程序中。 github地址：https://github.com/wg-front/wxml2canvas 一、背景 随着小程序应用的日渐成熟，多处场景需要能够生成分享图便于用户进行二次传播，从而提升小程序的传播率以及加强品牌效应。 对于简单的分享图，比如固定大小的背景图加几行简短文字构成的分享小图，我们可以利用官方提供的canvas接口将元素直接绘制， 虽然繁琐了些，但能满足基本要求。 对于复杂的分享图，比如用户在微信游戏圈发表完话题后，需要将图文混排的富文本内容生成分享图，对于这种长度不定，内容动态变化的图片生成需求，直接利用官方的canvas接口绘制是十分困难的，包括但不限于文字换行、表情文字图片混排、文字加粗、子标题等元素都需要一一绘制。又如王者荣耀助手小程序，需要将十人对局的详细战绩绘制成分享图，包含英雄数据、装备、技能、对局结果等信息，要绘制100多张图片和大量的文字信息，如果依旧使用官方的接口一步一步绘制，对开发者来说简直就是一场噩梦。我们急需一种通用、高效的方式完成上述的工作。 在这样的背景下，wxml2cavnas诞生了，作为一种分享图绘制的通用方案，它不仅能快速的绘制简单的固定小图，还能直接将wxml元素真实地转换成canvas元素，并且适配各种机型。无论是复杂的图文混排的富文本内容，还是展现形式多样的战绩结果页，都可以利用wxml2cavnas完美地快速绘制并生成所期望的分享图片。 二、Wxml2Canvas介绍及示例 1. 介绍 Wxml2Cavnas库，是一个生成小程序分享图的通用方案，提供了两种绘制方式： 封装基础图形的绘制接口，包括矩形、圆形、线条、图片、圆角图片、纯文本等，使用时只需要声明元素类型并提供关键数据即可，不需要再关注canvas的具体绘制过程； wxml直接转换成canvas元素，使用时传入待绘制的wxml节点的class类名，并且声明绘制此节点的类型（图片、文字等），会自动读取此节点的computedStyle，利用这些数据完成元素的绘制。 2. 生成图示例 下面是两张极端复杂的分享图。 2.1 游戏圈话题 [图片] 点击查看完整长图 2.2.2 王者荣耀战绩 [图片] 点击查看完整大图 三、小程序的特性及局限 小程序提供了如下特性，可供我们便捷使用： measureText接口能直接测量出文本的宽度； SelectorQuery可以查询到节点对应的computedStyle。 利用第一条，我们在绘制超长文本时便于文本的省略或者换行，从而避免文字溢出。 利用第二条，我们可以根据class类名，直接拿到节点的样式，然后将style转换成canvas可识别的内容。 但是和html的canvas相比，小程序的canvas局限性很多。主要体现在如下几点： 不支持base64图片； 图片必须下载到本地后才能绘制到画布上； 图片域名需要在管理平台加入downFile安全域名； canvas属于原生组件，在移动端会置于最顶层； 通过SelectorQuery只能拿到节点的style，而无法获取文本节点的内容以及图片节点的链接。 针对以上问题，我们需要将base64图片转换jpg或png格式的图片，实现图片的统一下载逻辑，并且离屏绘制内容。针对第五条，好在SelectorQuery可以获取到节点的dataset属性，所以我们需要在待绘制的节点上显示地声明其类型（imgae、text等），并且显示地传入文本内容或图片链接，后文会有示例。 四、Wxml2Canvas使用方式 1. 初始化 首先在wxml中创建canvas节点，指定宽高： [代码] <canvas canvas-id="share" style="height: {{ height * zoom }}px; width: {{ width * zoom }}px;"> </canvas> [代码] 引入代码库，创建DrawImage实例，并传入如下参数： [代码] let DrawImage = require('./wxml2canvas/index.js'); let zoom = this.device.windowWidth / 375; let width = 375; let height = width * 3; let drawImage = new DrawImage({ element: 'share', // canvas节点的id, obj: this, // 在组件中使用时，需要传入当前组件的this width: width, // 宽高 height: height, background: '#161C3A', // 默认背景色 gradientBackground: { // 默认的渐变背景色，与background互斥 color: ['#17326b', '#340821'], line: [0, 0, 0, height] }, progress (percent) { // 绘制进度 }, finish (url) { // 画完后返回url }, error (res) { console.log(res); // 画失败的原因 } }); [代码] 所有的数字参数均以iphone6为基准，其中参数width和height决定了canvas画布的大小，规定值是在iphone6机型下的固定数值； zoom参数的作用是控制画布的缩放比例，如果要求画布自适应，则应传入 windowWidth / 375，windowWidth为手机屏幕的宽度。 2. 传入数据，生成图片 执行绘制操作： [代码] drawImage.draw(data, this); [代码] 执行绘制时需要传入数据data，数据的格式分为两种，下面展开介绍。 2.1 基础图形 第一种为基础的图形、图文绘制，直接使用官方提供接口，下面代码是一个基本的格式： [代码] let data = { list: [{ type: 'image', url: 'https://xxx', class: 'background_image', // delay: true, x: 0, y: 0, style: { width: width, height: width } }, { type: 'text', text: '文字', class: 'title', x: 0, y: 0, style: { fontSize: 14, lineHeight: 20, color: '#353535', fontFamily: 'PingFangSC-Regular' } }] } [代码] 如上，type声明了要元素的类型，有image、text、rect、line、circle、redius_image(圆角图)等，能满足绝大多数情况。 class类名指定了使用的样式，需要在style中写出，符合css样式规范。 delay参数用来异步绘制元素，会把此元素放在第二个循环中绘制。 x,y用来指定元素的起始坐标。 将css样式与元素分离的目的是便于管理与复用。 此种方式每个元素都相互独立，互不影响，能够满足自由度要求高的情况，可控性高。 2.2 wxml转换 第二种方式为指定wxml元素，自动获取，下面是示例： [代码] let data = { list: [{ type: 'wxml', class: '.panel .draw_canvas', limit: '.panel' x: 0, y: 0 }] } [代码] 如上，type声明为wxml时，会查找所有类名为draw_canvas的节点，并且加入到绘制队列中。 class传入的第一个类名限定了查询的范围，可以不传，第二个用来指定查找的节点，可以定义为任意不影响样式展现的通用类名。 limit属性用来限定相对位置，例如，一个文本的位置(left, top) = (50, 80)， class为panel的节点的位置为(left, top) = (20, 40)，则文本canvas上实际绘制的位置(x, y) = (50 - 20, 80 -40) = (30, 40)。如果不传入limit，则以实际的位置(x, y) = (50, 80)绘制。 由于小程序节点元素查询接口的局限，无法直接获取节点的文本内容和图片标签的src属性，也无法直接区分是文本还是图片，但是可以获取到dataset，所以我们需要在节点上显示地声明data-type来指明类型，再声明data-text传入文字或data-url传入图片链接。下面是个示例： [代码] <view class="panel"> <view class="panel__img draw_canvas" data-type="image" data-url="https://xxx"></view> <view class="panel__text draw_canvas" data-type="text" data-text="文字">文字</view> </view> [代码] 如上，会查询到两个节点符合条件，第一个为image图片，第二个为text文本，利用SelectorQuery查询它们的computedStyle，分别得到left、top、width、height等数据后，转换成canvas支持的格式，完成绘制。 除此之外，下面的示例功能更加丰富： [代码] <view class="panel"> <view class="panel__text draw_canvas" data-type="background-image" data-radius="1" data-shadow="" data-border="2px solid #000"></view> <view class="panel__text draw_canvas" data-type="text" data-background="#ffffff" data-padding="2 3 0 0" data-delay="1" data-left="10" data-top="10" data-maxlength="4" data-text="这是个文字">这是个文字</view> </view> [代码] 如上，第一个data-type为background-image，表示读取此节点的背景图片，因为可以通过computedStyle直接获取图片链接，所以不需要显示传入url。声明data-radius属性，表示要将此图绘成乘圆形图片。data-border属性表示要绘制图片的边框，虽然也可以通过computedStyle直接获取，但是为了避免非预期的结果，还是要声明传入，border格式应符合css标准。此外，图片的box-shadow等样式都会根据声明绘制出来。 第二个文本节点，声明了data-background，则会根据节点的位置属性给文字增加背景。 data-padding属性用来修正背景的位置和宽高。data-delay属性用来延迟绘制，可以根据值的大小，来控制元素的层级，data-left和data-top用来修正位置，支持负值。data-maxlength用来限制文本的最大长度，超长时会截取并追加’…’。 此外，data-type还有inline-text，inline-image等行内元素的绘制，其实现较为复杂，会在后文介绍。 五、Wxml2Canvas实现原理 1. 绘制流程 整个绘制流程如下： [图片] 因为小程序的限制，只能在画布上绘制本地图片，所以统一先对图片提前下载，然后再绘制，为了避免图片重复下载，内部维护一个图片列表，会对相同的图片链接去重，减少等待时间。 2. 基本图形的实现 基础图形的绘制比较简单，内部实现只是对基础能力的封装，使用者不用再关注canvas的绘制过程，只需要提供关键数据即可，下面是一个图片绘制的实现示例： [代码] function drawImage (item, style) { if(item.delay) { this.asyncList.push({item, style}); }else { if(item.y < 0) { item.y = this.height + item.y * zoom - style.height * zoom; }else { item.y = item.y * zoom; } if(item.x < 0) { item.x = this.width + item.x * zoom - style.width * zoom; }else { item.x = item.x * zoom; } ctx.drawImage(item.url, item.x, item.y, style.width * zoom, style.height * zoom); ctx.draw(true); } } [代码] 如上，x,y值坐标支持传入负值，表示从画布的底部和右侧计算位置。 3. Wxml转Canvas元素的实现 3.1 computedStyle的获取 首先需要获取wxml的样式，代码示例如下： [代码] query.selectAll(`${item.class}`).fields({ dataset: true, size: true, rect: true, computedStyle: ['width', 'height', ...] }, (res) => { self.drawWxml(res); }) [代码] 3.2 块级元素的绘制 对于声明为image、text的元素，默认为块级元素，它们的绘制都是独立进行的，不需要考虑其他的元素的影响，以wxml节点为圆形的image为例，下面是部分代码： [代码] if(sub.dataset.type === 'image') { let r = sub.width / 2; let x = sub.left + item.x * zoom; let y = sub.top + item.y * zoom; let leftFix = +sub.dataset.left || 0; let topFix = +sub.dataset.top || 0; let borderWidth = sub.borderWidth || 0; let borderColor = sub.borderColor; // 如果是圆形图片 if(sub.dataset.radius) { // 绘制圆形的border if(borderWidth) { ctx.beginPath() ctx.arc(x + r, y + r, r + borderWidth, 0, 2 * Math.PI) ctx.setStrokeStyle(borderColor) ctx.setLineWidth(borderWidth) ctx.stroke() ctx.closePath() } // 绘制圆形图片的阴影 if(sub.boxShadow !== 'none') { ctx.beginPath() ctx.arc(x + r, y + r, r + borderWidth, 0, 2 * Math.PI) ctx.setFillStyle(borderColor); setBoxShadow(sub.boxShadow); ctx.fill() ctx.closePath() } // 最后绘制圆形图片 ctx.save(); ctx.beginPath(); ctx.arc((x + r), (y + r) - limitTop, r, 0, 2 * Math.PI); ctx.clip(); ctx.drawImage(url, x + leftFix * zoom, y + topFix * zoom, sub.width, sub.height); ctx.closePath(); ctx.restore(); }else { // 常规图片 } } [代码] 如上，块级元素的绘制和基础图形的绘制差异不大，理解起来也很容易，不再多述。 3.3 令人头疼的行内元素的绘制 当wxml的data-type声明为inline-image或者inline-text时，我们认为是行内元素。行内元素的绘制是一个难点，因为元素之前存在关联，所以不得不考虑各种临界情况。下面展开细述。 3.3.1 纯文本换行 对于长度超过一行的行内元素，需要计算出合适的换行位置，下图所示的是两种临界情况： [图片] [图片] 如上图所示，第一种情况为最后一行只有一个文字，第二种情况最后一行的文字长度和宽度相同。虽然长度不同，但都可通过下面代码绘制： [代码] let lineNum = Math.ceil(measureWidth(text) / maxWidth); // 文字行数 let sinleLineLength = Math.floor(text.length / lineNume); // 向下取整，保证多于实际每行字数 let currentIndex = 0; // 记录文字的索引位置 for(let i = 0; i < lineNum; i++) { let offset = 0; // singleLineLength并不是精确的每行文字数，要校正 let endIndex = currentIndex + sinleLineLength + offset; let single = text.substring(currentIndex, endIndex); // 截取本行文字 let singleWidth = measureWidth(single); // 超长时，左移一位，直至正好 while(singleWidth > maxWidth) { offset--; endIndex = currentIndex + sinleLineLength + offset; single = text.substring(currentIndex, endIndex); singleWidth = measureWidth(single); } currentIndex = endIndex; ctx.fillText(single, item.x, item.y + i * style.lineHeight); } // 绘制剩余的 if(currentIndex < text.length) { let last = text.substring(currentIndex, text.length); ctx.fillText(last, item.x, item.y + lineNum * style.lineHeight); } [代码] 为了避免计算太多次，首先算出大致的行数，求出每行的文字数，然后移位索引下标，求出实际的每行的字数，再下移一行继续绘制，直到结束。 3.3.2 非换行的图文混排 [图片] 上图是一个包含表情图片和加粗文字的混排内容，当使用Wxml2Canvas查询元素时，会将第一行的内容分为五部分： 文本内容：这是段文字； 表情图片：发呆表情(非系统表情，image节点展现)； 表情图片：发呆表情； 文本内容：这也； 加粗文本内容：是一段文字，这也是文字。 对于这种情况，执行查询computedStyle后，会返回相同的top值。我们把top值相同的元素聚合在一起，认为它们是同一行内容，事实也是如此。因为表情大小的差异以及其他影响，默认规定top值在±2的范围内都是同一行内容。然后将top值的聚合结果按照left的大小从左往右排列，再一一绘制，即可完美还原此种情况。 3.3.3 换行的图文混排 当混排内容出现了换行情况时，如下图所示： [图片] 此时的加粗内容占据了两行，当我们依旧根据top值归类时，却发现加粗文字的left值取的是第二行的left值。这就导致加粗文字和第一部分的文字的top值和left值相同，如果直接绘制，两部分会发生重叠。 为了避免这种尴尬的情况，我们可以利用加粗文字的height值与第一部分文字的height值比较，显然前者是后者的两倍，可以得知加粗部分出现了换行情况，直接将其放在同组top列表的最后位置。换行的部分根据lineHeight下移绘制，同时做记录。 最后一部分的文本内容也出现了换行情况，同样无法得到真正的起始left值，并且其top值与上一部分换行后的top值相同。此时应该将他的left值追加加粗换行部分的宽度，正好得到真正的left值，最后再绘制。 大多数的行内元素的展现形式都能以上述的逻辑完美还原。 六、总结 基于基础图形封装和wxml转换这两种绘制方式，可以满足绝大多数的场景，能够极大地减少工作量，而不需要再关注内部实现。在实际使用中，二者并非孤立存在，而更多的是一起使用。 [图片] 如上图所示，对于列表内容我们利用wxml读取绘制，对于下部的白色区域，不是wxml节点内容，我们可以使用基础图形绘制方式实现。二者的结合更加灵活高效。 目前Wxml2Canvas已经在公司内部开源，不久会放到github上，同时也在不断完善中，旨在实现更多的样式展现与提升稳定性和绘制速度。 如果有更好的建议与想法，请联系我。

背景 在做小程序时，关于默认导航栏，我们遇到了以下的问题： Android、IOS手机对于页面title的展示不一致，安卓title的显示不居中 页面的title只支持纯文本级别的样式控制，不能够做更丰富的title效果 左上角的事件无法监听、定制 路由导航单一，只能够返回上一页，深层级页面的返回不够友好 探索 小程序自定义导航栏已开放许久>>了解一下，相信不少小伙伴已使用过这个功能，同时不少小伙伴也会发现一些坑： 机型多如牛毛：自定义导航栏高度在不同机型始终无法达到视觉上的统一 调皮的胶囊按钮：导航栏元素（文字，图标等）怎么也对不齐那该死的胶囊按钮 各种尺寸的全面屏，奇怪的刘海屏，简直要抓狂 一探究竟 为了搞明白原理，我先去翻了官方文档，>>飞机，点过去是不是很惊喜，很意外，通篇大文尽然只有最下方的一张图片与这个问题有关，并且啥也看不清，汗汗汗… 我特意找了一张图片来 [图片] 分析上图，我得到如下信息： Android跟iOS有差异，表现在顶部到胶囊按钮之间的距离差了6pt 胶囊按钮高度为32pt， iOS和Android一致 动手分析 我们写一个状态栏，通过wx.getSystemInfoSync().statusBarHeight设置高度 Android： [图片] iOS:[图片] 可以看出，iOS胶囊按钮与状态栏之间距离为：4px， Android为8px，是不是所有手机都是这种情况呢？ 答案是:苹果手机确实都是4px,安卓大部分都是7和8 也会有其他的情况(可以自己打印getSystemInfo验证)如何快速便捷算出这个高度,请接着往下看 如何计算 导航栏分为状态栏和标题栏,只要能算出每台手机的导航栏高度问题就迎刃而解 导航栏高度 = 胶囊按钮高度 + 状态栏到胶囊按钮间距 * 2 + 状态栏高度 注：由于胶囊按钮是原生组件，为表现一致，其单位在各种手机中都为px，所以我们自定义导航栏的单位都必需是px（切记不能用rpx），才能完美适配。 解决问题 现在我们明白了原理，可以利用胶囊按钮的位置信息和statusBarHeight高度动态计算导航栏的高度，贴一个实现此功能最重要的方法 [代码]let systemInfo = wx.getSystemInfoSync(); let rect = wx.getMenuButtonBoundingClientRect ? wx.getMenuButtonBoundingClientRect() : null; //胶囊按钮位置信息 wx.getMenuButtonBoundingClientRect(); let navBarHeight = (function() { //导航栏高度 let gap = rect.top - systemInfo.statusBarHeight; //动态计算每台手机状态栏到胶囊按钮间距 return 2 * gap + rect.height; })(); [代码] gap信息就是不同的手机其状态栏到胶囊按钮间距，具体更多代码实现和使用demo请移步下方代码仓库，代码中还会有输入框文字跳动解决办法,安卓手机输入框文字飞出解决办法,左侧按钮边框太粗解决办法等等 胶囊信息报错和获取不到 问题就在于 getMenuButtonBoundingClientRect 这个方法，在某些机子和环境下会报错或者获取不到，对于此种情况完美可以模拟一个胶囊位置出来 [代码]try { rect = Taro.getMenuButtonBoundingClientRect ? Taro.getMenuButtonBoundingClientRect() : null; if (rect === null) { throw 'getMenuButtonBoundingClientRect error'; } //取值为0的情况 if (!rect.width) { throw 'getMenuButtonBoundingClientRect error'; } } catch (error) { let gap = ''; //胶囊按钮上下间距 使导航内容居中 let width = 96; //胶囊的宽度，android大部分96，ios为88 if (systemInfo.platform === 'android') { gap = 8; width = 96; } else if (systemInfo.platform === 'devtools') { if (ios) { gap = 5.5; //开发工具中ios手机 } else { gap = 7.5; //开发工具中android和其他手机 } } else { gap = 4; width = 88; } if (!systemInfo.statusBarHeight) { //开启wifi的情况下修复statusBarHeight值获取不到 systemInfo.statusBarHeight = systemInfo.screenHeight - systemInfo.windowHeight - 20; } rect = { //获取不到胶囊信息就自定义重置一个 bottom: systemInfo.statusBarHeight + gap + 32, height: 32, left: systemInfo.windowWidth - width - 10, right: systemInfo.windowWidth - 10, top: systemInfo.statusBarHeight + gap, width: width }; console.log('error', error); console.log('rect', rect); } [代码] 以上代码主要是借鉴了拼多多的默认值写法，android 机子中 gap 值大部分为 8，ios 都为 4，开发工具中 ios 为 5.5，android 为 7.5，这样处理之后自己模拟一个胶囊按钮的位置，这样在获取不到胶囊信息的情况下，可保证绝大多数机子完美显示导航头 吐槽 这么重要的问题，官方尽然没有提供解决方案…竟然提供了一张看不清的图片??? 网上有很多ios设置44，android设置48，还有根据不同的手机型号设置不同高度，通过长时间的开发和尝试，本人发现以上方案并不完美,并且bug很多 代码库 Taro组件gitHub地址详细用法请参考README 原生组件npm构建版本gitHub地址详细用法请参考README 原生组件简易版gitHub地址详细用法请参考README 由于本人精力有限，目前只计划发布维护好这2种组件，其他组件请自行修改代码，有问题请联系 备注 上方2种组件在最下方30多款手机测试情况表现良好 iPhone手机打电话和开热点导致导航栏样式错乱，问题已经解决啦，请去demo里测试，这里特别感谢moments网友提出的问题 本文章并无任何商业性质，如有侵权请联系本人修改或删除 文章少量部分内容是本人查询搜集而来 如有问题可以下方留言讨论，微信zhijunxh 比较 斗鱼: [图片] 虎牙: [图片] 微博: [图片] 酷狗: [图片] 知乎: [图片] [图片] 知乎是这里边做的最好的，但是我个人认为有几个可以优化的小问题 打电话或者开启热点导致样式错落，这也是大部门小程序的问题 导航栏下边距太小，看起来不舒服 搜索框距离2侧按钮组距离不对等 自定义返回和home按钮中的竖线颜色重了，并且感觉太粗 如果您看到了此篇文章，请赶快修改自己的代码，并运用在实践中吧 扫码体验我的小程序: [图片] 创作不易，如果对你有帮助，请移步Taro组件gitHub原生组件gitHub给个星星 star✨✨ 谢谢 测试信息 手机型号 胶囊位置信息 statusBarHeight 测试情况 iPhoneX 80 32 281 369 48 88 44 通过 iPhone8 plus 56 32 320 408 24 88 20 通过 iphone7 56 32 281 368 24 87 20 通过 iPhone6 plus 56 32 320 408 24 88 20 通过 iPhone6 56 32 281 368 24 87 20 通过 HUAWEI SLA-AL00 64 32 254 350 32 96 24 通过 HUAWEI VTR-AL00 64 32 254 350 32 96 24 通过 HUAWEI EVA-AL00 64 32 254 350 32 96 24 通过 HUAWEI EML-AL00 68 32 254 350 36 96 29 通过 HUAWEI VOG-AL00 65 32 254 350 33 96 25 通过 HUAWEI ATU-TL10 64 32 254 350 32 96 24 通过 HUAWEI SMARTISAN OS105 64 32 326 422 32 96 24 通过 XIAOMI MI6 59 28 265 352 31 87 23 通过 XIAOMI MI4LTE 60 32 254 350 28 96 20 通过 XIAOMI MIX3 74 32 287 383 42 96 35 通过 REDMI NOTE3 64 32 254 350 32 96 24 通过 REDMI NOTE4 64 32 254 350 32 96 24 通过 REDMI NOTE3 55 28 255 351 27 96 20 通过 REDMI 5plus 67 32 287 383 35 96 28 通过 MEIZU M571C 65 32 254 350 33 96 25 通过 MEIZU M6 NOTE 62 32 254 350 30 96 22 通过 MEIZU MX4 PRO 62 32 278 374 30 96 22 通过 OPPO A33 65 32 254 350 33 96 26 通过 OPPO R11 58 32 254 350 26 96 18 通过 VIVO Y55 64 32 254 350 32 96 24 通过 HONOR BLN-AL20 64 32 254 350 32 96 24 通过 HONOR NEM-AL10 59 28 265 352 31 87 24 通过 HONOR BND-AL10 64 32 254 350 32 96 24 通过 HONOR duk-al20 64 32 254 350 32 96 24 通过 SAMSUNG SM-G9550 64 32 305 401 32 96 24 通过 360 1801-A01 64 32 254 350 32 96 24 通过

在微信小程序/小游戏的开发中，网络传输主要是依靠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 事件，监控异常断线。 希望大家在实际应用中能帮助到到大家。

swiper刷新wx:for。刷新数据，当前current并未检测数组长度。刷新数据时。数据变少，导致数组长度为1，current还是1。 [图片] [图片]