Javascript是如何工作的---Web Workers的原
2018-12-06 本文已影响0人
ITgecko
- 前言略。。。大概就是，这是一个javascript系列文章的第七篇，然后推荐了一个应用SessionStack。原文地址: https://blog.sessionstack.com/how-javascript-works-the-building-blocks-of-web-workers-5-cases-when-you-should-use-them-a547c0757f6a
- 这次我们将来逐步理解Web Workers：首先是一个大致的概念介绍、讨论不同类型的workers、他们的组成部分是如何一起工作的、以及在不同场景下他们的优势和局限性。
- 你应该已经知道了javascript是运行在单线程环境中，但同时js也为开发者提供了写异步代码的机会。
异步编程的局限性
- 异步编程可以让你的应用的UI界面是响应式(渲染速度快)的，通过"调度部分代码"，让他们在event loop中晚一点再执行，这样就允许UI渲染的优先级最高了。
- 异步编程一个比较好的使用场景就是ajax请求，因为向服务端发送的请求会花费很多时间，所以他们应该是异步的，当客户端在等待返回时可以执行其他的代码。
// This is assuming that you're using jQuery
jQuery.ajax({
url: 'https://api.example.com/endpoint',
success: function(response) {
// Code to be executed when a response arrives.
}
});
- 然而这里还是会有问题，一个ajax请求可以经由浏览器的API来处理，但其他的代码如何异步地处理呢？举个例子，如果ajax请求的success成功的回调函数里，执行的代码是CPU密集型(CPU intensive)的代码：
var result = performCPUIntensiveCalculation();
-
performCPUIntensiveCalculation不是一个http请求而是一堆阻塞代码(比如一大堆for循环)，就没有办法及时清空事件循环，浏览器的UI渲染就会被阻塞，页面无法及时响应给用户。 - 这意味着异步函数，只能解决一小部分在js语言单线程中的局限性问题。
- 在有的时候，遇到花费大量计算时间的代码时，可以使用
setTimeout来暂时跳过，让浏览器去渲染页面。比如，把复杂计算的代码依次放在单独的setTimeout回调函数里执行，就把他们放在事件循环里的不同位置，这样就能节省时间来执行UI渲染、响应。 - 我们来看下这个计算数字数组平均数的函数：
function average(numbers) {
var len = numbers.length,
sum = 0,
i;
if (len === 0) {
return 0;
}
for (i = 0; i < len; i++) {
sum += numbers[i];
}
return sum / len;
}
- 上面代码可以重写为模仿异步代码的形式:
function averageAsync(numbers, callback) {
var len = numbers.length,
sum = 0;
if (len === 0) {
return 0;
}
function calculateSumAsync(i) {
if (i < len) {
// Put the next function call on the event loop.
setTimeout(function() {
sum += numbers[i];
calculateSumAsync(i + 1);
}, 0);
} else {
// The end of the array is reached so we're invoking the callback.
callback(sum / len);
}
}
calculateSumAsync(0);
}
- 这里就是利用了setTimeout函数，把每一步的计算往事件循环的后面放，在每次计算(setTimeout)之间可以让其他的代码继续执行，从而可以让浏览器进行渲染。
webWorker可以解决问题
- HTML5提供了很多开箱即用(out of the box)的好东西，包括：
- SSE
- Geolocation
- Application cache
- Local Storage
- Drag and Drop
- Web Workers
- web workers是在浏览器内的线程，可以执行JavaScript代码，同时不会阻塞事件循环。
- 这确实是很不错的。整个JavaScript的范式(paradigm)都是基于单线程的，但随着web worker的到来，单线程编程的局限性就被(部分地)解决了
- web workers允许把那些运行时间长、或者计算很耗时的代码放到后台执行，从而不会阻塞UI渲染，让你的应用更加的响应式。这样，更不需要使用setTimeout这种小技巧来实现异步代码了。
- 这里有个简单的demo，对一个长数组排序，是否使用webworker的对比，很明显就是不使用webworker的情况，在计算过程中页面是有明显的卡顿的，只有等计算结果出来后才能继续交互。
Web Worker概述
- web worker允许你用运行时间很长的代码来处理计算密集型的任务，同时还不会阻塞UI。事实上，他们都是并行运行的，Web Workers实际上就是多线程。
- 你可能会问：“JavaScript不是一个单线程的语言吗？”
- 事实上：JavaScript是一个语言，它并没有规定一个线程模式。Web Workers并不是JavaScript的一部分，它是浏览器的特性，通过JavaScript语言来实现的。大多数浏览器都经历过单线程(曾经，当然现在改成多线程了)，大多数的JavaScript的实现发生在浏览器中。Web Workers不能应用于Node.js中，Node.js中有类似的集群(cluster)、子进程概念(child_process)，他们也是多线程但是和Web Workers还是有区别。
- 值得注意的是，规范提到了三种类型的Web Workers:
- 专有workers(Dedicated Workers)
- 共享workers(Shared Workers)
- 服务workers(Service workers)
Dedicated Workers
- 专有workers由主进程来生成，并且他只能与主进程交流。
Shared Workers
- 共享Workers在同一源(origin)下面的各种进程都可以访问它，包括：iframes、浏览器中的不同tab页(一个tab页就是一个单独的进程，所以shared workers可以用来实现tab页之间的交流)、以及其他的共享workers。
Service workers
- 服务worker是一种注册了地址源(origin)和路径的事件驱动的worker，他可以控制与它关联的网站、对导航以及资源请求，进行拦截和修改。还可以缓存资源，让你的网站能在很好的处理某些特定情况(比如失去网络连接后)。总之他就是类似于一个浏览器与服务器中间的代理服务器。
- 本文主要讨论专有workers，没有特别声明的话，web workers、workers都是指代的专有workers。
web workers如何工作的
- web workers通过一个单独的
.js文件实现，在页面中还通过了一些异步的HTTP请求，这些请求是完全被隐藏了的，你只需要调用web workers提供的API。 - workers利用类似于线程间的消息传递，来实现并行。他们完美地保证你的UI是实时的、高性能的、响应式的呈现给用户。
- Web Workers是在浏览器的一个独立的线程中运行，因此他们的代码需要放在一个单独的js文件中，这点很重要。
- 我们来看下一个基本的worker如何创建：
let worker = new Worker('task.js');
- 当这个"task.js"文件存在并且可访问的话，浏览器就会分配出一个线程，去异步地下载这个文件。下载完成后，就去执行这个文件，worker就开始工作了。
- 当js文件的地址失效，返回404时，worker就会静默地停止。
- 为了启动已经创建好的worker，你需要调用
postmessage方法：
worker.postMessage();
Web Worker通信
- 为了实现Web Worker和页面之间的通信，需要调用
postMessage方法，或者通过BroadcastChannel接口。
postMessage方法
- 新的浏览器支持传一个JSON对象作为第一个参数，老的浏览器只能传string类型。
- 我们来看一个例子，一个页面创建一个worker，然后前后如何与它通信，传递一个JSON对象相对更复杂一点，传字符串的话都是一样的。
- 我们来看一下html中的一部分代码：
<button onclick="startComputation()">Start computation</button>
<script>
function startComputation() {
worker.postMessage({'cmd': 'average', 'data': [1, 2, 3, 4]});
}
var worker = new Worker('doWork.js');
worker.addEventListener('message', function(e) {
console.log(e.data);
}, false);
</script>
- 然后这是worker中的js代码：
self.addEventListener('message', function(e) {
var data = e.data;
switch (data.cmd) {
case 'average':
var result = calculateAverage(data); // Some function that calculates the average from the numeric array.
self.postMessage(result);
break;
default:
self.postMessage('Unknown command');
}
}, false);
- 当点击按钮时，主页面会调用
postMessage方法。传递了一个JSON对象给worker，然后worker中通过监听message，在回调函数中处理传过来的信息。 - 当message到达时，计算是在worker中进行的，所以不会阻塞主页面的事件循环。worker中处理事件
e的过程，就和标准函数一样。处理完成后，result就会被返回给主页面。 - 在worker作用域中，
this和self都指向worker的全局作用域。
有两种方法停止worker：在主页面调用
worker.terminate()或者在worker里面调用self.close()。
Broadcast Channel
- Broadcast Channel是一种更常用的通信方法，他允许我们广播(Broadcast)发送消息给所有同源的上下文环境(context)。所有的浏览器tab页面、iframes或者同源下的workers都可以发送以及接收消息:
// Connection to a broadcast channel
var bc = new BroadcastChannel('test_channel');
// Example of sending of a simple message
bc.postMessage('This is a test message.');
// Example of a simple event handler that only
// logs the message to the console
bc.onmessage = function (e) {
console.log(e.data);
}
// Disconnect the channel
bc.close()
-
可以从下面这张图，在视觉上来清晰地感受Broadcast Channel：
image
- Broadcast Channel目前只有新版本的chrome、Firefox浏览器支持。
消息的大小
- 有两种传输消息给worker的方法：
- 复制消息(传递的拷贝值)：传递的消息内容会被序列化、复制、然后发送，然后在接收端反序列化。页面和worker之间不会使用同一个实例，最后传输的结果都是在两边生成的拷贝对象。大多数浏览器，在两边都是使用的JSON对值进行编码和解码。这样对数据的解码、编码操作，势必会增加消息传输过程的时间开销。越大的消息，传输的耗时越长。
- 传输消息(传输原对象)：直接传递值意味着，发送端一旦发送了数据，就无法再使用该值了。传输数据的过程几乎是瞬时的，这种传输方式的局限性在于只能用ArrayBuffer类型来传递。
web workers可使用的特性
- 由于web workers的多线程性质、他只能使用JavaScript的特性的一个子集。下面是它可以使用的特性列表：
- navigator对象
- location对象(只可读)
- XMLHttpRequest
- setTimeout()/clearTimeout() 和 setInterval()/clearInterval()
- 应用缓存(Application Cache)
- 通过
importScripts()函数引入额外的JavaScript代码 - 创建其他的web workers
web workers的局限性
- 遗憾的是，worker无法使用一些重要的JavaScript特性：
- DOM(会造成线程不安全)
- window对象
- document对象
- parent对象(浏览器中就是等于window对象)
- 意味着worker不能操作DOM(也就是UI)。你可能觉得这样限制会很麻烦，但一旦你学会如何正确的使用web workers，你就明白在你使用worker计算代码时，页面的UI是会同时发生变化的，因此worker里面不允许操作DOM。worker会帮你处理繁重的任务，然后一旦完成再把结果返回给page页面。
处理错误
- 和任何js代码一样，web workers里抛出的错误，你也需要进行处理。当worker执行过程中如果遇到错误，会触发一个
ErrorEvent事件。接口包含了三个有用的属性来帮忙排查问题：- ** filename**-出错的worker的名字
- ** lineno**-出错的代码所在行数
- ** message**-对错误的描述
- 这里是一个处理错误的例子：
function onError(e) {
console.log('Line: ' + e.lineno);
console.log('In: ' + e.filename);
console.log('Message: ' + e.message);
}
var worker = new Worker('workerWithError.js');
worker.addEventListener('error', onError, false);
worker.postMessage(); // Start worker without a message.
- 当你在worker中写下一些会报错的代码后，就可以监听到错误事件了。一旦出错，会把错误抛到原页面，然后通过页面监听error事件，对错误进行捕获。
web worker好的应用实例
- 至此我们已经列举了web workers的强大和缺陷，接下来看下基于它有什么强大的应用实例：
- Ray tracing: Ray tracing是一种用于生成图片的渲染技术，它以像素为单位追踪光的轨迹。Ray tracing为了模拟光的路径，需要大量的计算。这种想法是为了，模拟光的行为：比如折射、反射、介质等等。所有的这些计算逻辑可以放到web worker中执行，以免阻塞UI渲染。你可以把渲染图片的功能分割给多个不同的workers一起执行(多个CPU分开运行)，这里是一个ray tracing基于web workers的示例—— https://nerget.com/rayjs-mt/rayjs.html.
- Encryption(加密)：端到端的加密现在越来越流行了，因为基于人们的规章制度越来越严厉、以及一些敏感内容。加密也是一个相当耗时的工作，尤其是如果遇到大量的数据需要频繁的加密(比如请求发送给后端之前需要先加密)。这就是一个非常适合使用web worker的场景，不需要去访问dom或者其他东西，只需要纯算法来完成工作。只要是在web worker中工作的，对于端用户就是无缝的，不会影响到体验。
- Prefetching data(预取数据)：为了优化你的网站、加快数据加载的速度，你可以利用web worker来加载一些数据，事先存储好后面会使用到的数据。这种场景也是非常神奇的，因为他会在不影响UI加载的前提下加载数据。
- Progressive Web Apps(响应式的web应用)：这种web应用要求，即使在用户弱网条件下，也能够迅速的加载。这意味着数据需要本地存储在浏览器上(就是本地持久化)。这里就是IndexDB或其他类型的API来扮演的工作。通常情况下，客户端的存储都是必要的，但使用起来需要不阻塞UI渲染线程，那么工作就需要在worker中进行了。不过，以IndexDB为例，它提供了一些异步的API，调用它们的话也不需要使用web worker，但如果是同步的API，就必须要在worker中使用了。
- Spell checking(拼写检查)：一个基本的拼写检查器应该按以下顺序来工作：程序去读取一个存放有拼写正确单词的字典文件；字典内容被解析为一个搜索树(search tree)来确保文本搜索的效率；当一个词汇传递给检查器时，检查器会在之前生成好的搜索树中检查它是否存在；如果不存在，用户应该会看到一些可选择的拼写单词，这些备选单词通过替换一些字母并保证最后是有效的，所以在用户可能输错的情况下，他真正想要输入的词汇就出现在备选词汇中了。所有的这些处理过程都可以在web worker中进行了，用户可以不被阻塞的输入词汇和句子，web worker在后台校验词汇是否正确以及提供备选词汇。
