基於 WebAssembly 的AIoT應用框架實踐

Waft 是一個專注於 AIoT 領域，面向原子化服務的應用開發框架，核心解決的是 AIoT 領域下使用者和服務連線低效的問題。具備高效能、動態化、原子化、跨平臺、支援多語言開發等特性：

背景

2014年年底，亞馬遜推出了一個全新的智慧硬體產品——"Echo" 智慧音箱，該裝置可以隨時響應使用者的語音指令，由內建的虛擬助手 Alexa 為使用者提供資訊、音樂、設定鬧鐘、控制智慧家居裝置等服務。一時間，全球網際網路巨頭紛紛入局，佈局家庭 AIoT 新賽道，搶佔家庭場景的流量新入口。隨著新玩家的入場，智慧音箱的能力也在飛速提升，不僅能聽歌與智慧家居控制，還可以設定鬧鐘與日程，百科問答與聊天等，簡單高效的語音互動讓使用者真切的感受到人工智慧技術的到來。

2019年春季，天貓精靈釋出了第一款帶屏的智慧音箱。 相比傳統音箱，不僅增加了一塊更利於使用者互動的螢幕，還支援了各種感測器裝置，成為了一款真正的智慧家庭助手裝置。 作為一款普惠AI的產品，為了讓更多的使用者能夠體驗到人工智慧的便利性，智慧音箱的硬體配置相對比較低，整體硬體配置與當前市面上的手機相差甚遠，對應用軟體的執行效能提出了巨大的挑戰。 除了這些自研產品外，天貓精靈還支援了很多生態硬體產品，如： 手錶、電視、中控面板等。 這些 AIoT 裝置具有以下特點：

• 硬體配置跨度大：記憶體從128M到2G，儲存從128M到32G

• 螢幕尺寸多樣，從1.3寸、4寸、7寸、8寸、10寸到電視大屏

• 作業系統多樣：Android、Linux、RTOS 等

我們一直在思考和探索下面兩個問題的解決方案：

• 什麼樣的應用形態，更適合 AIoT 裝置？

• 什麼樣的應用框架和開發方式，更適合 AIoT 領域的開發者？

我們陸續嘗試了多種應用開發方式和框架：

1. 2018年6月，開始引入 Andorid APP 的生態。陸續接入了優酷、芒果TV、BliBli、騰訊影片、愛奇藝、快手、抖音等30多個 APP。但由於天貓精靈裝置算力與儲存的限制，無法安裝太多應用，一個 APP 要幾十M左右，導致軟體生態受到限制。

2. 2018年12月，我們嘗試引入小程式技術來解決儲存空間不足的問題。並於19年1月上線第一個小程式貓精版“螞蟻森林”，之後陸續引入了：寶寶巴士、鬥魚直播、貝瓦兒歌、汽車之家等600多個小程式。但問題也很明顯：

1）在1G記憶體裝置上，小程式的效能較差體驗不太理想，冷啟動需要十多秒，熱啟動需6秒左右。

2）面向手機開發的小程式幾乎都是豎屏版本，在 天 貓 精 靈 的橫屏裝置上體驗並不好，需要開發者做UI適配或者容器端做分屏顯示處理。

3. 2020年7月，開始在 天 貓 精 靈 裝置上嘗試雲應用，想徹底突破終端的效能問題。 雲應用可能是 應用生態的終極解決方案之一。 一切應用皆可上雲，當前所有的應用生態都可囊括，且終端無效能壓力。但當前成本太高，還無法大規模鋪開。需要等待5G和雲應用的大規模爆發，來降低伺服器和頻寬成本以及網路延遲。

經過近三年在天貓精靈應用開放上的嘗試，逐步形成了我們對 AIoT 行業的一些理解：

• 終端形態：硬體配置、作業系統和螢幕呈多樣化發展、碎片化分佈。

• 場景需求：觸達路徑短、多模態互動、多源服務靈活聚合。

• 業務核心：快速響應演算法，提供多種UI形態的智慧化服務。

這對我們的技術框架提出了非常高的要求：

• 能充分發揮硬體效能，在低配置硬體中實現極速啟動。

• 支援多模態互動，通過服務原子化精準快速地滿足使用者意圖。

• 可跨系統跨平臺實現多端自適應。

• 面向AIoT行業開發者友好的開發工具鏈。

• 重雲（邊）輕端，降低終端側的效能壓力。

經過近兩年的嘗試，發現在天貓精靈 AIoT 上，APK 和小程式方案並不能很好的滿足上述訴求，無法兼顧使用者體驗和應用生態，且雲應用尚無法大規模鋪開的情況下，我們從2020.08開始嘗試探索一種新的解決方案 —— Waft。

