2015年我們宣布計劃將Unity WebGL構建目標的導出文件改為WebAssembly，即Wasm?，F在Unity 2018.2已經支持這項改動。本篇文章我們將介紹它是如何實現，以及對使用Unity制作交互式Web內容的開發者的意義所在。

Wasm的發展

我們在Unity 5.6中曾對WebAssembly支持作為實驗性功能發布，WebAssembly剛開始就得到四大主流桌面端瀏覽器的支持。從此時起，Unity和瀏覽器就開始加入不少相關的改進內容和錯誤修復。

從此WebAssembly的用戶使用量也在增長，我們得到了許多積極的反饋。所以下一步計劃是正式支持它：Unity 2018.1標志著對WebAssembly支持的實驗階段結束，同時我們也實現了制作Wasm-only版本的可能。

在Unity 2018.2，Wasm最終取代了asm.js，成為了默認鏈接目標（Linker Target）。這意味著，當開發者發布Unity WebGL構建目標時，Unity 2018 LTS將默認使用Wasm。

這是一個非常重要的里程碑，我們一直在為實現這個目標而努力。我們的要求是：確保Unity的實現和瀏覽器支持是穩定的，并且需要覆蓋Wasm的內部測試，這其中包括升級Emscripten和修復代碼中的一些問題。

如今我們擁有了所有測試套件的Wasm變體，任何將要合并到程序主線的改動都會針對WebAssembly進行測試。

請注意：我們仍然維護和運行asm.js套件，但現在所有要合并到主線的改動都是針對Wasm進行測試。

WebAssembly與asm.js

下面詳細介紹一下WebAssembly，并探討與asm.js之間的區別。

Wasm比asm.js速度更快、容量更小且內存使用率更高，這些都是Unity WebGL導出的痛點。Wasm也許不能解決所有的問題，但它能改善所有領域的平臺。需要注意，性能可能會因瀏覽器實現而異。但所有瀏覽器廠商都將致力于支持和改進WebAssembly。

打開Wasm文件時，你會立即注意到它是一個二進制文件，而asm.js是個文本文件。這種發布代碼的方法比較緊湊，但是也造成開發者無法在調試的時候而閱讀或修改代碼。

Wasm有自己的指令集，而asm.js則是“高度可優化”的Javascript子集。在開發構建中，WebAssembly給算術運算加入了更為精確的錯誤檢測功能，它能在特定情況拋出異常，例如：除以零、將大浮點數舍為整數等。在非開發版本中，這類算術錯誤的檢測將被屏蔽，所以不會影響用戶體驗。

1、代碼大小

為了生成WebAssembly，我們有一套基于IL2CPP、emscripten和binaryen復雜的工具鏈，它會將C/C++和C#代碼轉換為WebAssembly。這會產生二進制文件<build name>.wasm.code.Unityweb，從而實現比asm.js更小的版本。

此外，WebAssembly開發版本的代碼大小要比asm.js小數十MB，而非開發版本的大小會小幾百KB。為了讓你了解衡量基線，WebAssembly空項目的代碼大小約比asm.js的小12%，如果包含3D物理則會小18%。

請注意：上圖的測試結果在測量時不包含任何非必要資源包，也不包含內置著色器，使用Brotli作為壓縮格式。對于任意改進內容，例如：性能、內存、載入時間，得到的改進效果會根據項目而異。

2、內存

限定Unity堆的大小是asm.js的限制之一，即Unity堆的大小必須在構建時指定，后面無法進行更改。WebAssembly能讓Unity堆的大小在運行時增長，從而使Unity內容的內存使用超過啟動時指定的初始堆大小。

這意味著開發者可以讓內容從例如32MB這樣的小型堆開始，并讓它根據需要增長，這在之前是無法實現的。

將Memory Size值視為內容一開始的初始大小，這是Unity 2018.2中的功能，所以可以立即使用此功能。但是如果構建目標是asm.js，則無法使用此方法，因為無法調整堆的大小。

如果堆增長得過多，瀏覽器可能會耗盡內存，是否過多取決于瀏覽器。為了使各瀏覽器獲得一致的行為，請設置Unity堆的最大值。你可以通過在編輯器腳本中設置emscripten參數 “-s WASM_MEM_MAX=<value>” 來實現。

例如：PlayerSettings.WebGL.emscriptenArgs = "-s WASM_MEM_MAX=512MB";

