WebAssembly場景及未來

引言

從前面的文章中，我們已經了解了 WebAssembly（WASM）的基本知識，演進歷程，以及簡單的使用方法。通過全面了解了WebAssembly的設計初衷和優勢，我們接下來要知道在什么樣的場景中我們會使用 WASM 呢？在這些不同的場景下，我們是如何使用 WASM 的呢？

在這一章中?，我們將會討論一下 WASM 的在業界的使用場景

應用場景概覽

通過現有的認知，我們已經知道在web中wasm的高性能表現，使得其在越來越多的web應用開發中大展拳腳。隨著WebAssembly技術的發展，它的很多能力被開發完善，基于如下能力：

加速基于瀏覽器的應用運行速度，來在一定程度上替代 JavaScript。
將不同的編程語言編譯成 WASM 來提供它們之間的互操作的可能。
安全的應用沙盒環境可為宿主環境（Host）提供一定的安全保障。

使它能夠在包括瀏覽器在內的很多不同的環境中運行。這些場景包括：云原生場景、移動設備、物聯網、區塊鏈等多種不同的場景。

下圖中充分說明了，WASM 在不同場景中的使用情況。

從圖中我們可以看出：

WebAssembly最多的應用場景依然是在Web站點開發上，大約占65%。
WebAssembly 在云原生和容器化方面的應用大幅增加，由去年的20%提升到了35%。
增長幅度最大的是在插件擴展方向，WebAssembly的沙盒化安全環境很適合用于托管不受信任的第三方代碼。

在不同的領域中， WASM 有著不同程度的應用。目前有大量的公司和組織在使用 WASM 或者參與 WASM 生態的建設，可觀下圖：

WASI

很多人可能疑惑為什么突然提到這個技術概念，因為WebAssembly是不止跑在瀏覽器里的前端技術，WebAssembly有著更遠大的的宏圖大業。

Docker的創始人Solomon Hykes曾發推文說到：在2008年如果WASM和 WASI(WebAssembly System Interface, WASM系統接口)這兩個已經存在了的話，我們就沒有必要創立 Docker了。在服務器上運行WebAssembly是計算的未來，但缺少的是一個標準的系統接口希望WASI可以成為它?。

WASI(WebAssembly?System Interface, WASM系統接口),系統接口指的就是例如文件操作、網絡連接、系統時鐘、隨機數之類的操作系統調用，開發WASI的唯一目的就是將WebAssembly向瀏覽器之外推進，最終能夠真正做到一份wasm代碼運行在所有不同環境不同操作系統的機器中。

WebAssembly運行在瀏覽器內，與系統交互靠的是JS膠水語言的能力，JS通過瀏覽器內核再到操作系統內核。而WebAssembly脫離了瀏覽器后，運行在各個操作系統中也需要抹平系統api的差異性，這就是WASI需要解決的問題。

WASI只是一個標準，業界也有一些實現方案，有些實現方案已經能做到生產環境使用了。正因為WASI的標準提出，才能讓WebAssembly這個崛起于前端的技術，在其他領域有著比他在前端更廣闊?的天地。

應用場景細化

1.web應用

1.1視頻編解碼

WASM 可以用于視頻編解碼，在 WASM 中實現的視頻解碼器可以用于在瀏覽器中播放視頻，目前 H5 支持的視頻格式有限，主要是三種：MP4, WebM 和 Ogg，而且不同瀏覽器支持的格式也不同，所以視頻類公司需要解決如何在網頁中播放其它格式視頻的問題，比如：愛奇藝、b站

從愛奇藝的技術博客中，我們得知由于之前使用的是 JavaScript，其運行效率較低。在引入了 WASM 技術之后替換 JavaScript 來進行轉封裝之后，他們發現瀏覽器中播放視頻的性能提高了將近 20%。下圖為愛奇藝直播使用 WASM 之后的性能提高。