Waft是什麼

Waft 是一個面向 AIoT 原子化服務的應用開發框架，是一個適合 AIoT 應用開發的解決方案。

取名叫 Waft，其實有兩重含義在裡面：

• Waft 是 WebAssembly Framework for Things 的縮寫，是一個面向 AIoT 的 WebAssembly 框架。

• Waft 單詞本身的含義是“（在空氣中）飄蕩”，和我們的目標比較匹配：輕量的高效能的應用框架。

Waft的發展歷程：

設計理念

Waft 的設計理念： 原子化服務的快速直達和靈活的場景化組合 。

化整為零：超級應用的核心內容短平快直達

移動網際網路時代，一個個 App 將網際網路割裂成資訊孤島，使得使用者獲取資訊和服務的成本越來越高，操作路徑越來越長。在天貓精靈智慧終端上，我們希望能通過原子化服務的方式來解決這個問題。原子化服務指的是應用中能滿足某個特定使用者意圖的完整功能，比如快遞提醒，瞭解疫情資訊，收取螞蟻森林能量。將核心功能從應用中抽取出來後，通過卡片、浮窗這類輕量互動方式，縮短觸達使用者的路徑，降低使用者使用的成本。

化零為整：多來源的服務組合成場景化應用

當深藏在應用中的服務被原子化後，就具備了被重新組合成場景化應用的可能性。以天貓精靈中的語音頭條為例，當用戶起床後，可以跟精靈說“早上好”，得到天氣、交通限行、新聞、音樂等資訊服務，早上好就是由天氣、出行、新聞、音樂等一系列應用中的原子化服務重組後的場景應用。類似的，還有中午好、晚上好等聚合了多種原子化服務的場景。更進一步的組合，是打通使用者上下文資訊的組合，一個服務的輸出可以作為另一個服務的輸入，比如使用者預定了杭州到北京的機票這一資訊語境，可以被傳輸到預定酒店的服務中，無需使用者再次輸入重複的資訊，使用者購買電影票的資訊，可以作為美食餐廳推薦服務的輸入，為使用者提供更貼心的組合服務。

設計目標

從開發者的角度看，可以把 waft 容器簡單類比成一個輕量級的瀏覽器，專注於 AIoT 領域，儘可能拋棄歷史包袱。

和傳統瀏覽器的差異主要在於：

1）核心的差異：

2）開發方式的差異：

Waft 的設計目標如下：

• 高效能：支援 AOT 執行模式，能接近原生應用體驗，可執行在非常低配的 IoT 裝置上。

• 原子化：面向原子化的服務。化整為零，超級應用的核心內容短平快直達；化零為整，多源化的服務重組成場景化應用。

• 動態化：應用和服務都可以動態下發與更新，具備與Web同級別的動態化能力。

• 跨平臺：支援 Android, Linux, RTOS, MacOS 等多平臺，並能實現UI自適應，能力自降級。

• 多語言：面向廣大的開發者群體(前端、終端、傳統 IoT 端、後端等)，支援 AssemblyScript, Kotlin, Swift, C/C++,  Rust, Golang 等多種開發語言。

• 端雲協同：應用邏輯和任務堆疊託管到雲端執行，終端只做最終渲染和使用者互動的反饋。

技術方案

Waft 是基於 WebAssembly 構建起來的一套應用開發框架：

WebAssembly 是一種體積小且載入快的 二進位制格式 ， 其目標就是充分發揮硬體能力以達到原生執行效率。是一種執行在現代網路瀏覽器（並不侷限於）中的新型程式碼格式，並且提供新的效能特性和效果。它設計的目的不是為了手寫程式碼，而是為將諸如 AssemblyScript、Kotlin、Swift、C、C++、Rust、Golang 等高階語言編譯為一種執行效率更高的中間位元組碼（可簡單類比為 Web 的組合語言）。 我們選擇基於 WebAssembly 來搭建 Waft 的整套技術體系，主要原因如下：

• WebAssembly 是 W3C 的標準，技術理念先進，開源社群活躍。

• 支援 AOT 模式，具有和原生幾乎相當的效能表現。

• 可脫離瀏覽器執行，可執行在 IoT 裝置上。

• 支援多語言開發，社群內已有多種語言可編譯為 WebAssembly 格式。

• 具有很好的跨平臺和動態化特性。

Waft終端架構

終端容器的核心任務是，頁面的快速響應和豐富的表現形式，給使用者一個非常好的互動體驗。

