簡介：魔方卡片（Cube），讓 App 首頁實現(xiàn)敏捷更新。

CodeHub#7 正式落幕，來自螞蟻集團的技術(shù)專家「京君」與掘金社區(qū)的開發(fā)者們分享了「支付寶」全新的卡片技術(shù)棧——魔方卡片（Cube）。

京君圍繞 Cube 技術(shù)的架構(gòu)邏輯，闡述其渲染和生產(chǎn)過程，并指導開發(fā)者完成初階的技術(shù)調(diào)試。

?點擊播放，可觀看 CodeHub#7 完整回放；公眾號mPaaS后臺回復“Cube”可獲取講師完整PPT。

動態(tài)卡片的背景

從 Windows 時代開始，應用程序圖標就成了用戶（流量）的主入口，并且一直持續(xù)到移動端時代。圖標即入口的方式，缺點是不直觀，最少需要一次點擊后才能接觸到想要的信息。在此背景下，iOS系統(tǒng)和部分Android系統(tǒng)實現(xiàn)了把內(nèi)容和服務前置的卡片，如下圖所示：

此外，鴻蒙系統(tǒng)也提出了類似的卡片場景，作為某種流量入口。實際上，在應用內(nèi)部的卡片作為內(nèi)容展示以及服務入口的場景則更為普遍，比如支付寶首頁和招行銀行的理財頁面，其中每個小矩形都是一個卡片。對于運營來說，卡片樣式和內(nèi)容可以隨時配置，不用等待應用版本升級，也是某種剛需。

魔方卡片（Cube）概要

魔方卡片（Cube）是螞蟻集團內(nèi)部自研的一套跨平臺動態(tài)化卡片解決方案，是服務于應用頁面內(nèi)的區(qū)域動態(tài)化技術(shù)，面向內(nèi)容運營，幫助產(chǎn)品技術(shù)提高開發(fā)效率和運營效率。每一個魔方卡片（Cube）獨立嵌在原生頁面內(nèi)的一個區(qū)域，區(qū)域內(nèi)容通過卡片模版進行展示。

這里展開講下高性能。魔方卡片（Cube）追求的是接近native原生體驗。我們定義了兩個維度:

一個是極致的性能。在Cube小程序能力的基礎上，我們?nèi)サ袅艘恍碗s的css能力，例如偽類偽元素、inline/block等，同時也對js的能力做了限制（魔方卡片使用quickjs作為腳本引擎）。此外，我們還對quickjs做了一些優(yōu)化，包括不限于離線atom編譯優(yōu)化，異步gc優(yōu)化等。我們也引入了wamr作為quickjs的“協(xié)處理器”，支持用戶使用javascript和assemblyscript混合開發(fā)。這樣用戶可以用assemblyscript一些熱點函數(shù)或者模塊。

另一個維度是極致的內(nèi)存。在信息瀑布場景無限下拉，魔方卡片的內(nèi)存增長接近Native卡片。我們對卡片的能力做了比較精細分級，通過在開發(fā)時配置，減小運行時的內(nèi)存消耗。下圖展示了一個簡單卡片，如圖所示魔方卡片的工程目錄，以及錢包某個卡片的真實代碼和運行效果。

Cube卡片的生產(chǎn)&工作流程

• 研發(fā)期
• • 本地開發(fā)

魔方卡片（Cube）配套獨立的開發(fā)工具，支持卡片的編譯、日志輸出、實時預覽等功能，vue作為當前開發(fā)模版的dsl語言，支持js、css編輯卡片樣式。

• • 卡片管理

卡片本地開發(fā)完成后，通過卡片管理后臺將卡片編譯產(chǎn)物上傳發(fā)布，可以對卡片進行版本管理，卡片發(fā)布后就可以在客戶端進行卡片的動態(tài)更新。

• 運行期

為了方便端上業(yè)務接入魔方卡片，我們引入了一個魔方卡片容器（CardSDK）的概念。CardSDK把一些和業(yè)務層/服務端聯(lián)系緊密的，且通用能力做了一些封裝。例如我們通過CubeCardSdk從服務端拉取卡片和業(yè)務數(shù)據(jù)。此外CardSDK也負責常用的JSAPI、第三方組件的接入。這樣魔方卡片能夠更專注于卡片產(chǎn)品本身。

核心系統(tǒng)架構(gòu)

