微信小程序导入其他字体会不会影响运行_小程序 Canvas 2d 与同层渲染

最近使用 Canvas 2d 做了一下周年活动页，中间踩了一些坑记录一下。 新的 canvas 接口和 web Canvas 的标准保持一致，所以编写代码的时候建议直接参考 Mdn 的文档，mp 上的文档 CanvasContext 部分都是旧的接口。 Canvas2d 的初始化和 Web 类似，需要先通过 DOM 接口获取到元素实例后才能继续画布操作，小程序没有DOM接口则用 CreateSelectorQuery替代。 小程序旧的  Canvas 接口 已经不再维护，2d (新接口)实现细节无从知晓，推测其主要目的在于保持与 Web 同构，重构的过程应该与同层渲染有关。但旧接口的性能瓶颈问题( 线程通信带来的损耗和画布频繁更新的矛盾问题)官方并未给出解法。 同层渲染是微信想办法把原生组件放到 Webview 去渲染。不同的系统实现的方式不同： IOS系统的 Wkwebview 实现的时候为了让 Webview 滚动更加流畅，对于 overflow : scroll的元素会新建一个 WkChildScrollView，这个View是 UIScrollView 的子类，也就是说它也是一个原生组件，但Webkit 内部已经处理了这个View和其他DOM节点的渲染问题，于是微信机智的把它的原生组件挂载到 WKScrollView 利用内核解决同层渲染的问题。 (图片转载) 而安卓端的chromium 支持 WebPlugin 机制，WebPlugin 是浏览器内核的一个插件机制，主要用来解析和描述embed 标签。Android 端的同层渲染就是基于 embed 标签结合 chromium 内核扩展来实现的。 (图片转载) 既安卓端利用 webview 支持导入外部媒体的特性，将原生组件作为其他数据源引入，让引擎去解决渲染的问题。 更详细的说明 https://developers.weixin.qq.com/community/develop/article/doc/000c4e433707c072c1793e56f5c813 两端的方案不同，但思路都是寻求 Webview 渲染引擎解决问题，Chromium 侧的方案更加彻底主要两方面，一是 WebPlugin 机制刚好契合这个场景，再则微信自己维护私有的 Chromium ，可以从更加底层去支持。 回到 Canvas 2d 的话，同层渲染在两端表现差异不大，在其父节点上使用 transform 做 CSS 动画也能流畅运行。然，Android 端在小程序基础库2.8.x 初始化画布会有问题，表现为画布绘图成功却无法显示。 理论上的更优方案落地表现却不一定最优。 最后罗列一下 Key-points :

• Canvas 2d 具有更好的渲染表现
• Canvas 2d 在小程序基础库2.9.0起可用，虽官方文档标明2.7.0开始支持，但低于2.9.0 的基础库其 bug 感人且大多无解
• 企业微信基础库目前最高 2.8.3 故如小程序需支持企业微信端，则不要考虑 Canvas 2d
• Canvas 2d 需要同 Web Canvas 一样显式的设置画布大小，同时也有 Viewport 的概念
• 微信7.0.13之前在不同端没有做字体保护，画布 font 设置的字体如果手机没有，则会引起微信闪退，小米8必现
• 某些手机(三星 使用缺省写法也引起闪退，如 #333 得写完整 #333333
• Android 端无法导出3倍图，会报 errMsg: "canvasToTempFilePath:fail:convert native buffer parameter fail. native buffer exceed size limit." 解决方案是设定最大2倍图
• drawImage 只接受 HTMLImageElement ，需要先调用 Canvas.CreateImage
• CreateImage 返回的Image对象，本地图片无回调(onload，onerror)，解决方案是setTimeout手动触发、但企业微信还是会闪退，见3

困了，以上。