大家好，我是前端西瓜哥。

wasm 拿來做 Web 端的圖形編輯器貌似是不錯的選擇。

因為圖形處理會有相當多無法利用到 WebGL GPU 加速的 CPU 密集的計算。比如對一條復雜貝塞爾曲線進行三角化，對多個圖形進行復雜圖形的布爾運算。

圖形編輯器性能天花板 Figma 用了 wasm，我們也該用嗎？

Figma 的性能提升

說到 wasm 和圖形編輯器，經常有人提到 Figma 的加載速度提升為原來的三倍。來自 Figma 官方這篇文章：

《WebAssembly cut Figma's load time by 3x》

閱讀后我有了不少收獲。

Figma 從一開始就是用 C++ 寫的。在 wasm 被瀏覽器支持之前，Figma 使用 wasm 的前身 asm.js 去轉成 JavaScript，使其可以在瀏覽器上運行。

wasm 在 2017 年被瀏覽器實裝，Figma 自然而然用上了 wasm，沒有太多的改造成本。

彼時，Figma 發現在 Chrome 運行 wasm 有 BUG，會失敗。Firefox 則能正常運行。Edge 和 Safari 則要過幾個月才實裝。

所以這篇文章的對比數據 只是針對 Firefox 的，是 C++ 通過 asm.js 編譯成 js，以及編譯為 wasm 這兩者的性能對比，不是原生 js 和 wasm 的對比。

首先是加載速度提升為原來的 3 倍。加載指的是打開頁面，圖紙的繪制效果最后展示出來的這個過程。

一個很大的設計圖紙，原來加載需要 12s 左右，現在只需要 4s，不得不說這提升確實不錯，極大提高用戶的使用體驗，尤其是用戶經常要打開一些大圖紙的場景。

這里 wasm 速度提升的原因：

• wasm 的字節碼解析快，并直接編譯，而 JavaScript 需要 JIT 在運行的過程中去逐步判斷是否要對特定代碼進行編譯優化。
• CPU 復雜計算相當多，累加起來 wasm 就是比 js 快。
• 另外一個利好，就是 wasm 編譯出來的機器碼會被緩存下來，第二次加載直接不用編譯了。JavaScript 則要照常解析。

其實我更在意的是在 Chrome 的表現，它是占有率最高，其使用的 v8 引擎性能比 Firefox 的要好。但 asm.js 的優化更多針對的是 Firefox 的，在 v8 上不知道是否有效果。

然后對比了它們的體積變化，體積減少并不是很明顯。尤其是壓縮之后。

理論上 wasm 保存不是文本，是字節，數據會更緊湊，體積一般要少得多。

不過需要注意的是這里的也是 asm.js 編譯產出，并不是原生寫的 JS 邏輯。

我其實挺好奇 Figma 為什么選擇用 C++ 去開發？

我猜可能團隊成員更熟悉 C++，應該有不少來自圖像處理軟件公司的大佬。這些軟件用什么寫的？多半是 C++。選擇 C++ 是團隊的最好的選擇。

另外服務端也是要運行編輯器的渲染邏輯的（比如生成預覽圖），C++ 要比 nodejs 性能高得多，消耗更少的資源。Nodejs 甚至沒有 Canvas 環境，通常會生成 SVG 用一些第三方轉成圖片。

或者可能需要用到一些JavaScript 沒有的 C++ 圖形庫。我發現國內一些圖形編輯器廠商貌似挺喜歡用 Skia（Canvas 2D 的底層調用庫，開源）的，wasm 倒挺合適。

是否上 wasm？

做圖形編輯器，如果要做到性能優化到極致的，還是要看看頭部公司在做什么，業界的最新技術是什么。

為了極致的性能，還是很有必要用 wasm 的，當然這得一開始做產品的時候就用，像 Figma 一樣。招人的時候要求 C++。

如果已經用 JavaScript 了，然后想用 C++ 重構去轉 wasm 我感覺不太可能，這個投入產出比太低，團隊也沒這個基因，你還想基因突變不成。

如果只是將部分功能做成 wasm，我不好說，不知道會不會有通信上的問題，可能有點搞頭。

只是做個簡單的圖形編輯器，性能要求不高，能用就行，比如白板工具、表格，就沒必要用 wasm 了，甚至 WebGL 都可以不用，直接 Canvas 2D 走起。

最后需要強調的一點是，Figma 強大的原因在于 WebGL 的硬件加速，wasm 更多的是錦上添花的作用。你得好好確認你的圖形編輯器的瓶頸在哪里。