Cube 技術解讀 | Cube 小程序技術詳解

• 2022 年 1 月 4 日
• 筆記
• cube, mPaaS, 小程序, 支付寶, 移動開發

本文為《Cube 技術解讀》系列第三篇文章，之前上線的《支付寶新一代動態化技術架構與選型綜述》與《Cube卡片技術棧解讀》歡迎大家回顧。

魔方卡片（Cube）已在「支付寶」App 中被廣泛應用，同時，現已支持在 mPaaS 側對外商業化輸出，歡迎廣大開發者登錄 mPaaS 控制台體驗及使用。

而 Cube 小程序則是 Cube 技術除了魔方卡片（Cube）外的另外一種形態，將主要應用與智能電視、POS 機以及其他 IoT 領域，目前還在研發打磨中，歡迎廣大開發者交流探討。

小程序作為動態化或者跨端開發的一種技術棧，在業界成為事實標準。Cube 作為一種輕量級小程序技術棧，具有體積小、啟動快、內存佔用低等特點，也比較適合「即用即走」的小程序場景。

以下將重點介紹 Cube 小程序技術棧與技術演進實踐（若無特殊說明，所有的數據和圖表都是針對小程序）。

渲染小程序

模塊組成

小程序視角，Cube 渲染引擎主要由以下模塊組成：

• Components：主要是小程序規範里的組件；

• Layout：支持 Inline，Block，Flex，Inline-Block，Inline-Flex 等多種布局方式，還包括文本分詞，斷行等計算；

• Style：支持樣式解析，樣式匹配，樣式繼承，偽類和偽元素等多種選擇器；

• Rendering：管理渲染相關 Render Tree，圖片資源請求調度等；

• Animation：JS 和 CSS 動畫實現；

• JS Bridge：和 JS 引擎橋接；

• JS Engine：目前支持 V8，JSC，QuickJS；其中 Android 下支持 V8，QuickJS；

• Compositor：用於動畫和圖層的合成器（開發中）。

線程模型

Cube 小程序技術棧內部有這麼幾個線程：Bridge，Layout，Render，Paint，UI 等。

• Bridge 線程：執行 JS；與 AppX 橋接的類 DOM 的 JSAPI；處理 JS 相關事件；

• Layout 線程：布局計算；樣式計算與匹配；維護 Layout Tree；

• Render 線程：維護 Render Tree；綁定數據；分層；

• Paint 線程：生成繪製命令；

• UI 線程：平台事件分發；UI 布局。

小結：

• 並行布局，異步繪製：這裡的並行是指 JS 執行，Layout 布局 以及 Render 三者完全並行處理。由於 Layout 和 Render，Paint 等不在一個線程，因此是異步繪製；

• 多個線程協同工作，有點像 CPU 的 5 級流水線。

值得注意得是：Web 渲染引擎有個特點就是和 Node 相關的 DOM 操作必須和 JS 在一個線程。這就導致解析 HTML，布局，樣式計算，DOM，JS （包括垃圾回收）都在一個線程里。帶來的後果就是只有解析完文檔才能看到 UI 效果，這也是 Web 渲染小程序白屏時間較長的一個原因。

Cube 小程序技術棧，將「DOM操作」 和 JS 執行解耦。因此 JS 的 GC 不會影響 UI 呈現。這種實現對於加快小程序啟動非常有幫助。由於布局計算和 JS 執行也解開耦合，因此一般不會由於 JS 執行阻塞 UI 交互。

Cube 小程序技術棧的特點

• 體積小，啟動快：主 so 只有 2.8 MB（如果包括 Ariver，AppX，InsideSDK，整體小程序技術棧最小是 5.7MB）。另外可以享受到 OS 的紅利（包括 UI 的初始化和緩存）；

• 高性能：接近於原生體驗；

• 內存佔用小：小程序技術棧初始化後（包括 Inside SDK，Cube，AppX），大約只需要 7.5 MB；

• 支持 Android，iOS 雙端。

與 Web 引擎對比

下面僅僅針對小程序場景與 Web 引擎對比：

技術演進

• 讓小程序業務低成本適配 Cube 渲染小程序，需要做三方面的工作：

• 擁抱 Web 技術，補齊前端開發常用的能力：包括 CSS，小程序組件等；

• 完善相關工具：包括開發，調試，Profile，發佈，打包等；

• 針對 Cube 的架構特點，深入優化，並拉開和 Web 渲染的差異。提供更好的用戶體驗。

新的流式布局（Flow Layout）

最初 Cube 小程序使用只支持 Flex 布局 Yoga 用於布局計算。後面升級成支持 Block，Flex，Inline-Block等多種布局方式的 Flow Layout。從而解決開發者只能使用 Flex 布局的困擾。目前兩個布局引擎 Cube 內部都支持。其中 Flow Layout 主要用在小程序，Yoga 用在卡片。兩者能力差異如下：

支持 CSS 樣式表

老版本的 Cube 只支持內聯樣式和簡單的 CSS 選擇器；然而小程序並沒有約束 CSS，因此 Cube 擴充支持 CSS 樣式表，樣式繼承，多種選擇器等。從而使得 Web 渲染切換到 Cube 渲染，適配成本大大降低。甚至部分小程序可以做到在小程序 IDE 里基於 Web 渲染開發，然後打包成 Cube 渲染產物在真機上預覽。前端同學無需進行過多的修改和適配。

新老 Cube 版本，選擇器支持上的差異如下：

註：

• [1] 老版本 Cube 是指：錢包 10.2.0 以前版本；

• 新樣式能力基本上對標 Web 引擎的樣式能力；

• 新樣式能力支持像這種複雜選擇器。

