摘要：可以將耗時任務(wù)拆解出去，降低主線程的壓力，避免主線程無響應(yīng)。主線程接收發(fā)消息每個實(shí)例通過接收消息，通過發(fā)送消息。收發(fā)主線程消息和主線程代碼類似，在代碼中，也是接收消息，這個消息來自主線程或者其它。

本周精讀的文章是 speedy-introduction-to-web-workers，是一篇 Web Workers 快速入門的文章，借精讀這篇文章的機(jī)會，談?wù)剬?Web Workers 的理解與運(yùn)用。

就像分工，你只負(fù)責(zé)編碼，而你的朋友負(fù)責(zé)設(shè)計，那你就可以專心把自己的事情做好，而且更快速的完成任務(wù)。

本文通過一個比方，描述了 Web Workers 的兩大特征：

高效。

并行。

因?yàn)闉g覽器是單線程的，任何大量耗時的 JS 任務(wù)都會卡住界面，使瀏覽器無法響應(yīng)任何操作，這樣的用戶體驗(yàn)非常糟糕。Web Workers 可以將耗時任務(wù)拆解出去，降低主線程的壓力，避免主線程無響應(yīng)。

但 CPU 資源是有限的，Web Workers 并不能增加總體運(yùn)行效率，算上通信的損耗，整體計算效率會有一定的下降。

const worker = new Worker("../src/worker.js");

上述代碼中，worker 就是一個 Web Workers 實(shí)例，執(zhí)行的代碼是 ../src/worker.js 路徑下的文件。

Web Workers 用來執(zhí)行異步腳本，只要掌握了它與主線程通信的方式，就可以在指定時機(jī)運(yùn)行異步腳本，并在運(yùn)行完時將結(jié)果傳遞給主線程。

const worker = new Worker("../src/worker.js");

worker.onmessage = e => {};

worker.postMessage("Marco!");

每個 worker 實(shí)例通過 onmessage 接收消息，通過 postMessage 發(fā)送消息。

self.onmessage = e => {};

self.postMessage("Marco!");

和主線程代碼類似，在 Web Workers 代碼中，也是 onmessage 接收消息，這個消息來自主線程或者其它 Workers。也可以通過 postMessage 發(fā)送消息。

worker.terminate();

文章內(nèi)容就這么多，是不是有寫太簡單了呢！筆者結(jié)合自己的使用經(jīng)驗(yàn)，再補(bǔ)充一些知識。

對象轉(zhuǎn)移就是將對象引用零成本轉(zhuǎn)交給 Web Workers 的上下文，而不需要進(jìn)行結(jié)構(gòu)拷貝。

這里要解釋的是，主線程與 Web Workers 之間的通信，并不是對象引用的傳遞，而是序列化/反序列化的過程，當(dāng)對象非常龐大時，序列化和反序列化都會消耗大量計算資源，降低運(yùn)行速度。

上面的圖充分證明了，大對象傳遞，使用對象轉(zhuǎn)移各項(xiàng)指標(biāo)都優(yōu)于結(jié)構(gòu)拷貝。

對象轉(zhuǎn)移使用方式很簡單，給 postMessage 增加一個參數(shù)，把對象引用傳過去即可：

var ab = new ArrayBuffer(1);
worker.postMessage(ab, [ab]);

瀏覽器兼容性也不錯：Currently Chrome 17+, Firefox, Opera, Safari, IE10+。更具體內(nèi)容，可以看 Transferable Objects: Lightning Fast!。

需要注意的是，對象引用轉(zhuǎn)移后，原先上下文就無法訪問此對象了，需要在 Web Workers 再次將對象還原到主線程上下文后，主線程才能正常訪問被轉(zhuǎn)交的對象。

Web Workers 優(yōu)勢這么大，但用起來需要在同域下創(chuàng)建一個 JS 文件實(shí)在不方便，尤其在前后端分離做的比較徹底的團(tuán)隊(duì)，前端團(tuán)隊(duì)能控制的僅僅是一個 JS 文件。那么下面給出幾個不用 JS 文件，就創(chuàng)建 Web Workers 的方法：

