What’s the WebWorkers？
2008 年 W3C 制定出第一個 HTML5 草案中提出了工作線程（Web Worker）的概念，並且規范出 Web Worker 的三大主要特征：能夠長時間運行（響應），理想的啟動性能以及理想的內存消耗。Web Worker 允許開發人員編寫能夠長時間運行而不被用戶所中斷的后台程序，去執行事務或者邏輯，並同時保證頁面對用戶的及時響應。
Web Workers類型有哪些？
- 專用線程（Dedicated Workers）
由主線程創建，並且只能和主線程通信。相當於每一次創建都是一個新的實例。 - 共享線程（Shared Workers）
在同一域名下，可以和任何進程通信（不同的Tabs，iFrames等）。可以理解為第一次創建就是在瀏覽器中停駐，類似一個MemoryCache，此后如果其他頁面需要創建該實例時，都會引用同一個Worker，成為跨進程的單例。 - 后台線程（Service Workers）
2014年推出的新規范，該API可以提供后台服務的能力，比如后台消息傳遞，代理偽裝，離線，消息推送等有意思的功能。本人測試Chrome下支持，但IE下日常（不支持）。
Web Workers可以干什么？
JavaScript是異步的單線程，通過時間片輪換模擬並發效果（可參考之前寫的《Web Workers實踐》）。隨着移動互聯網以及帶寬的提高，而HTML5提供了前端渲染的諸多好處（效果效率靈活輕量級），前端需要處理越來越多的數據，傳輸和解析也成為了一個很大的瓶頸。Workers+Promise絕對讓你爽歪歪。下面舉兩個很實際的場景，讓各位有一個清楚的認識。
應用場景1：后台計算能力
通過Worker將大量數據分析，統計的工作放到后台進行。比如為了減少文件大小，我們往往會做一次zip壓縮，好處很明顯，既可以加密，有可以極大的提高網絡傳輸的速度。但在傳統的JS中，zip解壓縮的性能損失是巨大的。隨着技術的發展，魚和熊掌也是可以兼得的。通過Workers技術，我們把數據的解壓縮和解析的工作交給子線程來處理，減輕主線程的負擔。如下，現在我們可以將Update放到Workers線程，主線程專注Render以及和用戶的交互。
應用場景2：共享線程代理多用戶
通過共享Worker，可以在多個進程中共用一個線程，接收從不同連接發送過來的指令，然后實現自己的指令處理邏輯，指令處理完成后將結果返回到各個不同的連接用戶。有了這種代理技術，可以衍生出很多有意思的功能，在代理中對參數安全性進行審核，對並發數統計，用戶自定義的JS函數的權限管理等，都可以通過子線程加一層殼來進行過濾。
性能至上
任何的技術都是有消耗的，關鍵在於技術人員針對自身情況，做出一個合理選擇，這取決於經驗和對各種因素全面的衡量。下面給出一些關鍵時間消耗，供各位選擇。
- Workers的創建一般都在1ms內，可以忽略不計
- PostMessage時間
不同瀏覽器差異較大，Chrome下80ms左右，而IE只有25ms
理論講，如果Worker創建后調用PostMessage，此時PostMessage事件會放在請求隊列，而此后的PostMessage則會直接在WebCore中響應，也就是首次事件可能時間要略久，但測試發現這種差異不並不存在或不明顯。 - OnMessage
各個瀏覽器中時間消耗很小，忽略不計。 - Transferring
默認的參數都是Copy形式，如果參數對象很大，而且在線程中並不修改該對象值，則可以使用Transferring，則參數為引用形式。否則參數拷貝會消耗大量時間。 - 創建多個Workers后的性能
未測試具體時間，但在真實應用中體驗很不錯
缺點
Workers下不支持DOM對象，不支持Mutex，並不是一種徹底的多線程方案。個人認為Workers主要是把數據部分的工作放到線程，提供后台計算能力，讓主線程和子線程更好的專注自己的工作，提高每個線程的性能。
Service Workers需要HTTPS才能使用，localhost除外，這太不實用。導致這一有意思的功能只能玩玩而已。