?????♀? 編者按：Cube 起源于 native 頁面的動態(tài)化訴求，產(chǎn)品形態(tài)表現(xiàn)于 Cube 卡片。隨著小程序概念的出現(xiàn)，Cube 融入了支付寶小程序技術(shù)棧，產(chǎn)品形態(tài)為輕量級的支付寶小程序解決方案。本文為《Cube 技術(shù)解讀》系列首篇文章，作者是螞蟻集團客戶端工程師入弦，歡迎查閱～

背景

支付寶客戶端的動態(tài)化技術(shù)經(jīng)歷三個階段。第一個階段是 native+web 的 hybrid 模式，以 webview 為基石。第二階段是實體組件模式，把 html 描述的組件和? css 樣式信息映射到實體組件，并且把實體組件的事件傳遞到j(luò)s層進行處理。第三階段是實體組件+部分光柵化的hybrid模式，Cube 是第三階段的產(chǎn)物。Cube 起源于 native 頁面的動態(tài)化訴求，產(chǎn)品形態(tài)表現(xiàn)于 Cube 卡片。隨著小程序概念的出現(xiàn)，Cube 融入了支付寶小程序技術(shù)棧，產(chǎn)品形態(tài)為輕量級的支付寶小程序解決方案（相對于使用瀏覽作為核心的 web 小程序）。這篇文章是一個綜述，也是 Cube 系列的首篇文章。

技術(shù)選型&演進

Cube 的準(zhǔn)確誕生時間很難確定，大致在 16 和 17 年之間，比 RN（ReactNative）晚上一年。Cube 誕生的主要原因是 native 頁面的動態(tài)化訴求。錢包改版的頻率高，給研發(fā)的壓力很大，于是想到把高頻改版的頁面動態(tài)化。RN 和 Flutter 的出現(xiàn)，給了我們一個很好的觀察視角，即業(yè)界優(yōu)秀的科技公司是如何看待動態(tài)化這個話題以及它們的答案。起步階段，我們達成以下共識：

1、獨立研發(fā)，自主可控。我們沒有選擇基于 RN 的開源代碼來實現(xiàn)我們的動態(tài)化解決方案，也沒有 Flutter 公布源碼后，切換到 Flutter。這么做是考慮到兩點，第一點，技術(shù)棧的演進要掌握在自己手里，不希望被牽著鼻子走；第二點，開源項目的產(chǎn)品化成本并不低，后期的維護成本也不低；

2、服務(wù)業(yè)務(wù)，技術(shù)克制。首先，我們沒有足夠能力和資源來支撐一個通用技術(shù)產(chǎn)品，服務(wù)于錢包業(yè)務(wù)是第一位的，簡單說就是貼著業(yè)務(wù)走。其次，我們拒絕只求花里胡哨的技術(shù) demo，把核心能力做好，把產(chǎn)品成熟度做好，考慮拿到業(yè)務(wù)價值是第一位的。

基于上面兩個共識，我們的技術(shù)選型如下：

1. 選擇 Javascript 作為邏輯語言；

2. 選擇 CSS 的某個子集作為界面描述語言；

3. 自繪制（text/img/div/scroller）+ 原生組件 （input, animation，map, audio, video …）的混合渲染模式。

