- 前言略。。。大概就是,这是一个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:
- 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在后台校验词汇是否正确以及提供备选词汇。