請注意：內存最大值為2032，任何大于此數值都將導致瀏覽器中的運行時錯誤。

Wasm在載入時能更高效地使用內存。因此它能減少用戶在使用asm.js時遇到的內存不足問題，尤其是在32位瀏覽器上。更多關于Unity WebGL中的內存處理方式，請閱讀：Unity WebGL內存詳解。

3、性能

Wasm和asm.js之間的性能差異取決于瀏覽器。Wasm作為二進制文件擁有比解析為JavaScript文本文件的asm.js更快的載入速度。已經被編譯的Wasm代碼模塊會存儲在IndexedDB緩存中，從而在重載相同內容時實現快速的啟動過程。為了利用Wasm緩存功能，只要確保啟用Data Caching選項即可。

啟動后，在針對asm.js代碼樣式優化其JavaScript引擎的瀏覽器中，Assembly的執行速度將和asm.js旗鼓相當。如果在之前無法識別asm.js的瀏覽器上運行Wasm，那么Wasm的速度明顯會更快。

根據代碼的不同，一些指令在Wasm的速度會更快，例如：64位整數算術，它在asm.js沒有相應的特定指令。

4、多線程

WebAssembly多線程支持或許是最受期待的功能，也是最能提高性能的功能。該功能本來應該于今年早些時候在瀏覽器中推出，但是由于Spectre和Meltdown的安全問題，必須禁用SharedArrayBuffer支持，而這是實現該功能的重要組成部分。

好消息是，在最近多個瀏覽器加入了很多安全措施，以便重新啟用SharedArrayBuffer，我們也已經看到多個跡象表明這些瀏覽器將要在即將推出的版本中發布該功能。

在Unity方面，我們打算為該功能的發布做好準備，所以我們正積極地開發Wasm多線程支持，它將在接下來數月作為實驗功能發布，該支持僅限于本地內部線程，例如：目前沒有C#線程。這里的內部指的是用于蒙皮，動畫，剔除，AI尋路和其它子系統的作業線程。一開始它們可能不會被全部啟用，但我們的長期目標是盡可能利用多線程功能。

調試

調試對asm.js來說一直是個挑戰。但是WebAssembly中的調試還沒有變得更好。雖然瀏覽器開始在開發套件中提供WebAssembly調試，但是這些調試工具尚未很好地擴展到Unity3D的內容大小。

Wasm的設計初衷是“開放和可調試”，所以可以期待瀏覽器在未來將提供實現該目標的更好的工具。與此同時，開發者可以使用其它調試方法：

通常Unity WebGL版本中的問題出現在已構建游戲與瀏覽器API交互層中。該交互層位于UnityLoader.js和<build name>.asm/wasm.framework.Unityweb中，它包含易于讀取的JavaScript代碼，便于通過瀏覽器內置開發工具進行調試。

對于調試C#代碼，Debug.Log()通常是唯一選項，因此建議盡可能在其它平臺上進行調試。

對于高級調試功能，請嘗試導出為asm.js，從而能夠使用console.log().來注釋所生成的asm.js內容。

值得一提的是，Unity 2018.2中加入了IL2CPP的托管代碼調試支持，在實現WebAssembly多線程支持后，我們會立即開始做調試實驗。

未來展望

各瀏覽器廠商會致力繼續改進WebAssembly支持，他們一直在開發新功能和優化內容，用于改進啟動時間和性能。

例如：

?異步Wasm實例化功能（在Unity中得到支持）

?Wasm結構化克隆功能，允許編譯后的Wasm在瀏覽器中緩存（在Unity中得到支持）

?基線和分層編譯，以加速實例化過程（在運行Unity內容時會自動支持）

?流式實例化功能，能夠實現在下載時編譯Wasm代碼（正考慮是否在Unity加入支持）

?多線程功能（正在開發該功能在Unity中的支持）

?上述的一些功能已經實現，具體取決于瀏覽器。

我們堅信WebAssembly的未來，也鼓勵開發人員默認使用它來進行開發。如有需要，可以將asm.js保留為舊版瀏覽器的運行時回退。該功能可以通過在WebGL Player Settings中選取WebGLLinkerTarget.Both實現。

我們計劃在Unity 2018.3中棄用asm.js。這意味著在將來，asm.js將不會獲得任何針對Wasm的改進內容，例如：多線程功能、SIMD等。但asm.js還會在Unity 2018 LTS發布后的二年時間里面得到支持。