初探Webassembly

在開始聊Webassembly(下文簡稱爲wasm)以前，咱先了解一下爲何會出現wasm這個全新的web格式。這得從Javascript的誕生提及。

Javascript的誕生

在1994年的時候，網景公司成立，同年發佈了Navigator瀏覽器0.9版本，這個瀏覽器只能用來瀏覽，不能和用戶進行相關的交互。1995年，Brendan Eich進入網景公司，花了十天的時間研究出了Mocha，以後改名爲LiveScript，最後由於網景公司想趁Java的熱度才改名成Javascript。

Brendan Eich主要研究的方向是函數式編程，網景公司但願研究將Scheme語言做爲網頁腳本語言的可能性。Brendan Eich也認同這種想法。網景公司但願網頁腳本語言要與Java足夠類似，而且要比Java簡單，要讓非專業的開發者也能上手，然而，Brendan Eich對Java談不上一點喜歡，因此他花了10天就設計出了JavaScript。

Javascript的弊端和改進之路

因爲JavaScript最初只是爲了簡單的在瀏覽器上進行簡單的交互，因此Brendan Eich並無考慮JavaScript在一些複雜場景中的狀況，隨着互聯網的發展，js已經變成了在Web領域最普遍使用的編程語言，所以JavaScript也留下來不少缺陷，例如沒有類型，異常(後來加上去了)和對象模型等等的坑，其中最大的坑當屬JavaScript性能了。

JavaScript是解釋型語言，而且是單線程的，因此效率比較低，執行速度很慢，而此時Web應用愈來愈複雜，好比在一些實時性較高的應用場景中(好比商品秒殺)，JavaScript顯得有心無力，因而，聰明的工程師們確定不會置這個問題於不顧，2009年，google在chrome中引入了JIT(即時編譯)技術，有了這個技術，JavaScript執行效率瞬間提高了20-40倍，隨之而來催生了一批大型Web應用，隨着互聯網的進一步發展，JIT性能提高並不能知足日益複雜的Web應用。而且JIT身也有不足之處，例如，第一，JIT是在運行期編譯，若是同一變量的數據類型變了，那麼JIT就得推到歷來，第二，JIT並不會去優化代碼，很粗暴的方式去轉譯代碼就完事了。第三，JIT在一些狀況下沒法生成代碼，例如異常，for in等等.總之，JIT帶來的性能提高實在有限，可能仍是由於自己JavaScript的編譯速度實在太慢了吧。聰明的工程師們不會輕易被這樣的問題給難倒，他們不斷的去探索和改進JavaScript帶來的性能問題。因而，新的解決方案隨之而來，其中，微軟的Typescript和Mozilla的asm.js是其中的具備表明行的解決方案。

Ts方案是JavaScript的一個超集，主要是把強類型的Ts經過插件轉譯成JavaScript，可是本質就是讓JIT變得快一些而已。asm.js是JavaScript的一個子集，加上變量類型儘量的提高JIT的性能。Mozilla Firefox是第一個實現針對asm.js優化的瀏覽器，從Firefox 22開始使用。Asm.js相較於普通的js取得了極大的性能提高，但asm.js自己也存在一些問題，還不是一個比較理想的解決方案。由於asm.js和JavaScript同樣，都是文本格式，對於複雜的項目而言，解析asm.js的時間也會很是長，和二進制格式根本不可同日而語。同時，由於asm.js對Math函數進行拓展和改寫以及自身的相關實現也遭遇了不少的問題，爲了解決這些問題，新的技術方案wasm應應勢而生。

什麼是Webassembly

WebAssembly是Web瀏覽器的新擴展，從官網的介紹就能知道wasm是一種無版本、安全的、高效的二進制格式，他能夠被調用進入上下文，也能夠調用瀏覽器的功能，並且不只是能夠運行在瀏覽器上，非Web環境也能夠運行。

wasm 模塊老是與 JavaScript「膠水」代碼一塊兒使用，在必要的時候能夠執行一些有用的操做。WebAssembly 能夠看作是對JavaScript的增強，彌補 JavaScript 在執行效率上的缺陷。

WebAssembly是 C、C++、Rust、Go、Java、等語言的編譯目標，通過編譯器編譯以後的二進制代碼，無需通過Parser和 ByteCode Compiler這兩步，比asm.js更快。WebAssembly強制使用靜態類型，在語法上徹底脫離 JavaScript，同時具備沙盒化的執行環境，安全性更好。

Webassembly與Javascript性能對比

咱們經過斐波拉契數列求和分別在wasm和Javascript中的執行速度來對比二者之間的執行效率。

咱們經過AssemblyScript來編寫wasm程序,AssemblyScript是一個相似於Typescript的語言，AssemblyScript環境的安裝可參考官網的文檔按步驟安裝便可（AssemblyScript傳送門。）咱們使用AssemblyScript來編寫一個斐波拉契數列求和的函數，代碼以下：

export function fib(n: i32): i32 {
  if (n === 0 || n === 1 ) {
    return n;
  }
  return fib(n - 1) + fib(n - 2);
}
複製代碼

通過asbuild的構建命令便可生成出普通版本和優化版本的.wasm二進制文件，還有一個.wasm.map源碼文件映射，生成的代碼文件以下圖所示：

Javascript斐波拉契數列求和的代碼以下：

function jsFib(n){
     if (n === 0 || n === 1 ) {
         return n;
     }
     return jsFib(n - 1) + jsFib(n - 2);
}
複製代碼

因爲30如下的斐波拉契數計算的時間很小，因此咱們取了30，35，40以及45的斐波拉契數在chrome、firefox和opera三個主流瀏覽器中進行計算，Javascript和wasm下的斐波拉契數在不一樣的瀏覽器中計算所花時長以下表所示(單位：ms)：

從上面的數據能夠看出在不一樣的瀏覽器裏面雖然wasm和js對於相同的斐波拉契數執行時間都存在時間上的差別，可是wasm的執行效率是比js高的不少的。

Webassembly能替代Js嗎

最後，既然wasm執行效率這麼快，那他會徹底替代Javascript嗎？雖然 JavaScript 跟 C、C++等靜態語言相比執行速度還有很大差距，可是大多數 Web 應用的性能瓶頸已經不是 JavaScript 語言自己了，反而是網絡資源的加載，這一點 WebAssembly 並沒有優點。

並且，當要開發一個新的功能時，不管你是選擇用 C、C++、Rust、Go、Java 仍是 AssemblyScript，開發成本都要比JavaScript高。遇到瀏覽器不支持，都得降級爲用JavaScript實現，這無疑增長了業務複雜性。wasm適合一些複雜運算場景，例如Google Earth和Auto CAD等Web端的應用已經由wasm實現，因此，至少目前來看，wasm不會徹底替代Javascript。