B站視頻相關功能里也有大量的Wasm模塊，因視頻上傳、封面圖處理這些都是計算比較密集的場景，b站利用Wasm版FFmpeg來加速視頻編解碼以提高性能

1.2工具類

Figma在線UI設計

Figma 是一個瀏覽器應用，只要有瀏覽器就能使用。Figma利用WASM提高了他們的響應和載入速度。

Photoshop Web版：以前類似PS這種復雜的應用在web版是很難達到較好的用戶體驗的，然而通過使用各種新的Web技術，Photoshop 的公開測試版已經到來。這其中比較重要的就是WebAssembly技術的應用，除了解決性能問題，更重要的是充分利用了wasm的跨平臺特性，使Photeshop在web端和PC端應用可以由同一份源碼編譯生成。

1.3瀏覽器平臺的VR

VR概念的火爆，讓很多人都想體驗無需下載安裝任何軟件，直接在瀏覽器上體驗虛擬現實。在虛擬現實（VR）場景中，響應速度是非常重要的。為了解決瀏覽器版本的延遲問題，人們會傾向于使用 WASM 。在論文中提供一種可為基于瀏覽器的應用程序帶來近乎本地化的低延遲的解決方案，通過在任何 WiFi 或支持蜂窩數據網絡的 AR/VR 設備上運行的 WASM 的字節碼能在硬件平臺上實現豐富的可操作性。

2.云原生

云原生是一種基于容器的應用開發和部署方式，它將應用程序打包成容器，然后將容器部署到云平臺上，云原生的應用程序可以在任何地方運行，包括本地計算機、云平臺、邊緣計算設備等。

在云原生場景中，WASM 可以用于編寫云原生應用程序，也可以用于編寫云原生的基礎設施。

2.1容器

?我們先來認識下容器的概念？容器是一種輕量級的虛擬化技術，它可以將應用程序和它的依賴打包在一個文件中，然后在不同的環境中運行。但容器一般都需要在宿主機的內核上運行，而不是直接運行在硬件上，所以導致性能會比較差

我們前面提到Docker的創始人對WASM技術是比較認同的，所以Docker也傾向于用WASM技術解決一些問題，在 2022 年 10 月底，Docker 宣布推出與 WASM 集成 ( Docker + WASM ) 的首個技術預覽版，并表示公司已加入字節碼聯盟 ( Bytecode Alliance ) ( Bytecode Alliance 是 WASM 和 WebAssembly System Interface 背后的非營利組織)，成為投票成員。目前開發者已經可以通過最新版的 Docker 快速構建面向 WASM 運行時的應用程序

Docker Engine創建了一個新的 Containerd Shim，把負責容器進程運行的 runC 替換成 WasmEdge 運行時，Wasm Module 的啟動和運行都依賴于 WASM 運行時環境。這部分是和 WasmEdge 合作的項目，這個 Containerd Shim 從 OCI artifact 中提取 WASM 模塊，并使用 WasmEdge 運行時來運行。當然這里的 WasmEdge , 理論上可以把這部分擴展到 Wasmtime 等其他的 WASM 運行時。

2.2邊緣計算

近幾年云計算的蓬勃發展，邊界不斷擴展， “ Kubernetes + 容器”組合，自然也被很多人考慮部署到邊緣側，以提高邊緣應用部署的效率和便利性。

但邊緣設備硬件通常資源有限，無法滿足部署運行完整的 Kubernetes的需求，而且很多邊緣設備基于 ARM 架構，但Kubernetes 發行版對 ARM 架構的支持有限，這些問題都困擾著開發者使用Kubernetes在邊緣計算的應用。當然業界也在不斷為了解決以上問題進行探索，也有一些可供選擇的技術解決方案，比如華為的 KubeEdge、阿里開源的 OpenYurt、騰訊開源的 SuperEdge等項目。

邊緣計算需要更輕量、更快的容器方案，而WASM正是解決這些痛點的一個新機會。

