Web Workers 提供了一種在瀏覽器單線程執(zhí)行外運(yùn)行 JS 代碼的方式。單線程處理了包括頁面內(nèi)容展示，通過鍵盤、鼠標(biāo)點(diǎn)擊和其他裝置的用戶交互，以及對于 AJAX 請求響應(yīng)的一些請求。

事件處理和 AJAX 請求是異步發(fā)生的，可以作為一種通用瀏覽器展示代碼路徑之外的運(yùn)行代碼的方式，但是它們?nèi)匀辉谶@一單線程內(nèi)運(yùn)行，并且必須很快完成。

否則，瀏覽器中的交互會失去作用。

Web Workers 允許在一個單獨(dú)的線程運(yùn)行 JS 代碼，完全獨(dú)立于瀏覽器線程及其常規(guī)活動。

近年來，關(guān)于 Web Workers 有什么用的問題有許多爭論。現(xiàn)如今 CPU 的速度非常快，幾乎每個人的個人電腦剛買來打開就擁有幾個 G 的內(nèi)存。類似地，移動設(shè)備也已經(jīng)達(dá)到了臺式機(jī)的處理器速度和內(nèi)存大小。

那些或許曾經(jīng)被認(rèn)為是“計(jì)算密集型”的應(yīng)用程序現(xiàn)在被認(rèn)為沒那么糟糕了。

所謂的 這不是一片空白 是什么意思？

但是很多次當(dāng)我們決定如何高效地執(zhí)行代碼時，在開發(fā)環(huán)境中測試，我們只考慮了一個應(yīng)用程序的執(zhí)行。在現(xiàn)實(shí)生活系統(tǒng)中，一個用戶的手中會同時執(zhí)行許多程序。

所以單獨(dú)運(yùn)行的應(yīng)用或許沒有必要使用 worker 線程，對于大范圍的用戶來說，或許才有必要使用 worker 線程提供最好的體驗(yàn)。

啟動一個新的 worker 就像是規(guī)定一個包含了 JS 代碼的文件一樣簡單：

new Worker(‘worker-script.js’)

一旦創(chuàng)建了 worker ，它便獨(dú)立于主瀏覽器線程單獨(dú)運(yùn)行，并執(zhí)行腳本中賦予它的任何代碼。只是瀏覽器看上去和存放專門腳本文件的 HTML 頁面是有關(guān)聯(lián)的。

數(shù)據(jù)是通過 JS 代碼中兩個互補(bǔ)的特性實(shí)現(xiàn)在 Workers 和主 Javascript 線程中的傳遞的：

發(fā)送端的 postMessage() 方法

接收端的 “message” 事件處理器

message 事件處理器像其他的處理器一樣，接收到一個事件參數(shù)，這個事件有一個 “data” 屬性，擁有從另一端傳來的數(shù)據(jù)。

這個可以成為一個雙向的溝通：在主線程那邊的代碼可以調(diào)用 postMessage() 方法發(fā)送信息到 worker ，然后 worker 可以使用環(huán)境中全局適用的 postMessage() 方法的某種實(shí)現(xiàn)將信息返回給主線程。

在 Web Worker 中的一個簡單流程將會是這樣的：在頁面的 HTML 中，一條信息發(fā)送到 worker ，然后該頁面等待一個響應(yīng)：

worker 代碼等待一條信息：

上面的代碼將會在控制臺打印輸出：

