給網路提速，讓在線程序像在電腦本地一樣快速運行
在WebAssembly的幫助下
在線應用程序能像電腦本地應用程序
一樣快速流暢地運行。
━━━━━━
如果能分享一個計算機輔助設計（CAD）模型，還能讓一位同事對它進行遠程操作，你會怎麼做？「點擊這個鏈接查看我的設計，請隨意增刪或修改。」你也許會這麼說。你不用遠程指導同事安裝特殊軟體，也不用擔心對方的操作系統能否運行。想像一下，你所有的程序和數據都存儲在雲端，甚至像多媒體編輯這樣的計算密集型應用程序在瀏覽器中也可以像安裝在本地那樣自如運行。
萬維網問世早期，很多心懷熱忱的聰明人就希望它能成為一種可運行所有程序的工具。這一夢想之所以如此誘人，是因為網路不同於其他軟體平台。它由開放標準定義，任何人都可以在互聯網上進行創建。它不屬於任何公司，所以開發者只需對用戶負責。它主要圍繞著開源技術構建，因此有民主化的潛力。
在過去30年間，整整一代的開發者們都在努力使這個願景變成現實。我們為互聯網增加了新的功能，比如音頻和視頻流、2D和3D圖形、排版、點對點通信、數據存儲、離線瀏覽以及多點觸控、定位和攝像頭輸入。但我們依然在不懈努力，這樣才能提升性能，尤其是讓網路應用程序能像非網路應用程序那樣快速運行。
幾年前，我在摩斯拉（Mozilla）工作的團隊選擇專攻存在時間最久、也是最難攻克的難題之一：JavaScript編程語言的性能問題。JavaScript是現代網頁的三大支柱之一，它使用超文本標記語言（HTML）來描述它們的布局，用級聯樣式表（CSS）來指定它們的組件樣式，並用JavaScript代碼來提供各種豐富的交互體驗。
我們用兩種方法攻克這一難題。首先我和同事們要能夠在瀏覽器中運行巨大而複雜的程序，就像直接安裝在電腦上一樣。然後我們跟其他瀏覽器公司合作，創建了一個名為WebAssembly的互聯網新標準，設計出如今已正式成為網路一部分的安全、高效的代碼。
在我們著手研究之前，互聯網開發人員有兩個選擇。他們可以使用現有的互聯網技術（HTML、CSS和JavaScript）來創建在現有網路瀏覽器上運行的應用程序；他們也可以創建一個瀏覽器插件，但用戶必須下載並安裝這個插件。這兩種方法都不太理想。
第一種方法較為便捷、簡單，對用戶來說也比較安全。但計算量較大的應用程序會由此造成糟糕的用戶體驗：畫面卡頓，音質下降，應用程序要用數秒或更長時間來響應用戶輸入。插件的方法雖能讓瀏覽器順利且快速地運行程序（甚至是對性能要求很高的電腦視頻遊戲），但用戶必須下載和安裝軟體，這很有可能將惡意代碼注入到用戶的系統中。此外，瀏覽器插件只能在其為之開發的特定瀏覽器上運行。所以如果你用的是另一種瀏覽器，那就沒轍了。
WebAssembly現在提供了一種全新的選擇。它利用了互聯網技術的已有優勢——JavaScript，也就是能在瀏覽器中運行JavaScript代碼並建立瀏覽器安全屬性的引擎，並進行各種優化，使代碼的讀取和執行更加迅速。
這種方法讓WebAssembly更易獲得瀏覽器公司的支持，因為這對它們來說也意味著更少的工作量和較小的風險。如今，摩斯拉火狐、谷歌Chrome、蘋果Safari和微軟Edge瀏覽器的最新版本都支持WebAssembly。因此，互聯網有望從此變得更加強大。下面來講這種改變是如何發生的。
━━━━━━
同許多技術創新的故事一樣，這次創新也是從電子遊戲開始的。團隊負責人馬丁?貝斯特（Martin Best）為摩斯拉做出的最好設想是：如果我們能讓遊戲在網路中順暢運行，那麼其他的計算密集型應用程序也會很快緊隨其後。
遊戲程序開發伊始，摩斯拉的很多工程師自然而然地將工作重點放在了JavaScript的性能上面。這是一個緊張而興奮的時刻，大家用上了最前沿的學術研究成果和一系列行業優化技術。有了這些，我們的團隊就能加速運行JavaScript，提供接近本地化的軟體體驗，這是一條黃金準則。
問題是這些性能改善的表現並不穩定。有時代碼運行速度真的很快，有時卻不然。JavaScript的設計讓人很難確定速度會在何時何地降低，更加不可能預測了。
我在摩斯拉的同事阿隆?扎凱（AlonZakai）產生了一個古怪的想法，可以解決這樣的問題：把一個他用C++語言編寫的遊戲，轉換為JavaScript代碼，從而讓遊戲在網上運行。當時是2010年，在那時，把C++轉換成JavaScript是不可想像的。
用C++編寫的遊戲可以是有著數百萬行代碼的大型程序，這在當時對JavaScript來說實在太複雜了。更糟糕的是，這種遊戲會給底層平台施壓，因為它們有數個不同部分——音頻、視頻、物理組件、人工智慧——需要協調運行。對於任何人來說，如何能將這一切計算密集型功能從快速強大如C++的編程語言跳轉到JavaScript（最初用於查看輕型超文本文檔的Web語言）上，都是一個不解之謎。
當時，甚至連扎凱自己都認為這是個奇怪的想法。但他不想用JavaScript逐行重寫他的遊戲，他好奇的是：這到底能做成嗎？於是他開始著手改編一個可以將C++代碼自動轉換成JavaScript代碼的開源工具。他把這個項目叫做Emscripten，這個詞結合了JavaScript中的「script」和電視節目《辛普森一家》中的「embiggen」（意指增強、變大，片中人物斯普林菲爾德的座右銘是：高貴的心靈使矮小的人變得偉大）。
扎凱花了兩年時間研究Emscripten，起初把它僅作為一個附帶項目，然後把它作為摩斯拉遊戲程序的一部分。團隊負責人貝斯特發現其他大型遊戲公司也遇到了跟扎凱一樣的煩惱：他們想讓大型遊戲繼續在網上運行，但不想花錢花時間用JavaScript進行重寫。
因此扎凱繼續開發Emscripten直至完成。當他第一次展示C++遊戲如何在瀏覽器中運行時，房間里的所有人都震驚了。它出現在屏幕上，所有的元素都包含在內：圖形、音頻、不斷變化的三維視角、多個角色的交互以及各種武器的選擇。即使有人之前存有疑慮，也被他的演示打消了，幾秒鐘之內，其他組員就上網點擊進入了遊戲，並在驚喜中開始相互射擊。
更令人驚訝的是，這個JavaScript代碼的運行速度比手寫JavaScript快得多。你一定以為，自動從一種語言翻譯到另一種語言的代碼會混亂不堪、運行緩慢，比不上經驗豐富的程序員編寫的代碼，因為程序員可以對代碼進行分析和優化。但是事實情況並非如此。
到底是怎麼回事？要想理解答案，你需要知道編寫C++代碼需要程序員創建具有明確特徵的對象。相較之下，JavaScript兼容性更強，而且非常靈活。事實證明，在翻譯的過程中，Emscripten保留了C++的嚴格性，允許生成的JavaScript更有效地運行。這是一個里程碑式的成果。
━━━━━━
當Emscripten已基本上可投入工作後，貝斯特想看看它能為商業軟體做些什麼。它能否將複雜的大型遊戲進行轉換，讓它在互聯網上運行？頗受歡迎的遊戲引擎Unity的開發人員們，邀請我們一起加入一次實驗性衝刺，看看我們能做到什麼程度。
讓大家吃驚的是，我們的聯合團隊在一周內就讓Unity的遊戲引擎上線了。但演示時載入時長達到半分鐘之久，並且運行得非常不順暢。我們很快找到了問題所在：瀏覽器引擎遇到了問題，因為它在運行時需要解析、分析和優化由Emscripten生成的JavaScript代碼。
從這裡開始我加入進來。我主要研究火狐瀏覽器中的JavaScript引擎性能。在研究這個問題的時候，我發現可以在Emscripten和運行Emscripten所生成代碼的引擎之間，制定各類協議：如果你只向引擎提供特定的輸入模式，那麼引擎就能夠可靠並相當快速地運行。
我將這一發現與貝斯特進行了分享，並建議扎凱修改Emscripten讓其只生成能快速運行的模式，同時，我在火狐瀏覽器中優化JavaScript引擎，提高代碼的運行快速。貝斯特幾乎和我一樣激動，「就這麼做！」他和布蘭登?艾克（Brendan Eich）這樣對我說。布蘭登?艾克是JavaScript的創始人，後來成為摩斯拉的首席技術官，伴隨著他們的鼓勵，我踏上了這一段新的征程。
在摩斯拉研究主管戴夫?赫爾曼（DaveHerman）的幫助下，我和扎凱一起工作，將所允許的JavaScript模式具體化，使Emscripten和瀏覽器之間的協議完全清晰化。我們把JavaScript的子集命名為asm.js，它本身就成為了一種獨特的語言（「asm」是Assembly的縮寫，是一種非常接近CPU機器語言的代碼類型，而「.js」則是JavaScript縮寫）。
新的asm.js運行速度更快，因為JavaScript是一種動態類型的語言。這意味著在程序運行之前，由變數表示的數據不一定是已知的，這使計算機難以提前優化將要執行的代碼。
為了讓JavaScript更快，我們需要為這種語言創建一個靜態類型的系統，這意味著代碼必須提前聲明它所執行操作的數據類型。這個變數是一個數字、一串字元還是一個更為複雜的對象？靜態系統要求程序員進行一些前期工作來解決這一問題。
經過幾個月的編程之後，我在火狐瀏覽器中對asm.js進行了優化，我們已準備好對它進行測試。這次是在另一個同樣強大的遊戲平台——Epic的Unreal引擎上。在火狐瀏覽器中運行數百萬行的整個代碼庫只花了幾天的時間——涉及的工作包括音頻和圖像處理等，這些都是在與計算機本地操作系統完全不同的瀏覽器中完成的。
我們的成績比預想的要好。動畫從一開始就很流暢。我們觀看的時候，周圍都是歡呼和慶祝的聲音，就好像拼了幾年的拼圖終於完成了最後一塊。
Epic的首席執行官蒂姆?斯維尼（TimSweeney）評論說，他知道在瀏覽器上運行這樣的遊戲是可能的，但他沒想到會這麼快。幾周之後，我們在2013年的遊戲開發者大會上展示了一些使用Unreal引擎的遊戲，這是第一個在沒有插件幫助的情況下能在瀏覽器中運行大型遊戲的引擎。
但是我們不希望asm.js或其使用的優化只限於火狐瀏覽器用戶。所以我們發布了asm.js的完整規範，並積極鼓勵其他瀏覽器提供商增加我們正在使用的相同優化。從2013年到2015年，四大主要瀏覽器引擎都通過運行asm.js提高了性能，微軟 Edge瀏覽器更是加入了部分火狐瀏覽器的開源asm.js優化代碼。
不久後，由Emscripten轉譯成asm.js的遊戲開始在網上出現了。比如在臉譜網上廣受歡迎的遊戲《帕帕彈珠傳奇》《足球經理》《雲端入侵者》和《糖果傳奇》等，用的都是asm.js。而且正如預期的那樣，一旦這些遊戲的出現證明了其可行性，其他的各種應用就會接踵而至。
例如，臉譜網如今在上傳用戶圖片之前，用asm.js在瀏覽器中對其進行壓縮以節省帶寬。Adobe公司把它用C++編寫的核心圖像編輯庫轉換為asm.js，以適應網路版Lightroom的需要。維基百科使用asm.js來播放用戶瀏覽器不支持的視頻格式。其他網路應用還包括計算機視覺、三維製圖、用戶界面設計、語言檢測、音頻混合、數字信號處理、醫學成像、物理模擬、加密、壓縮和計算機代數。
━━━━━━
這些進展相當完美，但有一點最終變得更加清晰：要想更進一步，我們必須創建一種新的網路標準，具備比asm.js代碼更加高效的載入速度。尤其是，新標準將以更加緊湊的表示法替代已知的變數和指令名，這種表示法就是二進位數。新標準還可以幫助我們解決用戶在asm.js里發現的一些小問題——他們需要64位整數算術等功能，且需要能夠將應用程序分解成可以單獨下載和優化的更小的塊。由此，WebAssembly的想法誕生了。
在摩斯拉遊戲項目剛開始的時候，針對這種標準出現過很多不同提案，但沒有一個是完全正確的。你可能會想，即便再提出新提案也是無濟於事。但隨著asm.js的廣泛使用，我們得到了一個獨一無二的機會，抓住契機把它引入到了WebAssembly中。如果一些瀏覽器需要等一段時間來支持WebAssembly（「wasm」）代碼，那麼開發人員只需利用Emscripten，就能很容易地生成wasm和asm.js兩種代碼。這樣他們既可以一直使用處處皆可運行的asm.js，也可以把wasm代碼發送給只能運行它的相應瀏覽器。
下一步是讓其他瀏覽器提供商信服，WebAssembly是個好主意。在某些情況下這出奇地簡單，因為這些公司的工程師們已有類似的想法。而在其他情況下，則需飲酒長談、四處尋訪團隊、說服管理人員，或者是在遊戲開發者大會期間，舒服地坐在舊金山芳草地藝術中心的花園裡進行推廣。到了2015年，終於相關人士都加入了進來，準備正式著手創建這個新的互聯網標準。
這個過程始於萬維網聯盟（W3C）社區小組的成立，這個組織由來自四大瀏覽器公司和其他有興趣的工程師們組成。我們一致認為，想要一下子解決所有問題是不明智的，因為僅制定規範就需要5年甚至更長的時間。因此，從一開始，我們的小組制定的目標就是定義和裝載被新興企業的專家們稱為「最小化可行產品」（MVP）。此後我們可以再根據反饋對其反覆改進。
於是我們走到了今天。瀏覽器公司已經同意了WebAssembly的初始MVP版本，並且已經發布了兼容性實施版本。Emscripten 可以把用C++編寫的代碼直接轉換成WebAssembly。不久後也將能夠運行其他語言，包括Rust、Lua、Python、Java和C#。使用WebAssembly，幾百萬行的代碼庫目前可在幾秒鐘內載入完畢，並且運行速度可達本地程序速度的80%。隨著運行代碼的瀏覽器引擎變得更好，預計載入時間和運行速度都會進一步優化。
WebAssembly社區小組有個宏偉的計劃。我們正在努力增加可以利用多核CPU的並行處理能力的功能。並且我們希望能為多種編程語言提供一流的工具和優秀的性能，從而使開發人員在為本地平台編寫代碼時能擁有同樣的自由。
回想起以本地程序的速度在網路中運行各種應用程序的最初夢想，我和我的同事們可以預見到，還有很多工作要做。但是藉助WebAssembly，我們很高興已向這個目標邁進了一大步。
作者：Luke Wagner
>>>本文為原創，轉載請回復。
TAG:悅智網 |