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

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

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

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

高效。

并行。

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

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

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

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

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

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

worker.onmessage = e => {};

worker.postMessage("Marco!");

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

self.onmessage = e => {};

self.postMessage("Marco!");

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

worker.terminate();

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

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

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

上面的圖充分證明了，大對象傳遞，使用對象轉(zhuǎn)移各項指標(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 文件實在不方便，尤其在前后端分離做的比較徹底的團(tuán)隊，前端團(tuán)隊能控制的僅僅是一個 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 會形成隊列，為什么要管理它？

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

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

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

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

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

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

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

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

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

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