Web Worker 概述

Web Worker 的作用，就是為 JavaScript 創(chuàng)造多線程環(huán)境，允許主線程創(chuàng)建 Worker 線程，將一些任務(wù)分配給后者運(yùn)行。在主線程運(yùn)行的同時(shí)，Worker 線程在后臺(tái)運(yùn)行，兩者互不干擾。等到 Worker 線程完成計(jì)算任務(wù)，再把結(jié)果返回給主線程。這樣的好處是，一些計(jì)算密集型或高延遲的任務(wù)，被 Worker 線程負(fù)擔(dān)了，主線程(通常負(fù)責(zé) UI 交互)就會(huì)很流暢，不會(huì)被阻塞或拖慢。

你可能會(huì)問(wèn)：“JavaScript不是一個(gè)單線程的語(yǔ)言嗎？”

事實(shí)上 JavaScript 是一種不定義線程模型的語(yǔ)言。Web Workers 不是 JavaScript 的一部分，而是可以通過(guò) JavaScript 訪問(wèn)的瀏覽器特性。歷史上，大多數(shù)瀏覽器都是單線程的(當(dāng)然，這已經(jīng)改變了)，大多數(shù) JavaScript 實(shí)現(xiàn)都是發(fā)生在瀏覽器中。Web Workers 不是在 Node.JS 中實(shí)現(xiàn)的。Node.js 中有類似的集群(cluster)、子進(jìn)程概念(child_process)，他們也是多線程，但是和 Web Workers 還是有區(qū)別 。

值得注意的是，規(guī)范中提到了三種類型的 Web Workers:

• 專用 Workers (Dedicated Workers)
• 共享 Workers (Shared Workers)
• 服務(wù) Workers (Service workers)

Dedicated Workers

專用 Workers 只能被創(chuàng)建它的頁(yè)面訪問(wèn)，并且只能與它通信。以下是瀏覽器支持的情況：

Shared Workers

共享 Workers 在同一源(origin)下面的各種進(jìn)程都可以訪問(wèn)它，包括：iframes、瀏覽器中的不同tab頁(yè)(一個(gè)tab頁(yè)就是一個(gè)單獨(dú)的進(jìn)程，所以Shared Workers可以用來(lái)實(shí)現(xiàn) tab 頁(yè)之間的交流)、以及其他的共享 Workers。以下是瀏覽器支持的情況：

Service workers

Service Worker 功能：

• 后臺(tái)消息傳遞
• 網(wǎng)絡(luò)代理，轉(zhuǎn)發(fā)請(qǐng)求，偽造響應(yīng)
• 離線緩存
• 消息推送

在目前階段，Service Worker 的主要能力集中在網(wǎng)絡(luò)代理和離線緩存上。具體的實(shí)現(xiàn)上，可以理解為 Service Worker 是一個(gè)能在網(wǎng)頁(yè)關(guān)閉時(shí)仍然運(yùn)行的 Web Worker。以下是瀏覽器支持的情況：

本文主要討論 專用 Workers，沒(méi)有特別聲明的話，Web Workers、Workers都是指代的專用 Workers。

Web Workers 是如何工作

Web Workers 一般通過(guò)腳本為 .js 文件來(lái)構(gòu)建，在頁(yè)面中還通過(guò)了一些異步的 HTTP 請(qǐng)求，這些請(qǐng)求是完全被隱藏了的，你只需要調(diào)用 Web Worker API。

Worker 利用類線程間消息傳遞來(lái)實(shí)現(xiàn)并行性。它們保證界面的實(shí)時(shí)性、高性能和響應(yīng)性呈現(xiàn)給用戶。

Web Workers 在瀏覽器中的一個(gè)獨(dú)立線程中運(yùn)行。因此，它們執(zhí)行的代碼需要包含在一個(gè)**單獨(dú)的文件中**。這一點(diǎn)很重要，請(qǐng)記住！

