Cube 技術解讀 | 支付寶新一代動態化技術架構與選型綜述

mPaaS 2021-09-18 11:57:09 阅读数:170

cube 支付 新一代 一代

Cube 技術解讀 | 支付寶新一代動態化技術架構與選型綜述_支付寶

如標題所述,筆者將持續更新《Cube 技術解讀》系列文章。本文為Cube系列首篇文章,後續文章筆者會更側重於技術詳解,包括不限於:Cube卡片技術棧一篇,Cube小程序技術棧一篇,質量KITE&工具ACT一篇,性能優化一篇等。

背景

支付寶客戶端的動態化技術經曆三個階段。第一個階段是native+web的hybrid模式,以webview為基石。第二階段是實體組件模式,把html描述的組件和css樣式信息映射到實體組件,並且把實體組件的事件傳遞到js層進行處理。第三階段是實體組件+部分光栅化的hybrid模式,Cube是第三階段的產物。

Cube起源於native頁面的動態化訴求,產品形態錶現於Cube卡片。隨著小程序概念的出現,Cube融入了支付寶小程序技術棧,產品形態為輕量級的支付寶小程序解决方案(相對於使用瀏覽作為核心的web小程序)。這篇文章是一個綜述,也是Cube系列的首篇文章。

技術選型

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

  1. 獨立研發,自主可控。我們沒有選擇基於RN的開源代碼來實現我們的動態化解决方案,也沒有Flutter公布源碼後,切換到Flutter。這麼做是考慮到兩點,第一點,技術棧的演進要掌握在自己手裏,不希望被牽著鼻子走;第二點,開源項目的產品化成本並不低,後期的維護成本也不低;

  2. 服務業務,技術克制。首先,我們沒有足够能力和資源來支撐一個通用技術產品,服務於錢包業務是第一比特的,簡單說就是貼著業務走。其次,我們拒絕只求花裏胡哨的技術demo,把核心能力做好,把產品成熟度做好,考慮拿到業務價值是第一比特的。

基於上面兩個共識,我們的技術選型如下:

  • 選擇Javascript作為邏輯語言;

  • 選擇CSS的某個子集作為界面描述語言;

  • 自繪制(text/img/div/scroller)+ 原生組件 (input, animation,map, audio, video …)的混合渲染模式。

阿裏在前端的積累比較多,Cube選擇擁抱前端,采用javascript和css是自然的事情。默認js引擎是quickjs。沒有選擇v8,有兩個判斷:v8太重,內存開銷和庫加載速度都不理想;Cube的應用場景大概率不需要v8提供的jit能力。我們額外引入了第三方的  wamr 作為webassemby引擎,且在編譯構建工具上支持javacript和assemblyscript混合開發。Flutter開源後受到很多人的追捧,在很多文章和ppt上都看到了“Flutter完全獨立於平臺層的渲染管線的優勢”錶述,認為比RN映射實體組件的方式要高級很多。我們不認為Flutter的渲染管線的性能優於操作系統的渲染管線,畢竟設備和操作系統可以垂直整合,利用一些設備特性。此外,是否自建渲染管線應該取决於業務訴求,而不應該盲目的追求技術。

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

當前狀態

在承接業務的過程中,Cube大致沉澱了2種業務形態,分別是Cube卡片和Cube小程序。

Cube卡片的作用是給native頁面賦予區域化的動態能力,提高業務迭代和運營效率。錢包接入的卡片也分為兩類,一類是沒有js能力的簡單卡片,支持錶達式和vif&vshow這類構建時控制DOM樹的操作,追求近似native的速度;另一類是具備js能力的複雜卡片,用來支持一些複雜的業務。Cube卡片在錢包已經大規模應用,pv超過100億,接入的場景參考截圖,包括不限於首頁、理財、我的等tab頁,以及卡包、出行、支付結果頁等二級頁面。