螞蟻在前端的積累比較多，Cube 選擇擁抱前端，采用 javascript 和 css 是自然的事情。默認(rèn) js 引擎是 quickjs。沒有選擇 v8，有兩個判斷：v8 太重，內(nèi)存開銷和庫加載速度都不理想；Cube 的應(yīng)用場景大概率不需要 v8 提供的 jit 能力。我們額外引入了第三方的 wamr ( https://github.com/bytecodealliance/wasm-micro-runtime ) 作為 webassemby 引擎，且在編譯構(gòu)建工具上支持 javacript 和 assemblyscript 混合開發(fā)。Flutter 開源后受到很多人的追捧，在很多文章和 ppt 上都看到了“Flutter 完全獨立于平臺層的渲染管線的優(yōu)勢”表述，認(rèn)為比 RN 映射實體組件的方式要高級很多。我們不認(rèn)為 Flutter 的渲染管線的性能優(yōu)于操作系統(tǒng)的渲染管線，畢竟設(shè)備和操作系統(tǒng)可以垂直整合，利用一些設(shè)備特性。此外，是否自建渲染管線應(yīng)該取決于業(yè)務(wù)訴求，而不應(yīng)該盲目的追求技術(shù)。

Cube 的自建渲染管線僅限于自繪制標(biāo)簽，如前所述包括 text/img/div/scroller，使用平臺層的 canvas api 直接繪制在系統(tǒng)的 view 上；如果某顆子樹的標(biāo)簽都是自繪制標(biāo)簽，這顆子樹會被“拍平”繪制在一個 view 上。自繪制標(biāo)簽以外的標(biāo)簽都是用映射原生組件的方式，并且封裝了統(tǒng)一的實體組件映射些協(xié)議，提供給開發(fā)人員。目前 Cube 的業(yè)務(wù)場景主要集中在移動端，也簡單嘗試過往 linux/rtos 平臺移植。如果后續(xù)業(yè)務(wù)逐漸擴展到 linux/rtos，我們會考慮進一步完善自繪制，一個是把平臺層的 canvas api 收斂到 skia，另一個是內(nèi)置 layer compositor。

當(dāng)前狀態(tài)

在承接業(yè)務(wù)的過程中，Cube 大致沉淀了 2 種業(yè)務(wù)形態(tài)，分別是 Cube 卡片和 Cube 小程序。

Cube 卡片的作用是給 native 頁面賦予區(qū)域化的動態(tài)能力，提高業(yè)務(wù)迭代和運營效率。錢包接入的卡片也分為兩類，一類是沒有 js 能力的簡單卡片，支持表達式和 vif&vshow 這類構(gòu)建時控制 DOM 樹的操作，追求近似 native 的速度；另一類是具備 js 能力的復(fù)雜卡片，用來支持一些復(fù)雜的業(yè)務(wù)。Cube 卡片在錢包已經(jīng)大規(guī)模應(yīng)用，pv 超過 100 億，接入的場景參考截圖，包括不限于首頁、理財、我的等 tab 頁，以及卡包、出行、支付結(jié)果頁等二級頁面。

Cube 卡片的定位也是優(yōu)先服務(wù)于錢包內(nèi)的一二方業(yè)務(wù)，如果要想提供給三方開發(fā)者區(qū)域動態(tài)化的能力，我們推薦小程序 widget。此外，我們正在著手把 Cube 卡片能力輸出給中小型金融機構(gòu)以及互聯(lián)網(wǎng)公司。

Cube 是作為渲染引擎來引入小程序技術(shù)棧。小程序基礎(chǔ)設(shè)施包括：容器，前端框架，渲染引擎，腳本引擎。容器可以理解成 Appx/渲染引擎/腳本引擎之間的聚合層代碼，提供包管理/JSAPI/安全管控/錢包核心服務(wù)等功能。移動端上小程序默認(rèn)的渲染引擎是 UC，Cube 小程序應(yīng)用很有限。相對于 UC 來說，Cube 在包大小/啟動速度/列表滑動流暢性/內(nèi)存消耗上有一些優(yōu)勢，但是劣勢也非常明顯——Cube 支持的 css 能力不足，且 Cube 的開發(fā)工具不完善。基于此，從 19 年開始 Cube 投入了巨大的人力來擴充 css 能力。Cube 是除瀏覽器內(nèi)核外支持 CSS 較完善的渲染引擎，支持 flex/inline/block 等布局方式，偽類和偽元素，z-index 以及相對和絕對定位層級管理。我們也投入大量的精力試圖建立類似 devtools 功能的工具。

這些努力一定程度上改進了開發(fā)效能，但仍然無法滿足前端同學(xué)的訴求。我們逐漸意識到，在瀏覽器性能不是主要瓶頸的場景下，前端開發(fā)者不大會接受瀏覽器的一個子集。于是，Cube 小程序開始轉(zhuǎn)向 IoT 場景，面向瀏覽器跑不起來，或者，體驗極差的場景。Cube 小程序作為某種應(yīng)用開發(fā)棧，對試圖建立三方開發(fā)者生態(tài)的客戶是有一定的吸引力。目前我們主要的精力在電視大屏端，感興趣的同學(xué)可以在天貓魔盒上體驗 Cube 小程序，也可以在別的盒子以及智能電視上下載酷喵影視（https://acz.youku.com/wow/tvact/act/cibn?spm=a2hpd.20022520.sort.1!2~3~P~A ）。

在卡片和小程序之間，實際上還有一個中間地帶，即單頁。這個頁面可以是全屏，也可以是漂浮在空中的半屏。Cube 早期嘗試過 h5 單頁，面向高頻率營銷場景。它的技術(shù)棧和小程序幾乎完全一樣，不同的是，h5 單頁沒有容器的概念，從服務(wù)端下載到端上的不是小程序包而是嵌入了 Cube 構(gòu)建產(chǎn)物的 h5 頁面。h5 單頁接入過紅包碼業(yè)務(wù)和螞蟻森林的二級頁面，因為維護成本陸續(xù)下線。h5 單頁不成功，并不意味著單頁的需求不存在。近期探索的小程序 widget 其實就屬于單頁的范疇——我們希望 widget 能夠讓服務(wù)前置，承載一定的交互邏輯，同時也限制它的能力，便于管控，適合三方開發(fā)者。

技術(shù)架構(gòu)

Cube 的內(nèi)部有兩個大的模塊，一個是 CubeKit，負(fù)責(zé)對接 js 引擎且封裝平臺差異，也包括了開發(fā)調(diào)試工具。另一個是 CubeCore，是用 c++ 代碼實現(xiàn)的渲染核心邏輯。

對于 Cube 小程序，支持 tinyApp-dsl 子集，移動端上使用 jscore/v8 作為 js 代碼的執(zhí)行引擎，IoT 設(shè)備上使用 quickjs；對于 Cube 卡片，支持基于精簡 vue 的 card-dsl。簡單的卡片直接解析 AST 來渲染頁面，復(fù)雜卡片支持用戶用 js 寫一些簡單邏輯，并且通過 quckjs 來驅(qū)動 dom 樹的更新。

移動端上，Cube 和 Web 小程序共用一個容器代碼。在 IoT 設(shè)備上，我們持續(xù)投入人力到 Appx 和容器的垂直整合中。從目前的數(shù)據(jù)來看，IoT 上的 Cube 小程序相對移動端的 Cube 小程序有不小的基礎(chǔ)性能優(yōu)勢。在電視端上 Cube 小程序的基礎(chǔ)性能數(shù)據(jù)是：包體積 5.5 mb，內(nèi)存消耗 32 mb（淘寶特價板小程序為例），冷啟動耗時3～4s。隨著垂直整合的深入，未來 Cube 小程序的基礎(chǔ)性能會進一步的改善。

質(zhì)量體系這個話題，我放在技術(shù)架構(gòu)里講，原因是它本身是技術(shù)架構(gòu)的一部分。做業(yè)務(wù)開發(fā)，測試人員可以遍歷用戶場景，有 bug 修 bug。基礎(chǔ)軟件所承載的業(yè)務(wù)場景只是無限樣本中很小的一部分，業(yè)務(wù)場景的回歸沒有問題，不能夠保證引擎沒有問題——最壞的情況是問題持續(xù)累積，直到某一天突然爆發(fā)出來。這個時候再想解決問題，已經(jīng)積重難返。所以，基礎(chǔ)軟件的研發(fā)迫切需要某種提前暴露潛在問題的手段，這個手段不可能借助某個測試資源而是研發(fā)團隊自己建設(shè)。

瀏覽器的 WPT 測試用例集合給了一個很好的參考，Cube 也建設(shè)了這樣一套基礎(chǔ)能力樣本集合以及配套的樣本自動化執(zhí)行框架 KITE，投入到版本迭代&代碼提交中。截止目前，我們基本能做到單日粒度的自動巡檢，支撐我們在已有大量的業(yè)務(wù)場景的情況下對引擎做升級和重構(gòu)，下圖是引擎基礎(chǔ)能力巡檢工具的截圖。

開發(fā)工具鏈這個話題，我也放在這里講。Cube 的直接客戶不是用戶，而是業(yè)務(wù)方的開發(fā)同學(xué)。在項目初期就要考慮到工具這塊，比如調(diào)試器的設(shè)計、預(yù)覽容器、日志設(shè)計、低代碼搭建平臺等等。在擴展業(yè)務(wù)過程中，工具鏈某種程度上比 Cube 本身還要重要，畢竟它是客戶的第一印象。我們遇到過前期技術(shù)調(diào)研時，客戶因為工具的不完善而拒絕使用。業(yè)務(wù)接入后，除了能力上，業(yè)務(wù)方也會對工具提供各種要求（在協(xié)助排查問題時也會發(fā)現(xiàn)新的工具需求），貫穿產(chǎn)品的整個生命周期，也是維系客戶粘性的重要工作。隨著 Cube 大規(guī)模應(yīng)用于業(yè)務(wù)后，我們在工具上投入的精力逐漸超過了功能&技術(shù)迭代本身。

回顧&未來規(guī)劃

回顧過去 5 年，Cube 一路跌跌撞撞，中途差點夭折，能走到今天實屬不易。從個人視角，Cube 能活下來依賴“上下堅持”。一方面，上面的決策者堅持投入（19 年及以前幾乎沒有像樣的業(yè)務(wù)價值）；另一方面，一線的同學(xué)堅持做一件事，沒有技術(shù)追求是不可能挺過途中的各種坎坷。我們期待能 Cube 未來應(yīng)用到物聯(lián)網(wǎng)操作系統(tǒng)，畢竟應(yīng)用開發(fā)技術(shù)棧是操作系統(tǒng)的核心技術(shù)之一。

Cube 未來的規(guī)劃繼續(xù)堅持“緊貼業(yè)務(wù)”和“技術(shù)克制”，把產(chǎn)品做好，把開發(fā)者服務(wù)好，把技術(shù)打磨好。重點的發(fā)展方向如下：

1. 鑒于 Cube 卡片可以運行在 32MB 內(nèi)存/400Mhz的 RTOS 設(shè)備上，進一步探索在物聯(lián)網(wǎng)設(shè)備上的落地；

2. 推廣 Cube 小程序在電視大屏端的應(yīng)用和落地，探索商業(yè)模式。

如前所述，后續(xù)更新文章我會更側(cè)重技術(shù)詳解，針對卡片技術(shù)棧、小程序技術(shù)棧、質(zhì)量 KITE&工具 ACT、性能優(yōu)化等進行深入解讀與暢聊。如你對該系列文章感興趣，亦或是對 Cube 感興趣，你也可以在后臺進行留言。

咱們下篇文章再見。