Waft容器的三個核心模組為 Framework、Engine和 Native Services (基礎服務)：

• Framework: 作為終端的大腦，職責包括：端雲協同、包管理、場景管理、資源管理等等。

• Engine: 頁面渲染與邏輯執行的核心模組，包括：Runtime 虛擬機器、DOM Parser 以及頁面渲染與繪製。

• Native Services (基礎服務)：提供多種高效能的原子化服務，減輕業務開發的難度與工作量。

Waft渲染管線

說明如下：

• AST：抽象語法樹，通過編譯器將 XML 和 CSS Styles 編譯為一個json格式的抽象語法樹。

• VDOM Tree：虛擬 DOM 樹，根據自定義的 JSON 資料格式生成，UI 的虛擬表現形式，並可以通過設定不同的資料修改 VDOM 結構和資料，最終驅動真實元件進行繪製。

• Layout Tree：由 Yoga 建立的，包含寬高、Padding 等位置資訊的資料結構，用於佈局排版。

• Render Tree：CSSOM 和 DOM 合併而成，包含節點的樣式、佈局等資訊，用於渲染。

Waft前端框架和工具

在基於 WebAssembly 執行的基礎上，為了更好的支援前端開發者生態，我們選用了 AssemblyScript 作為前端框架的邏輯開發語言，它是 TypeScript 的語法變種。在前端框架的設計上，主要包含了3個層面：

• 框架核心層：封裝了渲染引擎、容器的API，具備生命週期、狀態管理、多頁路由等前端框架的核心能力。

• 工程構建層：集成了框架核心的構建能力。通過解析工程目錄和 DSL，並進行編譯成 Wasm/AOT 包的能力。並增加了內建函式，語法檢查等實用功能。

• 應用能力層：建設框架的UI元件庫，WebAPI/CSS標準，響應式&自適應能力，以及語音/觸屏多模態互動能力，並支援卡片開發標準。

在開發者工具上，目前支援了4個部分：

• IDE 外掛：VSCode 外掛集成了工程初始化，開發除錯，編碼輔助，應用管理等綜合能力。

• CLI 工具：CLI 支援無介面形式的工程流程化管理，包括建立、除錯、打包、單測等階段。

• Chrome DevTools：基於 Chrome DevTools Protocol 協議的開發除錯工具，可支援本地模擬器、無線方式連線真機的方式進行除錯，進行元素檢查、日誌檢視等功能。

• 線上工具：支援低程式碼平臺進行快速搭建產出應用，CloudIDE 雲端編輯和雲真機等能力。

技術特點

當前市面上的跨端方案也比較多，Waft 與其他方案相比，優勢在於同時兼顧了動態化、高效能和跨端一致性；劣勢在於因只支援 CSS的子集，頁面編寫靈活性上不如H5/小程式：

除了這些特點外，Waft還具備一些其他方案少有的特性。

端雲協同

Waft有一個核心目標是雲化：頁面跳轉邏輯和任務堆疊交由雲端管理，終端只做頁面渲染和互動的反饋。

藉助於 天 貓 精 靈 雲端 DM (Dialog Manager, 對話管理) 服務的能力，Waft應用的跳轉邏輯和業務堆疊管理可交由雲端管控。終端頁面在點選某個跳轉按鈕時，只需給 DM 傳遞相應的意圖引數，DM 負責分發意圖，呼叫對應的技能服務(應用)，再由技能服務向終端推送新的頁面，這裡的意圖和 Android 的 Intent 的作用非常相似。

藉助於貓精的對話流編排平臺，可將多個零散的原子化服務(頁面)，組合為一個複合場景，在平臺上通過視覺化編排的方式，構建多個頁面間的跳轉邏輯。

如下圖“早上好場景”的對話流：

端雲協同互動流程

動態化的AOT

得益於 WebAssembly 的技術優勢，Waft 可實現 AOT 級別的動態化能力，整體邏輯上跟動態載入執行一個 so 比較類似，且因為 WASM 執行在Waft容器的沙箱環境中，相比動態化so更安全可控。

多語言開發

因 WebAssembly (簡稱Wasm) 只是一種二進位制格式，理論上只要某種語言的工具鏈支援將原始碼編譯為 Wasm 格式，就可以在 Waft 容器中執行。

為了降低程式碼實現難度、提高可擴充套件性，現代編譯器一般都會按模組化的方式設計和實現。典型的做法是把編譯器分成前端（Front End）、中端（Middle End）、後端（Back End）。前端主要負責預處理、詞法分析、語法分析，生成便於後續處理的中間表示（Intermediate Representation, IR）。中端對IR進行分析和各種優化，例如常量摺疊、死程式碼消除、函式內聯。後端生成目的碼，把IR轉換成平臺相關的彙編程式碼，最終由彙編器編譯為機器碼。