魔方卡片（Cube）的系統(tǒng)架構(gòu)主要包括JSEngine、CardEngine、RenderEngine和Platform幾部分，絕大部分代碼都是C++實現(xiàn)。

• JSEngine

主要負責卡片js邏輯執(zhí)行和卡片數(shù)據(jù)變化監(jiān)聽，從而支持開發(fā)者在卡片內(nèi)部寫一些業(yè)務邏輯能力實現(xiàn)卡片內(nèi)容和樣式的動態(tài)變化。

因為卡片場景對性能要求較高，綜合包大小和性能等方面考慮，我們選擇了quickjs作為我們的js基礎引擎庫，同時實現(xiàn)了一個非常小的js響應式框架（JSFM），用來支持卡片內(nèi)的邏輯代碼能力。

• CardEngine

主要負責卡片數(shù)據(jù)的解析和綁定、卡片邏輯渲染、構(gòu)建DOM指令、JSAPI管理、JSBinding、Native事件通信等。

卡片DOM樹的初始化構(gòu)建過程，我們并沒有把它放在js運行時，而是在卡片實例初始化鏈路中直接通過C++進行指令生成和樹構(gòu)建，一方面是為了保持js框架更小更快，另一方面C++的運行效率更高。

• RenderEngine

后端渲染底座，負責卡片布局計算、樣式解析、Layer計算、自繪制組件、同層渲染、光柵化上屏等過程，以及手勢、動效等交互效果。

• Platform

平臺相關(guān)接口，包括原子view封裝、Canvas API、三方組件擴展協(xié)議、動畫api等。

線程模型和數(shù)據(jù)模型

線程模型

魔方卡片（Cube）生命周期內(nèi)的主要線程包括業(yè)務線程和引擎線程，業(yè)務線程是卡片數(shù)據(jù)的初始化階段由業(yè)務發(fā)起執(zhí)行，是卡片生命周期的beforeCreate階段。引擎線程是所有卡片生命周期運行階段的共有線程，主要包括Bridge線程、Render線程、Paint線程和UI主線程。

• Bridge線程

js運行時線程，也是Dom節(jié)點數(shù)據(jù)查詢和處理線程，因為基于魔方卡片小、快的定位，js邏輯只是卡片一個輔助能力，不具備過于復雜業(yè)務邏輯能力，所以Bridge線程相對較輕，并設計為單線程模式。

• Render線程

渲染相關(guān)數(shù)據(jù)計算線程，包括渲染樹構(gòu)建、節(jié)點層級計算、Layer分層繪制計算、手勢數(shù)據(jù)計算以及渲染任務構(gòu)建，Render過程主要涉及樹的遞歸計算過程，相對渲染過程耗時很短， 設計為單線程模式。

• Paint線程

繪制線程，執(zhí)行卡片節(jié)點分層繪制及光柵化任務。Paint線程并不是一個固定的線程，根據(jù)當前任務模型，Paint線程可能是主線程，也可能是一個線程池里的子線程；在同步渲染模式下，Paint線程直接是主線程；而在異步渲染模式下，通過一個線程池來實現(xiàn)Paint任務的并發(fā)渲染，提高渲染效率，例如在列表滑動場景。

• UI主線程

UI操作主線程，即為目前的平臺線程，主要包括手勢識別、UI上屏和三方擴展組件的數(shù)據(jù)更新等。

除了以上涉及的主要線程外，還有埋點和監(jiān)控相關(guān)的playground后臺線程，整體優(yōu)先級比較低。整體的線程模型設計，最大限度減少UI主線程壓力，提高卡片并發(fā)渲染效率。但目前還有一些不足，包括UI線程切換頻繁、Bridge線程越來越重等，后面會繼續(xù)優(yōu)化線程模型。

數(shù)據(jù)模型

和線程模型對應的數(shù)據(jù)模型主要包括三棵樹：NodeTree、RenderTree、LayerTree，除此之外，還存在一個臨時的PaintTree；

• NodeTree

卡片原始節(jié)點樹，對應前端的Dom樹，引擎會根據(jù)NodeTree做樣式解析和布局計算；

• RenderTree

渲染數(shù)據(jù)樹，這是一顆變形樹，很多情況下它的樹層級結(jié)構(gòu)和NodeTree是一樣的，其實當初在設計定義引擎數(shù)據(jù)模型的時候，我們討論過到底要不要這棵樹，有沒有必要存在這樣一顆和NodeTree層級一樣的樹，最終我們還是保留了，原因是這棵樹可以比較靈活的調(diào)整樹關(guān)系，如果把卡片分為布局階段和渲染階段，那么這顆樹就是渲染階段的源樹。