讓我們看看基本 Workers 是如何創(chuàng)建的:

var worker = new Worker('task.js');

Worker() 構(gòu)造函數(shù)的參數(shù)是一個(gè)腳本文件，該文件就是 Worker 線程所要執(zhí)行的任務(wù)。由于 Worker 不能讀取本地文件，所以這個(gè)腳本必須來(lái)自網(wǎng)絡(luò)。如果下載沒(méi)有成功(比如404錯(cuò)誤)，Worker 就會(huì)默默地失敗。

為了啟動(dòng)創(chuàng)建的 Worker，需要調(diào)用 postMessage 方法:

worker.postMessage();

Web Worker 通信

為了在 Web Worker 和創(chuàng)建它的頁(yè)面之間進(jìn)行通信，需要使用 postMessage 方法或 Broadcast Channel。

postMessage 方法

新瀏覽器支持JSON對(duì)象作為方法的第一個(gè)參數(shù)，而舊瀏覽器只支持字符串。

來(lái)看一個(gè)示例，通過(guò)將 JSON 對(duì)象作為一個(gè)更“復(fù)雜”的示例傳遞，創(chuàng)建 Worker 的頁(yè)面如何與之通信。傳遞字符串跟傳遞對(duì)象的方式也是一樣的。

讓我們來(lái)看看下面的 HTML 頁(yè)面(或者更準(zhǔn)確地說(shuō)是它的一部分):

然后這是 worker 中的 js 代碼：

當(dāng)單擊該按鈕時(shí)，將從主頁(yè)調(diào)用 postMessage。postMessage 行將 JSON 對(duì)象傳給 Worker。Worker 通過(guò)定義的消息處理程序監(jiān)聽(tīng)并處理該消息。

當(dāng)消息到達(dá)時(shí)，實(shí)際的計(jì)算在worker中執(zhí)行，而不會(huì)阻塞事件循環(huán)。Worker 檢查傳遞的事件參數(shù) `e`，像執(zhí)行 JavaScript 函數(shù)一樣,處理完成后，把結(jié)果傳回給主頁(yè)。

在 Worker 作用域中，this 和 self 都指向 Worker 的全局作用域。

有兩種方法可以停止 Worker:從主頁(yè)調(diào)用 worker.terminate()或在 worker 內(nèi)部調(diào)用 self.close()。

Broadcast Channel

Broadcast Channel API 允許同一原始域和用戶代理下的所有窗口,iFrames 等進(jìn)行交互。也就是說(shuō)，如果用戶打開(kāi)了同一個(gè)網(wǎng)站的的兩個(gè)標(biāo)簽窗口，如果網(wǎng)站內(nèi)容發(fā)生了變化，那么兩個(gè)窗口會(huì)同時(shí)得到更新通知。

還是不明白？就拿 Facebook 作為例子吧，假如你現(xiàn)在已經(jīng)打開(kāi) 了Facebook 的一個(gè)窗口，但是你此時(shí)還沒(méi)有登錄，此時(shí)你又打開(kāi)另外一個(gè)窗口進(jìn)行登錄，那么你就可以通知其他窗口/標(biāo)簽頁(yè)去告訴它們一個(gè)用戶已經(jīng)登錄了并請(qǐng)求它們進(jìn)行相應(yīng)的頁(yè)面更新。

可以從下面這張圖，在視覺(jué)上來(lái)清晰地感受 Broadcast Channel：

Broadcast Channel 瀏覽器支持比較有限:

消息的大小

有兩種方式發(fā)送消息給Web Workers:

復(fù)制消息：消息被序列化、復(fù)制、發(fā)送，然后在另一端反序列化。頁(yè)面和 Worker 不共享相同的實(shí)例，因此最終的結(jié)果是每次傳遞都會(huì)創(chuàng)建一個(gè)副本大多數(shù)瀏覽器，在兩邊都是使用的JSON對(duì)值進(jìn)行編碼和解碼，這樣對(duì)數(shù)據(jù)的解碼、編碼操作，勢(shì)必會(huì)增加消息傳輸過(guò)程的時(shí)間開(kāi)銷。信息越大，發(fā)送的時(shí)間就越長(zhǎng)。