雲端渲染

可將原來在終端上完成的UI資料解析、繫結、測量等渲染前的耗時操作由終端轉移到雲端，雲端僅下發繪製指令，由自研渲染引擎直接完成渲染。部分場景下可將UI渲染轉移到雲端，直接在雲端生成 UI 圖片後推送到終端進行顯示。大致思路如下：

上圖的補充說明：

1. 在雲和端上部署同一套 Waft Contanier 執行環境。

2. 將整個渲染拆分為5個步驟：

• 資料繫結 (DataBinding): 將 AST 和 Data 進行資料繫結，形成一個 VDom Tree (JSON 格式)

• 大小測量與位置計算 (Measure & Layout)：對 VDom Tree 進行 CSS 解析和佈局處理，計算出每個元素的x、y座標和width、height等資訊。產出一個包含詳細布局資訊的 Layout Tree。

• 建立UI元件：將 LayoutTree 中的每個節點，轉換為呼叫實際的建立UI元件的程式碼(如：createButton, createTextView, createImageView等等)。

• 繪製(Paint)：使用Skia圖形庫，在顯示的 FrameBuffer 中繪製。

• 展示(Display)：在螢幕中展示 FrameBuffer 中的內容，展示出最終的頁面。

3.  渲染的5個步驟，可以按場景決定雲端和終端分別執行哪幾步，比如：將資料繫結、大小測量與位置計算、建立UI元件指令這些操作放在雲端的 Waft Container 中執行，將 Paint、Display 兩步交給端上執行。

注：雲端渲染能力，還在預研階段，待線上業務落地後，我們會再詳細展開介紹這部分的實踐經驗

應用開發方式

在應用開發上，我們遵循“前端友好，研發提效”的理念，在框架設計和開發工具建設上提供更完整的解決方案，降低前端和AIoT開發者的開發門檻。所以Waft開發的上手也主要分為兩個部分，一個是前端框架的學習使用，包括開發語言、元件庫、API等；另一個是開發工具的上手使用，包括原始碼CLI工具的流程命令以及Devtools的使用；另外，開發者也可以使用我們的低程式碼搭建平臺來快速生產卡片應用。

開發語言

前端 UI 框架支援兩種DSL，支援類Web的單檔案寫法，以及阿里系的小程式寫法。目前支援的邏輯指令碼語言為 AssemblyScript，AS 是專門為 WebAssembly 設計的一種新語言，採用了類似 TypeScript 的變種語法，可以讓熟悉 TS 的前端開發者更快地上手。此外，我們也正在支援Kotlin/Swift/Rust/C/C++等其他開發語言。為了讓大家對Waft有一個直觀瞭解，在此展示下簡單的頁面開發程式碼和執行效果：

研發流程

Waft-CLI腳手架是輔助開發者原始碼開發的提效工具，封裝了多階段的不同功能：

• 初始化階段：通過 waft init 快速初始化應用，內建了1個通用開發模板以及多種業務模板。

• 開發除錯階段：通過 waft dev 開啟除錯模式，內建了連線多平臺的Devtools工具，支援Web瀏覽器、Mac模擬器和真機的除錯預覽。

• 質量檢測：封裝了單測執行、視覺稿對比、效能performance等質量檢測功能。

• 打包上傳：通過 waft build 構建wasm包和多平臺AOT包，並支援和雲端技能平臺關聯進行上傳和釋出。

• 執行監控：在執行態下，Waft框架和容器已經預設攜帶了應用的效能監控和基礎資料埋點能力，後期會在開發者平臺逐漸對三方開發者開放。

開發除錯工具

除錯工具(DevTools)可以幫助開發者更容易地定位與解決問題，目前功能支援了元素，日誌，網路請求資訊檢查，如下方影片所示。

為了達到 web 的開發除錯體驗，Waft 遵循了Chrome的除錯協議(Chrome Debug Protocol)，通過 Chrome 瀏覽器內建的除錯工具，提供日誌、元素審查、網路請求監控等功能。下圖展示了偵錯程式如何與裝置進行通訊，並獲取除錯資訊的流程：

低程式碼開發工具

Waft作為“端雲一體化”框架，不僅支援通過原始碼方式開發複雜的應用，同樣支援通過低程式碼搭建平臺，更高效、靈活的開發“輕服務”。輕服務，是連線使用者意圖與服務之間的直通橋樑，將原本藏在技能、應用的原子化服務釋放出來，方便使用者在天貓精靈端上直接觸達某一個特定的完整功能，而無需提前開啟技能、應用。在天貓精靈上建立一個輕服務的流程如下：