Message posted from webworker: Worker runningMessage posted from webworker: Worker received data: {“data”:”123456789'}

Worker 期望為長連接，而無須反復(fù)重啟

在 Worker 的生命周期里，瀏覽器與 Worker 會發(fā)送與接收多條消息。

Web Worker 的實(shí)現(xiàn)從以下兩方面確保了線程安全：

為 Worker 線程創(chuàng)建唯一，相互獨(dú)立的全局環(huán)境，而與瀏覽器的相隔離

主從線程調(diào)用 postMessage() 交換的數(shù)據(jù)通過拷貝進(jìn)行

每一個 Worker 線程的全局環(huán)境都是有別與瀏覽器頁面的 JavaScript 環(huán)境的，并且是唯一的。Worker 不能訪問瀏覽器中的 JavaScript 環(huán)境的任何數(shù)據(jù)，連 DOM、windows 對象、document 對象都不例外。

Worker 有屬于它們自己版本的東西，像將消息記錄到開發(fā)人員的控制臺的 ‘console’ 對象，以及發(fā)起 AJAX 請求的 XMLHttpRequest 對象。但除此之外，在 Worker 中運(yùn)行的 Javascript 代碼應(yīng)該是自包含的；來自于 Worker 線程的任何輸出，主窗口（main window）希望其都必須通過 postMessage() 函數(shù)作為數(shù)據(jù)返回。

此外，任何數(shù)據(jù)通過 postMessage() 在傳遞之前被復(fù)制（傳遞副本），因此在主窗口線程中修改數(shù)據(jù)并不會導(dǎo)致 Worker 線程中的數(shù)據(jù)變更。這為 main 線程和 Worker 線程之間傳遞的數(shù)據(jù)的沖突并發(fā)更改提供了固有的保護(hù)。

web workers 用例

典型的 web worker 例子就是任何 task 任務(wù)在執(zhí)行過程中可能會變得非常昂貴，要么消耗大量的 CPU 時間，要么花費(fèi)大量的時鐘時間（計(jì)算機(jī)調(diào)度的時鐘）來訪問數(shù)據(jù)。

一些可能會用到 web workers 的用例：

預(yù)取 和/或 緩存數(shù)據(jù)供后面使用

輪詢和處理來自web服務(wù)器的數(shù)據(jù)

處理和顯示大數(shù)據(jù)集（think genomics）

與游戲中的動作有關(guān)的計(jì)算

圖像處理和過濾

處理文本數(shù)據(jù)（代碼語法，拼寫檢查，字?jǐn)?shù)計(jì)算）

CPU 時間（片）是一個簡單的用例，但是對資源的網(wǎng)絡(luò)訪問也很重要。許多時候，網(wǎng)絡(luò)上的網(wǎng)絡(luò)通信可以以毫秒為單位執(zhí)行，但有時網(wǎng)絡(luò)資源變得不可用，直到網(wǎng)絡(luò)恢復(fù)或者請求超時（需要1-2分鐘才能清除）。

即使一些代碼在開發(fā)環(huán)境中被隔離測試時可能不會耗費(fèi)過長運(yùn)行時間，但當(dāng)多個事物可以同時運(yùn)行時，它可能會成為在用戶環(huán)境中運(yùn)行的問題。

下面的例子演示了 web workers 可用的兩個方法。

Demo：游戲碰撞檢測

（注意：這是一個很長的例子）

現(xiàn)在基于 HTML5 的游戲在網(wǎng)絡(luò)瀏覽器中隨處可見。游戲的一個中心方面是游戲環(huán)境中各個部分之間的計(jì)算運(yùn)動和交互。有些游戲的移動部分相對較少，而且很容易將其動畫化（ 超級馬里奧模擬器 ，還有嗎？）。但是讓我們考慮一個更復(fù)雜的例子。

例子涉及到大量的彩色球在矩形邊界上跳躍（反彈）。目標(biāo)就是讓這些球保持在游戲的邊緣，并且還可以探測球之間的碰撞并使它們彼此反彈。

邊界檢測相對簡單且執(zhí)行速度快，但是碰撞檢測在計(jì)算上的要求就更高了，因?yàn)樗笾掳辞虻臄?shù)量的平方數(shù)增長：有“n” 個球，每一個球都要和其它球進(jìn)行比較，看它們的路徑是否相交，是否需要被反彈（結(jié)果是 n * n，或者 n 的平方的比較）。

因此有 50 個球，需要進(jìn)行 2500 次檢查；有 100 個球，需要進(jìn)行 10000 次檢查（實(shí)際上它略少于這個數(shù)量的一半：如果你檢查球 n 對球 m，你不需要稍后檢查球 m 對球 n，但是，這里面仍然需要大量的計(jì)算）。

來自：https://www.oschina.net/translate/sing-webworkers-for-safe-concurrent-javascript