WasmEdge是由Cloudflare、AWS等公司聯合貢獻的開源項目，其目標是構建一個高效、可靠、低延遲的邊緣計算平臺。

WasmEdge使用LLVM后端進行優化，提供了接近原生速度的執行效率，使得它能夠在一個小型、輕量級的容器中高效運行復雜的計算任務，可應用于物聯網(IoT)設備，實時處理傳感器數據，提高響應速度，減輕云端負擔。

2.3Serverless

WebAssembly是非常適合用作微服務和無服務平臺的。后端即服務(Backend as a Service，BaaS)，函數即服務(Function as a Service，FaaS)都可以歸屬到severless無服務模型。WebAssembly的啟動時間相比docker或者其它VM要快很多，WebAssembly的運行時是非常"輕"的，啟動一個WebAssembly實例只需要5微秒。除此之外，輕量級所帶來的另外一個優勢就是可以在一臺機器上搭載更多實例。

3. IOT

隨著世界變得更加互聯，物聯網 (IoT) 設備的數量呈爆炸式增長。這些設備具有各種形狀和尺寸，從大型工業機器到微型傳感器，這些設備的硬件參差不齊，某些設備對于功耗和性能還是有要求的，亟需高性能以及高可移植性的方案解決問題。而且某些Wasm 運行時支持 AoT編譯，它采用 Wasm 字節碼并為目標 CPU/MCU 類型生成機器碼。這種方案解決了那些沒有可用的 CPU 和內存來執行 JIT（即時）編譯的微型物聯網設備?。

4.游戲

主流游戲引擎（Unity/Unreal）已經支持編譯目標為 WASM 。在發展早期，asm.js 曾是在瀏覽器環境運行這些引擎的解決方案。因為 WASM 解決了 asm.js 的痛點，相比之下速度更快，代碼更少，使用內存量更少，所以現在 WASM 成為它們在瀏覽器環境中的默認編譯目標。??

?未來發展

目前 WASM 還在快速發展階段，盡管它還存在一些局限性，但它在非web場景下的發展及應用還是讓人眼前一亮的，未來可見的是會解決一些現有問題和增加特性。?比如：SIMD、并發等能力的支持和提升

標準的演進：社區針對WASI標準目前有一些分歧，但標準對于行業的規范化發展還是必不可少的。而且現在科技巨頭（Google、微軟、亞馬遜等）也開始認可WASM，相信他們在社區方面的積極推動能做出更多貢獻。標準方面仍有重要的工作要做；WebAssembly對Web平臺的API支持，例如支持操作DOM等，線程并發等都在激烈討論中。
編程語言和平臺：WebAssembly會支持更多的編程語言和平臺,像 C++ 、Go （包括 TinyGo ）和 Rust 這樣的語言已經接受了 WASM ，但一些最常見的語言，如 Python 、 Java 和 PHP 還在努力實現支持，在客戶端和服務器端應用的范圍將會更廣泛。
?開發體驗更友好：WASM初期開發人員在一些大型復雜應用中使用該技術，難免會遇到各種問題，彼時WASM的工程化和工具鏈都不夠成熟，比如調試在WASM就是一個讓人頭痛的問題，編譯WASM和實際使用的開發鏈上也有不少可以提升和優化的工具。可猜測的未來WebAssembly開發工具和庫會變得更加完善，例如IDE、調試工具、庫等，使得WebAssembly的開發和調試更加容易和高效。

結語

本文我們已經討論了WebAssembly 在各種不同場景的應用和未來的發展趨勢。當然 WebAssembly 還處在發展的初期，有優勢也有很多不完善的地方。隨著WebAssembly在各個領域的應用，相信未來會有越來越多的開發者使用WebAssembly進行Web應用程序的開發，我們期待著WebAssembly能夠更好地與其他技術交互和融合，為Web開發帶來更高效、安全和優質的開發體驗。