Cesium原理篇：4Web Workers剖析(2)

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除外，這太不實用。致使這一有意思的功能只能玩玩而已。