WebAssembly的起源及實踐分析

在瀏覽器之爭中，Chrome憑借Java的卓越性能取得了市場主導地位，然而由于Java的無類型特性，導致其運行時消耗大量的性能做為代價，這也是Java的瓶頸之一。WebAssembly旨在解決這一問題。本文從WebAssembly的起源到開發實踐對其做全面探究，幫助開發者對WebAssembly有全面的了解。
　　緣起
　　讓我們從瀏覽器大戰說起。微軟憑借Windows系統捆綁Internet Explorer的先天優勢擊潰Netscape后，進入了長達數年的靜默期。而Netscape則于1998年將Communicator開源，并由Mozilla基金會衍生出Firefox瀏覽器，在2004年發布了1.0版本。從此，第二次瀏覽器大戰拉開帷幕。這場大戰由Firefox瀏覽器領銜，Safari、Opera等瀏覽器也積極進取，Internet Explorer的主導地位首次受到挑戰。2008年Google推出Chrome瀏覽器，不但逐步侵蝕Firefox的市場，更是壓制了老邁的Internet Explorer。在此次大戰之后的2012年，StatCounter的數據指出Chrome以微弱優勢超越Internet Explorer成為世界上最流行的瀏覽器。
　　分析Google Chrome瀏覽器戰勝Internet Explorer的原因，除了對Web標準更友善的支持外，卓越的性能是其中相當重要的因素，而瀏覽器性能之爭的本質則體現在Java引擎。此前，Java引擎的實現方式經歷了遍歷語法樹到字節碼解釋器等較為原始的方式，將每條源代碼翻譯成相應的機器碼并執行，并不保存翻譯后的機器碼，使得解釋執行很慢。2008年9月，Google發布了V8 Java引擎。V8被設計用于提高Web瀏覽器中Java的執行性能，通過即時編譯JIT（Just-In-Time）技術，在執行時將Java代碼編譯成更為高效的機器代碼并保存，下次執行同一代碼段時無需再編譯，使得Java獲得了幾十倍的性能提升。
　　然而，Java是個無類型（untyped，變量沒有類型）的語言，這直接導致表達式c=a+b有多重含義：
　　a、b均為數字，則算術運算符+表示值相加；
　　a、b為字符串，則+運算符表示字符串連接；
　　……
　　表達式執行時，JIT編譯器需要檢查a和b的類型，確定操作行為。若a、b均為數字，JIT編譯器則將a、b確認為整型，而一旦某一變量變成字符串，JIT編譯器則不得不將之前編譯的機器碼推倒重來。由此可見，Java的無類型特性建立在消耗大量性能代價的基礎之上。即便JIT編譯器在對變量類型發生變化時已進行相應優化，但仍然有很多情況Java引擎未進行或無法優化，例如for-of、try-catch、try-finally、with語句以及復合let、const賦值的函數等。
　　由此可見，Java的無類型是Java引擎的性能瓶頸之一，改進方案有兩種：一是設計一門新的強類型語言并強制開發者進行類型指定；二是給現有的Java加上變量類型。
　　微軟開發的Type屬于第一種改進方案。它是擴展了Java特性的語言，包含了類型批注，編譯時類型檢查，類型推斷和擦除等功能，Type開發者在聲明變量時指定類型，使得Java引擎能夠更快將這種強類型的語言編譯成弱類型。
　　看看第二種方案：
　　
　　代碼1
　　代碼1表示帶有兩個參數（a和b）的Java函數，和通常Java代碼不同的地方在于a=a | 0及b=b | 0，以及返回值后面均利用標注進行了按位OR操作。這么做的優點是使Java引擎強制轉換變量的值為整型執行。通過標注加上變量類型，Java引擎就能更快地編譯。
　　既然增加變量類型能夠提升Web性能，有沒有辦法將靜態類型代碼例如C/C++等轉換成Java指令的子集呢？上面的這段代碼恰恰是作為Java子集的asm.js，由代碼2的C語言編譯而來：
　　
　　代碼2
　　事實上，早在1995年起就已經有Netscape Plugin API（NPAPI）在內的可以使用瀏覽器運行C/C++程序的項目在開發。而2013年問世的asm.js是目前較為廣泛的方案。asm.js是一種中間編程語言，允許用C/C++語言編寫的計算機軟件作為Web應用程序運行，并保持更好的性能，而Mozilla Firefox從版本22起成為第一個為asm.js特別優化的網頁瀏覽器。
　　Google也同樣在為原生代碼運行在Web端而努力。Google Native Client（NaCl）采用沙盒技術，讓Intel x86、ARM或MIPS子集的機器碼直接在沙盒上運行。它能夠在無需安裝插件的情況下從瀏覽器直接運行原生可執行代碼，使Web應用程序可以用接近于機器碼運作的速度來運行。而Google Portable Native Client（PNaCl）則稍有變化，通過一些前端編譯器將C/C++源代碼編譯成LLVM的中間字節碼而不是x86或ARM代碼，并且進行優化以及鏈接。