傳遞消息：這意味著原始發(fā)送方在一旦發(fā)送后不能再使用它。傳輸數(shù)據(jù)幾乎是瞬間的，這種傳輸方式的局限性在于只能用 ArrayBuffer 類型來(lái)傳遞。

Web Workers 可用的特性

Web Workers 由于具有多線程特性，因此只能訪問(wèn) JavaScript 特性的子集。 以下是可使用特性列表：

• navigator 對(duì)象
• location 對(duì)象(只讀)
• XMLHttpRequest
• setTimeout()/clearTimeout() and setInterval()/clearInterval()
• 應(yīng)用緩存(Application Cache)
• 使用 importScripts() 導(dǎo)入外部腳本
• 創(chuàng)建其他的 Web Workers

Web Workers 的局限性

同源限制

分配給 Worker 線程運(yùn)行的腳本文件，必須與主線程的腳本文件同源。

DOM 限制

Worker 線程所在的全局對(duì)象，與主線程不一樣，無(wú)法讀取主線程所在網(wǎng)頁(yè)的 DOM 對(duì)象，也無(wú)法使用document、window、parent這些對(duì)象。這意味著 Web Worker 不能操作 DOM (因此也不能操作 UI)。有時(shí)這可能很棘手，但是一旦你了解了如何正確使用 Web Workers，你就會(huì)開(kāi)始將它們作為單獨(dú)的“計(jì)算機(jī)”使用，而所有 UI 更改都將發(fā)生在你的頁(yè)面代碼中。 Workers 將為你完成所有繁重的工作，然后一旦完成再把結(jié)果返回給 page 頁(yè)面。

通信聯(lián)系

Worker 線程和主線程不在同一個(gè)上下文環(huán)境，它們不能直接通信，必須通過(guò)消息完成。

腳本限制

Worker 線程不能執(zhí)行alert()方法和confirm()方法，但可以使用 XMLHttpRequest 對(duì)象發(fā)出 AJAX 請(qǐng)求。

文件限制

Worker 線程無(wú)法讀取本地文件，即不能打開(kāi)本機(jī)的文件系統(tǒng)(file://)，它所加載的腳本，必須來(lái)自網(wǎng)絡(luò)。

處理錯(cuò)誤

和 JavaScript 代碼一樣，Web workers 里拋出的錯(cuò)誤，你也需要進(jìn)行處理。當(dāng) Worker 執(zhí)行過(guò)程中如果遇到錯(cuò)誤，會(huì)觸發(fā)一個(gè) `ErrorEvent` 事件。接口包含了三個(gè)有用的屬性來(lái)幫忙排查問(wèn)題：

filename - 導(dǎo)致 Worker 的腳本名稱

lineno - 發(fā)生錯(cuò)誤的行號(hào)

message - 對(duì)錯(cuò)誤的描述

例子如下：

在這里，可以看到我們創(chuàng)建了一個(gè) worker 并開(kāi)始偵聽(tīng)錯(cuò)誤事件。

在 worker 內(nèi)部(在 workerWithError.js 中)，我們通過(guò)將未定義 x 乘以 2 來(lái)創(chuàng)建一個(gè)異常。異常被傳播到初始腳本，然后通過(guò)頁(yè)面監(jiān)聽(tīng) error事件，對(duì)錯(cuò)誤進(jìn)行捕獲。

Web Workers 應(yīng)用實(shí)例

到目前為止，我們已經(jīng)列出了 Web Workers 的優(yōu)點(diǎn)和局限性。現(xiàn)在讓我們看看它們最強(qiáng)大的用例是什么:

Ray tracing(光線追蹤)：光線追蹤是一種以像素為單位跟蹤光的路徑生成圖像的渲染技術(shù)。光線追蹤利用 CPU 密集型的數(shù)學(xué)計(jì)算來(lái)模擬光的路徑。其思想是模擬一些效果，如反射、折射、材料等。所有這些計(jì)算邏輯都可以添加到 Web Worker 中，以避免阻塞 UI線程。更好的是——可以很容易地在多個(gè) workers 之間(以及在多個(gè)cpu之間)分割圖像呈現(xiàn)。下面是一個(gè)使用 Web Workers 的光線追蹤的簡(jiǎn)單演示—https://nerget.com/rayjs-mt/rayjs.html。

Encryption(加密)：由于對(duì)個(gè)人和敏感數(shù)據(jù)的監(jiān)管越來(lái)越嚴(yán)格，端到端加密越來(lái)越受歡迎。加密是一件非常耗時(shí)的事情，特別是如果有很多數(shù)據(jù)需要頻繁加密(例如，在發(fā)送到服務(wù)器之前)。這是一個(gè)使用 Web Worker 非常好的場(chǎng)景，因?yàn)樗恍枰L問(wèn) DOM 或任何花哨的東西——它是完成其工作的純算法。只要是在 Web Worker 中工作的，對(duì)于端用戶就是無(wú)縫的，不會(huì)影響到體驗(yàn)。

