离屏Canvas — 使用Web Worker提升你的Canvas运行速度

如今由于有了离屏Canvas，你能够不用在你的主线程中绘制图像了！

　　Canvas 是一个很是受欢迎的表现方式，同时也是WebGL的入口。它能绘制图形，图片，展现动画，甚至是处理视频内容。它常常被用来在富媒体web应用中建立炫酷的用户界面或者是制做在线（web）游戏。

　　它是很是灵活的，这意味着绘制在Canvas的内容能够被编程。举个🌰，JavaScript就提供了Canvas的系列API。这些给了Canvas很是好的灵活度。

　　但同时，在一些现代化的web站点，脚本解析运行是实现流畅用户反馈的最大的问题之一。由于Canvas计算和渲染和用户操做响应都发生在同一个线程中，在动画中（有时候很耗时）的计算操做将会致使App卡顿，下降用户体验。

　　幸运的是, OffscreenCanvas 离屏Canvas能够很是棒的解决这个麻烦！

　　到目前为止，Canvas的绘制功能都与<canvas>标签绑定在一块儿，这意味着Canvas API和DOM是耦合的。而OffscreenCanvas，正如它的名字同样，经过将Canvas移出屏幕来解耦了DOM和Canvas API。

　　因为这种解耦，OffscreenCanvas的渲染与DOM彻底分离了开来，而且比普通Canvas速度提高了一些，而这只是由于二者（Canvas和DOM）之间没有同步。但更重要的是，将二者分离后，Canvas将能够在Web Worker中使用，即便在Web Worker中没有DOM。这给Canvas提供了更多的可能性。

　在Worker中使用OffscreenCanvas

　　Workers 是一个Web版的线程——它容许你在幕后运行你的代码。将你的一部分代码放到Worker中能够给你的主线程更多的空闲时间，这能够提升你的用户体验度。就像其没有DOM同样，直到如今，在Worker中都没有Canvas API。

　　而OffscreenCanvas并不依赖DOM，因此在Worker中Canvas API能够被某种方法来代替。下面是我在Worker中用OffscreenCanvas来计算渐变颜色的🌰：

// file: worker.js

function getGradientColor(percent) {
    const canvas = new OffscreenCanvas(100, 1);
    const ctx = canvas.getContext('2d');
    const gradient = ctx.createLinearGradient(0, 0, canvas.width, 0);
    gradient.addColorStop(0, 'red');
    gradient.addColorStop(1, 'blue');
    ctx.fillStyle = gradient;
    ctx.fillRect(0, 0, ctx.canvas.width, 1);
    const imgd = ctx.getImageData(0, 0, ctx.canvas.width, 1);
    const colors = imgd.data.slice(percent * 4, percent * 4 + 4);
    return rgba(${colors[0]}, ${colors[1]}, ${colors[2]}, ${colors[]);
}

getGradientColor(40);  // rgba(152, 0, 104, 255 )</pre>

　不要阻塞主线程

　　当咱们将大量的计算移到Worker中运行时，能够释放主线程上的资源，这颇有意思。咱们可使用transferControlToOffscreen 方法将常规的Canvas映射到OffscreenCanvas实例上。以后全部应用于OffscreenCanvas的操做将自动呈如今在源Canvas上。

const offscreen = document.querySelector('canvas').transferControlToOffscreen();
const worker = new Worker('myworkerurl.js');
worker.postMessage({ canvas: offscreen }, [offscreen]);</pre>

　　OffscreenCanvas 是 可转移的](https://developer.mozilla.org...。除了将其指定为传递信息中的字段之一之外，还须要将其做为postMessage（传递信息给Worker的方法）中的第二个参数传递出去，以即可以在Worker线程的context（上下文）中使用它。

　　在下面的🌰中，当颜色主题发生变化时会发生“复杂的计算”，这个计算即便在高性能的台式机上也要花费几毫秒。而你能够选择在主线程或Worker上运行这段动画。在主线程下，当复杂计算开始运行时，你将没法与按钮交互 - 线程被阻塞掉了。而在Worker下，UI的响应并无被影响。

　　Demo

　　它也是另外一种解释方式：任务繁忙的主线程也不会影响在Worker上运行的动画。因此即便主线程很是繁忙，你也能够经过此功能来避免掉帧并保证流畅的动画：

　　Demo

　　上例展现了在普通Canvas的下，当主线程被添加繁忙任务时动画被阻塞了，而基于Worker的OffscreenCanvas播放却很流利。

　与流行库一块儿使用

　　得益于OffscreenCanvas API通常状况下与常规Canvas元素的相API兼容，你能够很轻松地渐进地使用它，也可使用社区里的一些优秀的图形处理的库/框架。

　　举个🌰，你能够对其进行特征检测，若是可用的话，可经过在渲染的构造函数中指定canvas的配置项，而后实现与Three.js一块儿使用的功能：

const canvasEl = document.querySelector("canvas");
const canvas = ('OffscreenCanvas' in window) ? canvasEl.transferControlToOffscreen() : canvasEl;
canvas.style = { width: 0, height: 0 }
const renderer = new THREE.WebGLRenderer({ canvas: canvas });</pre>

　　上例的问题是Three.js须要Canvas具备style.width和style.height属性。而OffscreenCanvas是与DOM彻底分离的，没有这些属性。因此你须要本身提供这些属性，或者经过将其从three.js逻辑中删除或者自行编写这些值与初始Canvas尺寸相关联的逻辑。

　　下面是一个运行基本Three.js动画的demo：

　　Demo

　　可是请记住，有一些与DOM相关的API在Worker中并不容易得到，所以若是你想使用更高级的Three.js功能（好比纹理）的话，可能须要更多变通的方法。有关这方面已经开始尝试的一些想法，请查看 Google I/O 2017的视频。

　　此视频的示例中出现的commit()方法咱们并不推荐。请改用worker.requestAnimationFrame。

　结论

　　若是你对图像绘画使用得很是多，OffscreenCanvas能够有效的提升你APP的性能。它使得Worker能够处理canvas的渲染绘制，让你的APP更好地利用了多核系统。

　　OffscreenCanvas在Chrome 69中已经不须要开启flag（实验性功能）就可使用了。它也正在被 Firefox 实现。因为其API与普通canvas元素很是类似，因此你能够轻松地对其进行特征检测并按部就班地使用它，而不会破坏现有的APP或库的运行逻辑。OffscreenCanvas在任何涉及到图形计算以及动画表现且与DOM关系并不密切（即依赖DOM API很少）的状况下，它都具备性能优点。