下面是低程式碼開發的演示影片：

業務形態

Waft已支援多種業務表現形態，可根據裝置形態和應用形態靈活使用。

智慧場景

特點：雲端編排劇本，將多個頁面組合為智慧場景，互動邏輯由雲端決策，終端做頁面展示與使用者操作反饋。

適用領域：適用於助手類業務，如：早上好、晚上好、回家/離家模式等。

單頁面

特點：雲端下發資料和模版，終端通過 DataBinding 實現資訊的透出，重展示輕互動。

適用領域：適用於資訊展示為主的領域、如：天氣、時間、百科等

輕服務

特點：兼顧核心資訊展示與應用導流的作用，並通過聲屏聯動，在恰當時機內自動關閉輕服務彈窗

適用領域：適用於關鍵資訊查詢，且背後都有一個完整應用的領域，如：查快遞、查課表等。

浮層

特點：不打擾當前頁面互動，以簡潔的方式和當前頁面融合。

適用領域：螢幕特效，如：放鞭炮/煙花/炸彈等；以及個人相關時效性資訊的推送通知，如：快遞、外賣等；

Widget

可做為Widget，嵌入到任意頁面內，以資訊流的方式，實現內容透出、分發和引流。

6.6 多端適配

可針對不同的裝置不同場景，做差異化的適配，以提供更好的互動流程，提升使用者互動體驗。在保證基礎互動一致性的基礎上，充分利用裝置硬體特點和優勢。如我們在優酷TV大屏上天氣展示：

總結與展望

自2020.09年開始到現在，Waft經過大半年的發展，上線了10多個業務：早上好、晚安等智慧場景，天氣、時間等單頁應用，查快遞、查疫情等原子化的輕服務，放鞭炮、放煙花等節日彩蛋特效；除了天貓精靈自研裝置外，還在優酷TV大屏、海爾電視等生態裝置上線，階段性地完成了最初的一些技術設想與目標。

高效能

Waft 最核心的目標是高效能，能快速的響應使用者的請求。以下是Waft在天貓精靈1G裝置上的效能表現，擷取其中三個線上業務的監控資料：

下面是貓精版的螞蟻森林，在1G裝置上，Waft和小程式方案的冷啟動對比影片：

雖然當前的效能表現還不錯，但效能是Waft立足之本， 我們會進一步挑戰冷啟1.5s，熱啟1s的極致體驗。 從當前業務效能監控來看，啟動耗時的瓶頸在於渲染，因此，渲染引擎的優化將是我們後續重點投入的方向。

原子化

提面提到過的原子化服務包含兩重含義：

• 化整為零：超級應用的核心內容短平快直達，縮短使用者獲取服務的路徑。

• 化零為整：多來源的服務組合成場景化應用，提升使用者的需求滿足度。

已上線原子化服務有：快遞、課表、疫情、股市大盤、螞蟻能量等，使用者可快捷獲取這些服務的核心資訊。

    

服務原子化後，還帶來了更多的可能性：

1）可以很方便被各種場景組合，如天貓精靈上早上好、晚上好等場景。在這些場景內編排組合了天氣、時間、限行、早安新聞、精選歌單等多個原子化的服務。

2）也可以嵌入到其他頁面內，提供分發效率。如在天貓精靈的“服務直達“頁面內，嵌入了多個Waft的輕服務卡片。

跨平臺

Waft的核心模組都是使用C/C++開發的，可便於做多平臺的移植。目前已經在Android端上線，並且在RTOS和Linux平臺已跑通DEMO。因 Waft 是聚焦在AIoT領域，暫不考慮iOS裝置：

除了技術框架的跨平臺外，對於不同螢幕的UI自適應也是我們的一個重點方向：

多語言

得益於WebAssembly的技術優勢，藉助開源社群的力量，可支援多語言開發。當前已支援 AssemblyScript ， C/C++/Rust也經過可行性驗證 。 我們還會陸續支援C/C++、 Kotlin 、Swift、Golang等開發語言。

我們會持續基於 WebAssembly 和自繪渲染引擎做更多的探索和嘗試。如果您對 WebAssembly 或者 AIoT 領域的應用研發也感興趣，歡迎在文末評論區留言和我們進行交流。如果您想加入貓精大前端團隊一起探索，歡迎傳送簡歷到 [email protected]

關注 「Alibaba F2E」 微信公眾號 把握阿里巴巴前端新動向