Web Assembly背景

Javascript ，也叫Ecma script,  是這傢伙用了 10 天時間趕出來的。。

 

因此，各位程序猿們，若是你以爲老闆 10 天要大家上線一個 App 是一個喪心病狂的事情，那麼能夠多想一想這位哥。
Youtube 上有位哥的採訪，你能夠聽聽大神當年的故事。
https://www.youtube.com/watch?v=IPxQ9kEaF8c

 

 

固然，碼農和大神的區別在於：遇到這種事情，10 天之後碼農死掉了，而大神成功了。
只是但凡這種極速上線的事情，都會留下一堆的坑，大神和碼農的的區別，也就是水窪和天坑的區別。

這個是坑列表：

Javascript  從最開始設計，就是一種解釋型語言，由於大神以爲讓 Javascript 的目標用戶－ 「非專業編程人員和設計師」，瞭解什麼是編譯器是一件很殘忍的事情。

類型天然也是沒有的，由於學習類型就要學習 CPU 工做原理， 學習 CPU 工做原理就要學習組成原理， 大神以爲，讓 「非專業編程人和設計師」 去了解 1 和 1.0 一個是 CPU 上處理， 一個是 FPU 上面處理這種顯而易見的現象是一件很殘忍的事情。

對象模型是驚人的奇葩，那是由於不想設計得和 Java 同樣強大, Netscape 當初想法是主要工做都是 Java 來完成，只有輕量級的簡單操做留給 Java script, 作爲一種膠水語言( glue langurage).  如今知道爲何叫 Java script了吧？ 一個是Java, 一個是和Java 配合的 Script (腳本）。 以前還叫過Live script, 由於腳本和 Java 互動的技術叫 Live connect.

對於泛型， 缺省參數，操做符重載， 異常 等等這些黑科技， 大神的回答統統是：

 

 

 

好吧，異常後來加上去了。

 

若是故事到此爲止，其實不算一個悲傷故事，大神 10 天時間完成預約目的，東西也發佈了，市場反應也不錯。

可是問題是，市場反應實在是太好了，好得 Javascript 一路竄紅，紅得各大瀏覽器廠商紛紛支持， 成爲瀏覽器裏面事實上的官方語言。 在這個過程當中， 還順手幹掉了 VB script,

因而這個當初爲 「非專業編程人員和設計師」 的解釋型語言如今竟然變成互聯網上面最重要的語言之一，被用來作各類以前想也不敢想的東西，甚至還有人不顧死活的拿他來作WebOS.

因而這個時候，以前全部的小水窪都變成了天坑。以後很長段時間 JS 領域的發展史，均可以說是填坑史。

其中最大的一個坑，就是性能。

性能填坑階段一
Javascript 一開始就是解釋性語言，解釋性語言的一大特色就是慢， 而網頁應用愈來愈複雜，若是點個按鈕要等幾秒鐘，那淘寶的秒殺就要變成10秒殺了。這個固然不能忍。 因而聰明的人類想到一個辦法，雖然你是解釋型語言，可是我能夠偷偷的編譯你啊。 這個也不須要讓這幫 「非專業編程人員和設計師」 們知道， 我只要在程序運行前的一剎那，編譯即將運行的代碼就好。你看我機不機智。

因而 Google 在 2009 年在 V8 中引入了 JIT 技術 (Just in time compiling 江湖人稱即時編譯)。 有了這個buff, Javascript 瞬間提高了 20 － 40 倍的速度。直接致使一大波大型網頁應用的出現。今後 Javascript 一騎絕塵， 飛黃騰。。呃， 好像哪裏不對嘛？

人類的性能的指望是無窮無盡的，JIT 的帶來的性能提高很快就榨乾了。實際上 JIT 有如下問題：

JIT 基於運行期分析編譯，而 Javascript 是一個沒有類型的語言，因而， 大部分時間，JIT 編譯器實際上是在猜想 Javascript 中的類型，舉個例子：

function add(a, b) {return a+b}
Var c = add(1, 2)
JIT 看到這裏， 以爲好開心， 立刻把 add 編譯成 

function add(int a, int b) {return a+b} //a,b 被確認爲int 類型
但是你隨後又幹了這樣一個事情 

var d = add(「hello」, 「world」)

JIT 編譯器的表情確定是

 

怎麼辦， 已經編譯成機器碼了啊。
   這種狀況下，JIT 編譯器只能推倒重來。JIT 帶來的性能提高，有時候尚未這個重編的開銷大。

 

 

有不少的狀況下面， JIT 編譯器都沒法生成代碼，好比異常， 好比 for in , 這個基本上是實現難度引發的，具體能夠參考： Optimization killers · petkaantonov/bluebird Wiki · GitHub

事實上，大部分時間 JIT 都不會生成優化代碼，有字節碼的，直接字節碼，沒有字節碼的，粗粗編譯下就結了，由於 JIT 本身也須要時間，除非是一個函數被使用過不少遍，不然不會被編譯成機器碼，由於編譯花的時間可能比直接跑字節碼還多。

 

因而，總體上 Javascript JIT 提升的性能到達的天花板仍是不高的，雖然是提升了 20 - 50倍，那只是由於以前解釋執行實在是太慢了。。

性能填坑階段二。
既然 JIT 遇到的問題是類型不肯定問題和有一些語言功能，好比異常，for in ， JIT 起來很麻煩， 我可不能夠搞個方法讓用戶不去用這些功能，同時讓他們把用的類型都標註出來啊。

按照這個思路， 催生了兩種實現路徑：

一種是 Typescript,  Dart, JSX 爲表明的，基本思想是， 我搞個其餘的語言，這個語言是強類型的，因此程序猿們須要指定類型，而後我把它編譯成 Javacript 不就好了嘛。強類型的語言編譯成弱類型還不容易，什麼，不知道怎麼編？ 把類型去掉就好了嘛。

另外一種是火狐的  Asm.js 爲表明的， 作一個 javascript 子集， 同時試圖利用標註的方法，加上變量類型， 若是以爲好難理解，這就是個典型的例子：

 

 

加上一堆沒有什麼卵用提示 x 實際上是個 int， 而後有一個可以識別這些符號的JS引擎，你就能夠不用猜類型了哦， 事實上，因爲有了類型，連傳統的 AOT 都成爲了可能 (Ahead of time, 不懂的話，想象一下，就是和 C/C++ 那種編譯方式就行了）。

 

 

若是你沒有注意到，第二種的速度提高潛力比第一種要大很是多。由於第一種，不管如何，也是就是讓JIT (即時編譯) 快一點,  第二種那可直接就編譯了啊 (AOT).

這個是 Asm.js 相對於 JIT 和原生的性能對比

 

 

同時你們有沒後注意到，這個不是原生代碼哦， 性能堪比原生代碼， 安全性和傳統 Javascript 徹底同樣。 (尼瑪，你讓插件們怎麼活）。

 

 

Web Assembly 就是第二種方式，說到底，Mozilla, Google, Microsoft, and Apple 以爲 Asm.js 這個方法有前途，想標準化一下，你們都能用。

有了大佬們的支持，Web Assembly 比 asm.js 要激進不少。 Web Assembly 連標註 Js 這種事情都懶得作了，不是要 AOT 嗎？ 我直接給字節碼好很差？（後來改爲 AST 樹）。對於不支持 Web Assembly 的瀏覽器， 會有一段 Javascript 把 Web Assembly 從新翻譯爲 Javascript 運行， 這個技術叫 polyfill, HTML5 剛出來的時候很經常使用的一個技術。

使用 AST 的緣由是由於 AST 比字節碼更容易壓縮，也更容易翻譯。

不瞭解 AST 能夠看下面這張圖， 說明 Javascript 引擎的執行過程。 Javascript 先編譯爲 AST， 而後到 Bytecode.  AST 的抽象程度比 Bytecode 要高一級。

 

 

總結來講， Web Assembly 的工做方式以下：

 

 

好處是：

 

大幅度提升 Javascript 的性能，但願能把性能這個坑填完，同時也不損失安全性。Webapp 和 原生 App 的性能差距變得很小。

基本以前須要插件來提升速度這種技術已經沒有必要了， 網頁應用的移植性會變得更好。

 

文章二

 

提到了 WebAssembly，就必然首先說起對其有深遠影響的 asm.js，這是 Mozilla 在 2013 年推出的一項新技術，它是 JavaScript 的一個子集，捨棄了大量會致使性能問題的語法，而且被設計爲經過 C / C++ 代碼編譯生成，而非手工編寫 asm.js 代碼。上述的 sum 函數在 asm.js 中表現爲：

 

function sum(a,b){
   a = a | 0;
   b = b | 0;
   return ( a + b ) | 0;
}

 

上述代碼中，標準的 JavaScript 引擎會對其進行解析，並生成正確的結果，而 asm.js 會根據一些不會對運行時形成計算結果錯誤的特殊標識對變量的類型進行聲明（好比 a = a | 0 表示變量 a 是一個整數），經過這種方式，這種代碼既能夠在支持 asm.js 的JavaScript引擎上獲得很高的性能，也會在不支持的設備上繼續按照正確的邏輯進行執行，而非沒法運行。

雖然如此，asm.js 仍然存在着一些問題，主要是基於 JavaScript 語法的文本格式解析速度不夠快，而且代碼尺寸偏大，爲了解決這些問題，將 asm.js 進行二進制化的 WebAssembly 應運而生。

WebAssembly 是一種接近機器語言的跨平臺二進制格式。2017年3月份，四大主流瀏覽器廠商 Google Chrome、Apple Safari、Microsoft Edge 和 Mozilla FireFox 均宣佈已經於最新版本的瀏覽器中支持了 WebAssembly 的初始版本，這意味着 WebAssembly 技術已經實際落地、能夠在特定生產環境進行嘗試。

WebAssembly 目前能夠經過 Emscripten SDK 生成，下圖是 WebAssembly 的編譯原理

上圖展現瞭如何經過編寫 C / C++代碼生成 WebAssembly 內容。

首先經過 LLVM ，將 C/C++ 源代碼編譯爲 LLVM bytecode。這 是一種跨語言的底層虛擬機字節碼，理論上全部強類型編程語言都可以生成這種字節碼。經過這一點能夠得知，在將來理論上全部強類型編程語言（諸如 Java / C# 等）都可以開發 WebAssembly 程序。

其次，經過 EMScripten 中的後端編譯器，將這種抽象字節碼生成 asm.js 格式的文件。如上文所述，因爲 asm.js 仍然是 JavaScript，因此哪怕 JavaScript 引擎不支持該特性，也會以一般的方式運行這段邏輯。這意味着使用 C/C++編寫的源代碼，哪怕用戶設備不支持 WebAssembly，也能夠回退到 JavaScript 運行並獲得一致的結果。

接下來，asm.js 會經過另外一個編譯器生成爲 WebAssembly 的 .wasm 文件，因爲 WebAssembly 是二進制格式，相比 JavaScript 而言，其代碼體積同比小不少，而且因爲已是面向機器碼的格式，也無需在運行前對源代碼耗費時間進行 JIT 編譯操做。

經過上述內容能夠看出，WebAssembly 理論上能夠經過任何強類型語言生成，不強制依賴用戶的本地運行環境，代碼體積小、解析速度快，幾乎是 Web 開發將來的一顆「銀色子彈」。

惋惜的是在現階段，WebAssembly 仍然存在着很多問題須要去解決。

首先是自身的穩定性，以 Chrome 瀏覽器爲例，Chrome 57 支持 WebAssembly 的 MVP 版本，可是在 Chrome 58 上，大量的 WebAssembly 程序會直接致使進程崩潰，雖而後續的 Chrome 59 已經修復了絕大部分問題，可是仍然不得不對目前版本的穩定性持保留態度。

其次是可調試性，WebAssembly 被設計爲了一種開放的、可調試的程序，但目前不管是 Chrome 仍是 FireFox ，在調試方面還有很大的提高空間。因爲在目前階段調試較爲困難，因此用 WebAssembly 編寫業務邏輯代碼對研發來講仍是很不方便的。

還有就是與 Web 的互操做性。目前 WebAssembly 相似 WebWorker ，只能進行單純的數值計算工做，不能在C++層直接操做 DOM 節點。雖然在將來路線圖中說起這一特性會在後續加入，可是在目前階段 WebAssembly 更適合被用於更純粹的密集型數據計算工做，而非直接編寫業務邏輯。

綜上所述，在目前階段，WebAssembly 不適合直接編寫具體的業務邏輯，而更適合編寫應用程序中對性能要求比較高的庫，並與 JavaScript 編寫的業務邏輯進行通信，並在 JavaScript 端對 DOM 節點進行操做。

以筆者最近開發的白鷺引擎5.0的渲染庫爲例，白鷺引擎對外提供 JavaScript API，開發者編寫的 JavaScript 邏輯代碼會彙總爲一組命令隊列發送給 WebAssembly 層，而後 WebAssembly 負責全部的計算工做，最終生成一組基於 WebGL 格式的數據流，最後 JavaScript 對這組數據流進行簡單的解析並直接調用 DOM 的WebGL 接口傳遞數據。

在實踐過程當中，白鷺團隊總結出 WebAssembly 的幾個不容易注意的優點和缺點：

代碼體積很小，白鷺引擎團隊將大約300k左右（壓縮後）JavaScript 邏輯改用 WebAssembly 重寫後，體積僅有90k左右。雖然使用 WebAssembly 須要引入一個50k-100k的JavaScript類庫做爲基礎設施，可是整體來看資源尺寸的優點仍是很大的。

因爲代碼格式是二進制、沒法直接在瀏覽器中看到源碼，儘管理論上仍然能夠經過逆向工程必定程度上獲得原有的業務邏輯，可是因爲開發者能夠在編譯時使用了-O3 等激進的優化策略，因此最終反編譯獲得的業務邏輯也是很難閱讀的。雖然理論上一切在客戶端的內容都是不安全的，可是與全部代碼都直接暴露給用戶相比，代碼安全性獲得了很大的改善。

在運行 benchmark 等極限測試時，遊戲引擎使用 WebAssembly 並不比 JavaScript 有幾何量級的提高。筆者的推論是：因爲 JavaScript 引擎的JIT機制會把常常運行的函數進行極限的編譯優化，因此在 benchmark 這種代碼大量反覆執行的測試環境下，不管是 JavaScript 版本，仍是 WebAssembly 版本，運行的都是高度優化後的機器碼，雖然 WebAssembly 版本仍然比 JavaScript 版有必定的性能優點，可是並不明顯。

在運行業務邏輯代碼時，因爲大部分業務邏輯代碼只運行一次，因此 JavaScript 引擎只會對這部分代碼進行簡單的編譯優化而非極限優化，因此運行這一部分代碼 WebAssembly 相比 JavaScript 版本而言提高巨大，可是由於上文所述，不建議開發者在編寫業務邏輯時使用 WebAssembly，因此這裏陷入了一個兩難。在目前而言，理想狀況是除了底層庫以外，部分關鍵的涉及性能問題的邏輯也可使用 WebAssembly 進行編寫。

綜上所述，目前爲止因爲 WebAssembly 還不是很是完善，因此它目前的主要做用是做爲JavaScript 生態的有益補充，與JavaScript共存而不是取而代之。可是經過其路線圖咱們能夠得知，WebAssembly 的設計思想很是優秀，目前全部存在的問題從長遠的角度來講都是能夠解決的問題。在加上 WebAssembly 是很是罕見的由四大瀏覽器廠商共同宣佈會大力支持並實現的功能，其瀏覽器兼容性問題也終究能夠獲得解決，再退一步，哪怕舊式瀏覽器不支持，因爲 WebAssembly 支持回退到 JavaScript，也能夠保證正常運行。

在目前階段，WebAssembly 適合大量密集計算、而且無需頻繁與 JavaScript 及 DOM 進行數據通信的場景。好比遊戲渲染引擎、物理引擎、圖像音頻視頻處理編輯、加密算法等。

筆者認爲，WebAssembly 就像當初的 HTML5 標準同樣，在公佈以後最開始不被不少人看好，認爲會有瀏覽器兼容性問題、各大瀏覽器廠商的實現問題、性能問題、用戶需求與用戶體驗問題，但在近年來 HTML5 終於獲得了普遍的使用，甚至有些人認爲他能夠在不少場景下取代 NativeApp ，而非僅僅是當年「取代Flash」這一小目標。憑藉着底層技術的跨越式發展，以及瀏覽器廠商的一致支持，WebAssembly必定會有一個光明的將來，也許真的能夠成爲一顆 Web 開發的「銀色子彈」