微信小程序“同层渲染”

背景

最近，在小程序的开发中，canvas被接触最多。在此期间，由于兼容性问题，它经历了底层API新旧版本的更替，踩过的坑让人印象深刻。小程序(微信)的画布与HTML标准的画布截然不同。甚至小程序画布的底层API都有两个大版本(其实古代有一个版本，只是太老了，没法研究)。两个现有版本的区别在于是否支持“同层渲染”。

同层渲染

小程序的内容大部分在WebView上呈现。如果把WebView看作一个单独的层，那么系统带来的这些原生组件就位于另一个更高的层次(比如画布和视频)。这两个级别是完全独立的，所以单纯使用z-index是不可能控制原生组件和非原生组件之间的相对级别的。您只能使用封面视图和封面图像在本机组件上实现。但是cover-view和cover-image支持的css样式非常有限，经过实践，cover-view在一些安卓机器上的表现确实很差。

“同层渲染”就是将原生组件直接渲染到WebView级别，这样就可以通过简单的z-index来控制级别，而且支持的css非常丰富，让马妈再也不用担心我遇到的级别问题了！它看起来不漂亮吗？然而，现实很残酷。

「同层渲染」存在的问题

首先，根据小程序的官方文章，几乎整个“原生组件”都进行了重构，使用方式和支持的功能与之前大不相同，与标准画布API非常相似，甚至官方宣称“支持标准画布的大部分属性方法”。但是根据我的实际项目经验，新的canvas API只在iOS上表现不错，在一些安卓机器上会出现很多怪异的行为。一个简单的例子是，当绘制多个相同的形状时，画笔似乎出现在“不稳定”的位置，这使得最终的绘制结果不可预测。另一个令人头疼的问题在于drawImage方法。旧apidraimage的第一个参数是图片路径，可以是本地路径，也可以是网络路径，但是新apidraimage的第一个参数必须是图片实例。由于小程序无法获取DOM元素，只能用官方提供的createImage方法创建图片实例，然后在其onLoad回调中再次调用drawImage实现原来的简单方法。等等。然而，这些都是可以克服的。最终导致我们放弃的原因是它在一些安卓机器上的“不确定性”。如果在“新特性”和“兼容性”之间选择，我觉得还是坚持“兼容性”比较好。就像“优雅的退化”和“逐渐增强”一样，我更喜欢后者。

「兼容性」下的「同层渲染」

相信大部分做过画布相关小程序的人，都有不同程度的困扰。既然新的API不能用，问题就要解决。最后，我们在旧的API中提出了一组类似的“同层渲染”效果。目前需要“同层渲染”的场景基本上都需要在画布上分层，所以在覆盖画布的时候不会同时操作画布，因为使用canvasToTempFilePath可以将画布临时转换成图片，然后隐藏画布，显示tempImage。

黎明的曙光

新画布API也不是没有它的优点。一个很大的变化就是不再用物理尺寸来画，而是用实际尺寸。这将使用新的API绘制的结果比原来的高得多，这是为数不多的优势之一。此外，新的画布应用编程接口在iOS上运行良好。希望以后官方能让新canvas API的兼容性更好，让开发者尽快摆脱这些临时解决方案。