Prefetching data(預(yù)取數(shù)據(jù))：為了優(yōu)化你的網(wǎng)站或 web 應(yīng)用程序并改進(jìn)數(shù)據(jù)加載時(shí)間，你可以利用 Web Workers 提前加載和存儲(chǔ)一些數(shù)據(jù)，以便在需要時(shí)稍后使用。Web Workers 在這種情況下非常棒，因?yàn)樗鼈儾粫?huì)影響應(yīng)用程序的UI，這與不使用Workers 時(shí)是不同的。

Progressive Web Apps(漸進(jìn)式Web應(yīng)用程序)：這種漸進(jìn)式Web應(yīng)用程序要求，即使在用戶網(wǎng)絡(luò)不穩(wěn)定的條件下，也能夠迅速的加載。這意味著數(shù)據(jù)必須本地存儲(chǔ)在瀏覽器中。這也是 IndexDB 或類似 api 發(fā)揮作用的地方。通常情況下，客戶端的存儲(chǔ)都是必要的，但使用起來(lái)需要不阻塞UI渲染線程，那么工作就需要在 Worker 中進(jìn)行了。不過(guò)，以IndexDB 為例，它提供了一些異步的API，調(diào)用它們的話也不需要使用 web worker，但如果是同步的 API，就必須要在 Worker 中使用了。

Spell checking(拼寫(xiě)檢查)：一個(gè)基本的拼寫(xiě)檢查程序的工作流程如下-程序讀取一個(gè)字典文件與一個(gè)正確拼寫(xiě)單詞列表。字典被解析為一個(gè)搜索樹(shù)，以使實(shí)際的文本搜索更有效。當(dāng)一個(gè)單詞被提供給檢查器時(shí)，程序檢查它是否存在于預(yù)先構(gòu)建的搜索樹(shù)中。如果在樹(shù)中沒(méi)有找到該單詞，可以通過(guò)替換替換字符并測(cè)試它是否是有效的單詞(如果是用戶想要寫(xiě)的單詞)，為用戶提供替代拼寫(xiě)。所有的這些處理過(guò)程都可以在 Web Worker中進(jìn)行了，用戶可以不被阻塞的輸入詞匯和句子，Web Worker 在后臺(tái)校驗(yàn)詞匯是否正確以及提供備選詞匯。

總結(jié)

以上是生活随笔為你收集整理的多线程读取同一个文件_前端进阶：多线程Web Workers的工作原理及使用场景的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。