作者：字符串

“如題目所述，筆者將繼續(xù)更新《Cube 技術(shù)解讀》系列文章。

本文為Cube系列首篇文章，后續(xù)文章筆者會更側(cè)重于技術(shù)詳解，包括不限于：Cube卡片技術(shù)棧一篇，Cube小程序技術(shù)棧一篇，質(zhì)量KITE&工具ACT一篇，性能優(yōu)化一篇等，感謝大家關(guān)注【阿里巴巴移動技術(shù)】?！?p>

背景

支付寶客戶端的動態(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的準確誕生時間很難確定，大致在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是自然的事情。沒有選擇v8，有兩個判斷：v8太重，內(nèi)存速度和初始化速度都不理想；Cube的應(yīng)用場景大概率不需要v8提供的jit能力。我們額外引入了第三方的wamr ( ) 作為webassemby引擎，且在編譯構(gòu)建工具上支持javacript和assemblyscript混合開發(fā)。Flutter開源后受到很多人的追捧，在很多文章和ppt上都看到了“Flutter完全獨立于平臺層的渲染管線的優(yōu)勢”表述，認為比RN映射實體組件的方式要高級很多。我們不認為Flutter的渲染管線的性能優(yōu)于操作系統(tǒng)的渲染管線，畢竟設(shè)備和操作系統(tǒng)可以垂直整合，利用一些設(shè)備特性。此外，是否自建渲染管線應(yīng)該取決于業(yè)務(wù)訴求，而不應(yīng)該盲目的追求技術(shù)。

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

當前狀態(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ù)等功能。移動端上小程序默認的渲染引擎是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小程序，也可以在別的盒子以及智能電視上下載酷喵影視（!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，負責對接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.5mb，內(nèi)存消耗32mb（淘寶特價板小程序為例），冷啟動耗時3～4s。隨著垂直整合的深入，未來Cube小程序的基礎(chǔ)性能會進一步的改善。

質(zhì)量體系這個話題，我放在技術(shù)架構(gòu)里講，原因是它本身是技術(shù)架構(gòu)的一部分。做業(yè)務(wù)開發(fā)，測試人員可以遍歷用戶場景，有bug修bug?；A(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感興趣，你也可以持續(xù)關(guān)注我們。

咱們下篇文章再見。

關(guān)注我們，每周 3 篇移動干貨&實踐給你思考！