事實證明我們的決定是正確的， 我們后續(xù)支持的zindex/static等能力，都是因為這棵樹的存在可以在引擎層很好的去支持， 而不用在平臺層去模擬實現(xiàn)這種層級變更能力從而導致很有限的場景支持，包括以后我們做渲染快照技術(shù)也可以從這顆樹去考慮。

• LayerTree

LayerTree樹，顧名思義就是一個分層樹，在RenderTree基礎上對節(jié)點進行分層，同一層的節(jié)點在同一個渲染任務管線內(nèi)做繪制光柵化，不同層之間相互獨立，可以并發(fā)渲染。

• PaintTree

PaintTree是一個臨時樹，其實嚴格的說是一個拷貝樹，是通過RenderTree拷貝一個子樹，每次發(fā)生渲染時臨時生成，當然也會做些節(jié)點優(yōu)化處理，例如被完全蓋住的節(jié)點會被優(yōu)化調(diào)，避免重復渲染。每一個layer上存在一個PaintTree，通過PaintTree進行節(jié)點繪制生成光柵化指令或位圖。

高性能列表渲染

對于列表內(nèi)使用卡片的場景，主要考慮的是卡頓影響，尤其是中低端機設備。魔方卡片（Cube）支持異步渲染，所以在列表場景下可以很流暢，同時因為支持多線程并發(fā)能力，可以多張卡片并發(fā)渲染，所以在異步渲染條件下也不會有明顯的白屏效果。

Native技術(shù)優(yōu)化

我們期望卡片服務于頁面內(nèi)區(qū)域化內(nèi)容動態(tài)展現(xiàn)和簡單業(yè)務邏輯，更多的是面向移動端開發(fā)者。即使我們使用的卡片DSL語言描述是前端語言，我們也希望能夠?qū)SS的使用做約束、支持有限的CSS能力，但同時也希望盡可能覆蓋到一些開發(fā)者常用的CSS能力。

所以我們針對CSS能力做了一個專項工作，和前端團隊技術(shù)同學一起做了魔方卡片（Cube）CSS能力規(guī)范，對CSS能力做了約束限制。即便如此，在Native渲染引擎下，想非常好的去支持這些能力，也是有很多困難，包括zindex的支持、overflow等，因此我們也基于一些依賴的平臺能力也做了優(yōu)化處理。

Layer容器

我們引入Layer容器概念，前面介紹數(shù)據(jù)模型時，提到了LayerTree，每一個Layer節(jié)點是一個獨立的渲染容器，由平臺View作為Layer容器來渲染其他虛擬節(jié)點。如果按照常規(guī)的做法是一個View對應一個渲染容器，我們使用兩個View組合為Layer容器（iOS使用CALayer），將內(nèi)容層和邏輯層分離，這樣做的好處很多，例如layer節(jié)點的shadow繪制限制裁剪問題、內(nèi)容層的畫布切割優(yōu)化等。

手勢改造

手勢的優(yōu)化改造主要為了解決平臺系統(tǒng)手勢分發(fā)能力的限制，不管是Android平臺還是iOS平臺，系統(tǒng)對手勢的分發(fā)處理都有一些限制，例如兄弟節(jié)點不能分發(fā)事件（iOS）、超過父節(jié)點區(qū)域無法接收事件（影響overflow能力）等，所以需要對手勢進行改造。

因為卡片渲染支持三方組件擴展，為了不影響擴展組件的事件響應，我們基于Layer容器接管改造系統(tǒng)手勢行為，內(nèi)部進行容器節(jié)點的手勢分發(fā)管理，而對于存在三方組件混合渲染的場景，Layer容器和三方組件之間的手勢分發(fā)保持系統(tǒng)行為。

光柵化

魔方卡片（Cube）渲染過程包括指令渲染和位圖渲染兩種渲染模式，這兩種模式會在不同場景條件下切換，用來優(yōu)化不同場景下性能，例如幀率和內(nèi)存。位圖渲染在Android上相對比較復雜。默認是用Bitmap作為離線渲染的緩存，缺點是引入一次額外cpu/gpu內(nèi)存拷貝并且無法充分利用GPU資源，優(yōu)勢是兼容性好。我們嘗試過使用textureview作為離線渲染緩沖，發(fā)現(xiàn)6.0以下設備存在嚴重的兼容性問題，而且不同設備之間的穩(wěn)定性差別巨大。