div > div.jartto p span.yellow a#t1 {}
.pixel-ratio-2 .web1px::before {}
div:nth-child(2n+1) {}
input[type="button"] {}
#blue,div > div.jartto p span.yellow a#t1 {}

支持自動分詞，斷行（Inline Text）

最初 Cube 用的是 Android 和 iOS 提供的文本計算和繪製能力。這種技術方案（以下稱為平台層 Text）存在3個問題：

1. 性能問題：特別是 Android 下，利用 Android 平台層的接口實現文本布局計算，導致在文本較多的情況下，布局耗時在渲染整體耗時里佔比較高；

2. 富文本特性：富文本以及許多文本特性支持較麻煩；

3. 各平台上實現文本效果存在細節差異或者兼容性問題。

針對上述問題，在 Flow Layout 基礎上增強支持 Inline Text 布局計算文本。基於 Inline Text 可以較輕鬆實現以下富文本，圖文混排，分詞，自動換行等。

1.富文本

2.自動換行和分詞

Inline Text 實現前後的文本樣式對比如下：

註：

• 假設原有 Cube 採用平台層接口實現的文本特性稱為：平台層 Text；

• √表示實現細節上不完善或者不完全支持；

• 在 Inline Text 基礎上可以實現功能豐富的富文本組件；

• 值得一提的是：該實現非常精巧，對於 Cube 包體積只增加了 170KB。具體細節後續文章詳細探討。

文本布局計算耗時對比（文本節點較多場景）：

採用 QuickJS 替代 V8

V8 雖然是性能最高的 JS 引擎，但是存在內存佔用大，初始化較慢等不足。在 IoT 或者低端設備上這些不足會被放大。因此在這些設備上，Cube 採用 QuickJS 取代 V8。一方面降低內存佔用，另外一方面提升初始化性能。

Cube 內部目前適配了多個 JS 引擎，具體如下：

• 在 Android 移動端上使用 V8 和 JSI

• iOS 上使用 JSC

• IoT 等低端設備上使用 QuickJS

另外我們在開源 QuickJS 基礎上做了些優化工作。優化的結果大致如下（後續文章將詳細介紹）：

支持動畫和多媒體組件

除了上述基礎組件和能力之外，動畫和多媒體也是部分小程序不可缺少的。因此我們擴展支持了 Video，Canvas、Lottie，Live Player 等組件支持。並應用於 TV 大屏小程序、小遊戲以及直播場景上。

在低端設備上，如何提高動畫幀率並且降低內存佔用也做了深度的優化。以下是 Video 和 Canvas 組件在小程序中的效果圖：

支持多種模式的小程序產物

目前 Cube 支持多種模式的小程序產物：Native，Cube，Shared。

• Native 模式：對應的是舊的 Cube 渲染小程序模式，不支持 CSS 樣式表，只能支持內聯樣式和有限的幾種 CSS 選擇器。性能最高，兼容性較低；

• Cube 模式：在 Native 模式進化而來，支持 CSS 樣式表和多種 CSS 選擇器。性能良好，支持常用的 CSS 樣式和特性（包括樣式繼承，多種 CSS 選擇器）；

• Shared 模式：為了降低 Web 渲染的小程序遷移或者過渡到 Cube 渲染而開發。在同一個小程序產物里既支持 Web 渲染一部分頁面又支持 Cube 渲染一部分頁面。而且 Cube 渲染的頁面支持樣式表。這樣在性能和兼容性平衡。小程序產物相對於 Web 渲染的小程序，產物體積增加不會超過 10%。

註：如果需要 Web 產物兜底，則 Native 模式 和 Cube 模式的小程序產物，比 Shared 模式大。

研發進展

Cube 小程序在 TV 和 POS 機上和相關團隊，一起打磨小程序技術棧（包括渲染引擎，JS 引擎，AppX，Ariver 容器）等。

在 TV 上面臨的問題：

• 內存少：有的設備只有 512MB 內存，長列表滾動容易卡；

• 需要支持焦點切換；

• CPU 主頻較低：有的只有 1GHz。

短中期目標是用小程序技術棧替代 WeeX 單頁。當前進展如下：

• 小程序啟動性能上超過 WeeX 單頁（低端設備上優勢更明顯）；

• 內存佔用上，小程序初始化後內存佔用小於 10MB，典型小程序整體內存佔用在 32MB 左右。

具體細節後續文章詳細總結。

在 POS 機上面臨的問題：

在 POS 機上跑點餐小程序，主要有面臨以下問題：

• 內存少：部分設備只有 512MB 內存，容易出現卡死和 OOM；

• CPU 核心少：部分 CPU 只有雙核（硬件性能大約是主流手機的 1/5）；

• 長列表滾動卡。

短中期目標是用小程序技術棧替代 Flutter 開發的 App。當前進展如下：

• 小程序首屏啟動性能提升了 30%+；

• 小程序重點的交互場景的頁面，比如：購物車，商品詳情頁等，都已接近 Flutter App；

• 首頁滾動幀率達到 50，用戶已經難以感知和 Flutter 的差異（Flutter 幀率是 60）；

• 小程序內存佔用下降了 30%（本地測試已無卡死和 OOM）。

該場景主要是文本節點較多的長列表。採用了非常多的優化方法，後續文章詳細總結介紹。

總結

為了適配小程序，Cube 渲染引擎在布局計算、樣式能力、組件支持，還有開發工具等在小夥伴一起努力下取得了較大的進展。同時在低端設備（比如：IoT 設備）或者性能敏感場景，Cube 小程序性能優化，降低內存佔用也取得了不錯的效果。

而未來面對多種多樣的 IoT 設備，還需要加速技術演進以支持更多的場景。歡迎大家一起來交流討論。

本文轉自公眾號「阿里巴巴移動技術」，作者：曾維宏(恆實)