现在因为有了离屏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 )
不要阻塞主线程
当我们将大量的计算移到Worker中运行时，可以释放主线程上的资源，这很有意思。我们可以使用transferControlToOffscreen 方法将常规的Canvas映射到OffscreenCanvas实例上。之后所有应用于OffscreenCanvas的操作将自动呈现在在源Canvas上。
const offscreen = document.querySelector('canvas').transferControlToOffscreen();
const worker = new Worker('myworkerurl.js');
worker.postMessage({ canvas: offscreen }, [offscreen]);
OffscreenCanvas 是 [可转移的](developer.mozilla.org/en-US/docs/…)。除了将其指定为传递信息中的字段之一以外，还需要将其作为postMessage（传递信息给Worker的方法）中的第二个参数传递出去，以便可以在Worker线程的context（上下文）中使用它。
在下面的🌰中，当颜色主题发生变化时会发生“复杂的计算”，这个计算即使在高性能的台式机上也要花费几毫秒。而你可以选择在主线程或Worker上运行这段动画。在主线程下，当复杂计算开始运行时，你将无法与按钮交互 - 线程被阻塞掉了。而在Worker下，UI的响应并没有被影响。
它也是另一种解释方式：任务繁忙的主线程也不会影响在Worker上运行的动画。所以即使主线程非常繁忙，你也可以通过此功能来避免掉帧并保证流畅的动画：
上例展示了在普通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 });
上例的问题是Three.js需要Canvas具有style.width和style.height属性。而OffscreenCanvas是与DOM完全分离的，没有这些属性。所以你需要自己提供这些属性，或者通过将其从three.js逻辑中删除或者自行编写这些值与初始Canvas尺寸相关联的逻辑。
下面是一个运行基本Three.js动画的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不多）的情况下，它都具有性能优势。