同時光柵化能力依賴平臺系統(tǒng)的Canvas API，有些高階方法會涉及硬件加速的限制，包括shadow api以及系統(tǒng)對glRender buffer的限制(Android平臺)，我們也對大畫布場景做了視圖切割分段渲染來保證渲染性能。我們同時也在著手用Skia Canvas api替代平臺層的Canvas API。

同層渲染

魔方卡片（Cube）把三方組件當作獨立一層layer單獨進行數(shù)據(jù)更新，可以非常方便高效的接入擴展的三方組件。基于系統(tǒng)的UI能力，使擴展組件在卡片內(nèi)天生統(tǒng)一渲染。同時支持組件在不同卡片上的復用。在實際的業(yè)務場景中，同層渲染也帶來了很多額外的問題。諸如地圖/視頻/動畫等組件，一般會伴隨著較大的性能內(nèi)存開銷。這些開銷對卡片的渲染會有負面影響，尤其在列表滾動時。對于地圖/視頻組件，我們配合組件提供方case by case的解決問題，并且試圖在卡片上線時設置卡點。對于動畫組件，Cube持續(xù)的在擴展屬性動畫/幀動畫能力，并且內(nèi)置canvas能力。

魔方卡片（Cube）的現(xiàn)狀和規(guī)劃

目前魔方卡片（Cube）已經(jīng)服務「支付寶」的首頁、證券（股票）、卡包、出行等20+的業(yè)務場景，日pv超過100億。在未來相當長的一段時間內(nèi)，「支付寶」內(nèi)部的業(yè)務場景，將逐步把存量的native卡片和h5卡片Cube化。

因此，我們一方面會持續(xù)把開發(fā)者體驗做好，諸如開發(fā)調(diào)試工具鏈條；另一方面我們也將持續(xù)的優(yōu)化基礎性能，諸如追求更小的包體積，更低的內(nèi)存等。

同時，魔方卡片（Cube）Beta 已上線 mPaaS 供廣大移動開發(fā)者使用，公測期間，登錄 mPaaS 控制臺，立即贈送十個卡片模版免費使用。> > 點擊這里 < <體驗魔方卡片。

卡片未來規(guī)劃的另一個方向是物聯(lián)網(wǎng)設備（例如RTOS）的應用開發(fā)棧。準確說不是魔方卡片，而是卡片和小程序的某種中間形態(tài)。

物聯(lián)網(wǎng)設備的界面一般比較簡單，近似卡片；但是又需要多個“卡片”之間的路由能力，更接近于應用的形態(tài)。這樣一個混合形態(tài)既能保留魔方卡片（Cube）在內(nèi)存/性能/包體積上的優(yōu)勢，又能滿足物聯(lián)網(wǎng)設備應用開發(fā)的訴求。

根據(jù)我們的調(diào)研，大部分RTOS應用開發(fā)環(huán)境還是停留在傳統(tǒng)的C語言，效能和動態(tài)性都不理想。因此對于開發(fā)者來說，Cube 也許是一個不錯的選擇。

推薦閱讀：《Cube 技術(shù)解讀 | 支付寶新一代動態(tài)化技術(shù)架構(gòu)與選型綜述》

---

> > 點擊這里 < <體驗魔方卡片。

原文鏈接：https://developer.aliyun.com/article/801630?

版權(quán)聲明：本文內(nèi)容由阿里云實名注冊用戶自發(fā)貢獻，版權(quán)歸原作者所有，阿里云開發(fā)者社區(qū)不擁有其著作權(quán)，亦不承擔相應法律責任。具體規(guī)則請查看《阿里云開發(fā)者社區(qū)用戶服務協(xié)議》和《阿里云開發(fā)者社區(qū)知識產(chǎn)權(quán)保護指引》。如果您發(fā)現(xiàn)本社區(qū)中有涉嫌抄襲的內(nèi)容，填寫侵權(quán)投訴表單進行舉報，一經(jīng)查實，本社區(qū)將立刻刪除涉嫌侵權(quán)內(nèi)容。

總結(jié)

以上是生活随笔為你收集整理的Cube 技术解读 | 详解「支付宝」全新的卡片技术栈的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。