Cube卡片的定比特也是優先服務於錢包內的一二方業務,如果要想提供給三方開發者區域動態化的能力,我們推薦小程序widget。此外,我們正在著手把Cube卡片能力輸出給中小型金融機構以及互聯網公司。

Cube 技術解讀 | 支付寶新一代動態化技術架構與選型綜述_cube_02

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

這些努力一定程度上改進了開發效能,但仍然無法滿足前端同學的訴求。我們逐漸意識到,在瀏覽器性能不是主要瓶頸的場景下,前端開發者不大會接受瀏覽器的一個子集。於是,Cube小程序開始轉向IoT場景,面向瀏覽器跑不起來,或者,體驗極差的場景。Cube小程序作為某種應用開發棧,對試圖建立三方開發者生態的客戶是有一定的吸引力。目前我們主要的精力在電視大屏端,感興趣的同學可以在天猫魔盒上體驗Cube小程序,也可以在別的盒子以及智能電視上下載[酷喵影視]( https://acz.youku.com/wow/tvact/act/cibn)。

Cube 技術解讀 | 支付寶新一代動態化技術架構與選型綜述_cube_03

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

Cube 技術解讀 | 支付寶新一代動態化技術架構與選型綜述_cube_04

技術架構

Cube的內部有兩個大的模塊,一個是CubeKit,負責對接js引擎且封裝平臺差异,也包括了開發調試工具。另一個是CubeCore,是用c++代碼實現的渲染核心邏輯。

對於Cube小程序,支持tinyApp-dsl子集,移動端上使用jscore/v8作為js代碼的執行引擎,IoT設備上使用quickjs;對於Cube卡片,支持基於精簡vue的card-dsl。簡單的卡片直接解析AST來渲染頁面,複雜卡片支持用戶用js寫一些簡單邏輯,並且通過quckjs來驅動dom樹的更新。

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

Cube 技術解讀 | 支付寶新一代動態化技術架構與選型綜述_mPaaS_05

質量體系這個話題,我放在技術架構裏講,原因是它本身是技術架構的一部分。做業務開發,測試人員可以遍曆用戶場景,有bug修bug。基礎軟件所承載的業務場景只是無限樣本中很小的一部分,業務場景的回歸沒有問題,不能够保證引擎沒有問題——最壞的情况是問題持續累積,直到某一天突然爆發出來。這個時候再想解决問題,已經積重難返。所以,基礎軟件的研發迫切需要某種提前暴露潜在問題的手段,這個手段不可能借助某個測試資源而是研發團隊自己建設。

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

Cube 技術解讀 | 支付寶新一代動態化技術架構與選型綜述_支付寶_06

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

回顧&未來規劃

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

Cube未來的規劃繼續堅持“緊貼業務”和“技術克制”,把產品做好,把開發者服務好,把技術打磨好。重點的發展方向如下:

  1. 鑒於Cube卡片可以運行在32MB內存/400Mhz的RTOS設備上,進一步探索在物聯網設備上的落地;

  2. 推廣Cube小程序在電視大屏端的應用和落地,探索商業模式。

如前所述,後續更新文章我會更側重技術詳解,針對卡片技術棧、小程序技術棧、質量KITE&工具ACT、性能優化等進行深入解讀與暢聊。

Cube 技術棧將於近期上線 mPaaS,作為一項全新能力對外輸出,如你對該系列文章感興趣,亦或是對Cube 技術感興趣,歡迎點擊文末閱讀原文了解 mPaaS 更多相關資訊。

咱們下篇文章再見。


Cube 技術解讀 | 支付寶新一代動態化技術架構與選型綜述_支付寶_07

本文轉載於公眾號「阿裏巴巴移動技術」, 點擊這裏,了解 mPaaS 更多相關資訊。

版权声明:本文为[mPaaS]所创,转载请带上原文链接,感谢。 https://gsmany.com/2021/09/20210918115708790p.html