worker-loader 是一個 webpack 插件，可以將一個普通 JS 文件的全部依賴提取后打包并替換調(diào)用處，以 Blob 形式內(nèi)聯(lián)在源碼中。

import Worker from "worker-loader!./file.worker.js";

const worker = new Worker();

上述代碼的魔術(shù)在于，轉(zhuǎn)化成下面的方式執(zhí)行：

const blob = new Blob([codeFromFileWorker], { type: "application/javascript" });
const worker = new Worker(URL.createObjectURL(blob));

第二種方式由第一種方式自然帶出：如果不想用 webpack 插件，那自己通過 Blob 的方式創(chuàng)建也可以：

const code = `
  importScripts("https://xxx.com/xxx.js");
  self.onmessage = e => {};
`;

const blob = new Blob([code], { type: "application/javascript" });
const worker = new Worker(URL.createObjectURL(blob));

看上去代碼更輕量一些，不過問題是當(dāng)遇到復(fù)雜依賴時，如果不能把依賴都轉(zhuǎn)化為腳本通過 importScripts 方式引用，就無法訪問到主線程環(huán)境中的包。如果真的遇到了這個問題，可以用第一種 webpack 插件的方式解決，這個插件會自動把文件所有依賴都打包進(jìn)源碼。

為什么 postMessage 會形成隊(duì)列，為什么要管理它？

首先在 Web Workers 架構(gòu)設(shè)計上就必須做成隊(duì)列，因?yàn)檎{(diào)用 postMessage 時，對應(yīng)的 Web Workers 不一定完成了初始化，所以瀏覽器底層必須管理一個隊(duì)列，在 Web Workers 初始化完畢時，依次消費(fèi)，這樣才能確保任何時候發(fā)出的 postMessage 都能被 Web Workers 接收到。

其次，為什么要手動維護(hù)這個隊(duì)列，原因可能取決于如下幾點(diǎn)：

業(yè)務(wù)原因，前面的 postMessage 還沒來得及消費(fèi)，就不要發(fā)送新的消息，或者丟棄新的消息，這時候需要通過雙向通信拿到 Web Workers 的執(zhí)行結(jié)果回執(zhí)，手動控制隊(duì)列。

性能原因，一般 Web Workers 都會被用來執(zhí)行耗時的同步運(yùn)算，如果運(yùn)算時間比較長，那短期塞入多個消息隊(duì)列是沒有意義的。

如上圖所示，對于每次用戶輸入都要進(jìn)行的 SQL Parser 很耗時，及時放在 Web Workers 也可能導(dǎo)致將 Workers 撐爆到無響應(yīng)，這是不僅要使用多 Workers 緩沖池，還要對待執(zhí)行隊(duì)列進(jìn)行過濾，因?yàn)橛脩粲肋h(yuǎn)只關(guān)心最后一次輸入的 Parser 結(jié)果。

由于 Web Workers 運(yùn)算被卡住時，除了銷毀 Worker 沒有別的辦法，而銷毀 Worker 的成本比較高，不能對每一個用戶輸入都銷毀并新建 Web Workers，所以利用 Workers 緩沖池，當(dāng)緩沖池滿了，新的消費(fèi)隊(duì)列又進(jìn)來的時候，可以銷毀全部 Workers 緩沖池，換一批新緩沖池重新消費(fèi)用戶輸入。

Web Workers 是拆解異步計算的好幫手，vscode 網(wǎng)頁版也通過 Web Workers 異步完成代碼提示和高亮，筆者有對比過，發(fā)現(xiàn) Web Workers 性能提升非常明顯。

管理好你的 Web Workers 消息隊(duì)列，謹(jǐn)防同步計算讓 Web Workers 失去響應(yīng)！建立一個智能的消息隊(duì)列，根據(jù)業(yè)務(wù)需求設(shè)計一個最好的隊(duì)列消費(fèi)模型吧！

討論地址是：精讀《談?wù)?Web Workers》 · Issue #108 · dt-fe/weekly

如果你想?yún)⑴c討論，請點(diǎn)擊這里，每周都有新的主題，周末或周一發(fā)布。前端精讀 - 幫你篩選靠譜的內(nèi)容。