淘寶Native研發模式的演進與思考 | DX研發模式

語言: CN / TW / HK

DX全稱DinamicX,目前是在淘寶乃至整個阿里集團內廣泛使用的Native動態化方案,核 心優勢是性能和穩定性。過去幾年一直有其他淘寶/集團的外部文章中有涉及 到DX ,但DX一直沒有對外做過完整介紹,對外界來説這兩個字母頗有些神祕色彩。本 系列文章《DX研發模式》我們就將拉下它神祕的面紗,看看過去兩年 DX 在做什麼。

本文主要闡述 DX 的發展歷程以及近兩年的重點建設事項,喜歡看視頻和PPT的同學,可以在下方公眾號內回覆「 DX 」,觀看去年末筆者的分享“淘寶Native研發模式的演進”。

《DX研發模式》系列文章預吿如下,歡迎持續關注:

  1. 本文:《淘寶Native研發模式的演進與思考》

  2. 5月26日:《列表容器&事件鏈如何助力業務快速迭代》

  3. 5月31日:《如何持續突破性能表現?》

  4. 6月2日:《從0到1,IDE如何提升端側研發效率?》

DX的起源與發展

DX是從首頁為解決業務兩端一致性和動態性的問題孵化而來,後經過若干次升級和迭代,逐步完成了從首頁動態化方案——基礎鏈路動態化方案——集團共建動態化方案——集團移動小組標準Native研發模式的多級跳躍。隨着接入的業務和開發者越來越多、使用場景越來越複雜和多樣,技術範疇也從端側SDK延展到動態化技術體系,再到Native研發模式。

淘寶的技術選型

這可能是當前這個星球上最複雜App的淘寶技術選型標準,我們把淘寶所有的業務分為三個大類:核心域、導購域和開放域。不同場景對於性能體驗、穩定性、交付效率都有不同的訴求,這裏沒有“技術銀彈”,只有適合目標場景的最佳方案。

過去兩年我們面臨的挑戰是什麼

作為核心域標準技術選型的DX,過去幾年的挑戰是什麼呢?

首先來看一下大的業務背景:

  1. 業務競對加劇,集團從航母戰略升級為App矩陣戰略,對交付量和效都有了更高的要求;

  2. 隨着直播/短視頻/AR/3D技術的發展與普及,移動端邁入沉浸式/富交互體驗,Native技術棧的優勢更加明顯;

  3. 淘寶的購物效率越來越高,用户訪問時長/頻率降低,大部分購買決策發生在淘外,淘寶逐漸淪為下單/比價工具,而當內容場掌握了大量入口流量和用户時長後,開始下場自己閉環做電商成交,曾經的引流渠道變成直接競爭對手,淘寶也將面臨“無源之水、無本之木”的困境,所以淘系近年來一直在打造自己的內容/社區,讓更多的消費購前決策發生在淘系。

這三大業務背景深刻地影響着接入DX的每個業務以及潛在的新業務,所以過去兩年,我們的工作主要圍繞研發模式升級和體驗升級來進行。

首先來説研發模式升級,原先主要有兩個問題:

1、DX自身技術體系不完整,在19年之前,DX只能説是一個客户端動態化方案,包含一個端側SDK和一個組件平台,但隨着接入的新業務越來越多,DX自身技術體系不完整的瓶頸愈發明顯,大量新業務需要重複建設端側容器、搭建平台等基礎設施,導致接入成本高、收益低,而各業務自建的容器和平台,又難以沉澱和複用,進一步加劇了後續技術拉通的難度。

2、研發模式過於單一,隨着沉浸式體驗和富交互體驗的鋪開,很多業務吿別了過去重展示輕交互的模式,往中度交互開始進行體驗升級,尤其以微淘拆分出的逛逛和訂閲為代表的類內容場,需要以更沉浸式的瀏覽/互動體驗來吸引用户更多的停留和內容消費,而我們過去基於搭建的方式並不能很好地對此類場景進行研發支撐。

再來是體驗升級,我們雖然並不能決定具體業務場景的視覺交互和體驗設計,但面向優秀的體驗,我們可以做幾個事情:

  1. 提供開箱即用的體驗優秀的標準化組件,如日曆/富文本/複雜嵌套容器/Page Indicator等組件,極大降低體驗精細化帶來的適配成本,如Dark Mode/銀髮版字體自動放大適配等;

  2. 在富媒體/端智能的快速發展,以及下沉市場中低端設備的增加的背景下,持續優化DX渲染管線的性能水位,提升廣大業務場景的基礎瀏覽和交互體驗;

  3. 提供更完善的性能工具,幫助開發者在面對相對“黑盒”的模版性能問題時,可以做到早發現、可排查、可優化。

關於ProCode和LowCode的思考

在我們承接新訂閲和逛逛的新場景時發現,在這種內容型交互類場景,有着豐富的交互、聯動與轉場,DX過去動態邏輯表達力不足和基於模塊搭建的LowCode研發模式無法支撐其進行高效研發,核心矛盾是動態邏輯、複雜容器及內部聯動、多人並行開發與模塊引用,於是經過一系列的討論和思考後,有了下面這張圖:

基於在新場景下面臨的問題,我們決定把研發模式進行分層,定製性強/動態邏輯要求高的業務場景,用ProCode模式來開發,通過強大專業的DX IDE+Git來進行工程化多人協作開發,可以進行UI和動態邏輯的調試(事件鏈),而定製性弱/複用性高的業務場景,用LowCode模式來承接,通過可視化搭建平台來拖拽生成視圖和佈局,配置相應數據源和規則。同時,不斷抽象沉澱組件庫/能力庫,使越來越多的交互/功能/佈局可以通過可視化方式來拖拽生成。

我們暢想的未來是,當業務同學有一個新的業務想法時,可以通過LowCode模式自行搭建與配置,在線上圈選小部分用户進行灰度驗證,在驗證產品方向正確後,再投入更多的專業技術人員來做進一步的產品定製和升級,來產生更大的業務效果。

ProCode “三駕馬車”

要讓 ProCode 模式成型,必須要解決的是動態邏輯、複雜容器和相應的研發支撐問題,所以就有了 ProCode的“三駕馬車”:IDE、列表容器、事件鏈。

IDE

第一是IDE,這裏補充些背景信息,在做IDE之前,DX有個模版平台,主要來承載模版的開發/調試/發佈工作,那我們為什麼要再做一個IDE呢?

首先,嚴格來説,原來DX平台上的不叫IDE,只能説是Editor,從關係上來看,IDE包含Editor,借用一張VSCode的圖來説明兩者的差異:

其次,原來DX平台上的Web Editor(Monaco)雖然也支持大部分LSP API,但沒有工程/項目體系、文件系統、代碼上下文理解、調試等能力,且受限於瀏覽器環境,而IDE運行於本地環境,有豐富的擴展能力和插件,可以提供完整的研發生命週期支持。

所以,在ProCode模式下,我們的技術選型基於Katian IDE(兼容VSCode API),來得到更多的視圖擴展能力,未來還能通過靈活的部署方式(遠程開發、雲端部署),實現更高效/快速的研發與協作。

目前DX IDE已經接入了包括淘寶在內的集團多個重要業務,這些開發者使用IDE後研發效率有了大幅的提升,尤其是多人協作與調試效率有了量級的提升。關於DX IDE更詳細的介紹,可以期待和閲讀6月2日上線的系列文章《

從0到1,IDE如何提升端側研發效率?|  DX研發模式

列表容器

第二是列表容器,過去基於搭建的容器有個特徵,容器/頁面佈局由數據協議來描述,即數據佈局一體,這在簡單頁面結構(如單列表頁面)場景下運轉良好,配合搭建能較快地配置出樓層,通過協議來驅動端側渲染,服務端也不需要過多感知業務結構(默認就是單列表佈局)。但在複雜頁面結構(如多層多Tab嵌套容器),尤其還有複雜交互的情況下,就會讓整個數據結構變得過於複雜,同時也增加數據協議的paylaod,而頁面佈局的變化頻率遠小於業務數據。

在這種場景下,把兩者耦合在一起,明顯是不合適的,於是,出於職責單一和“動靜分離”的原則,我們進行了重新的思考和設計,在模版XML中統一描述佈局(包括容器/頁面佈局),讓數據迴歸純粹的數據結構,與此同時,我們也在DX中內置了新的功能強大的列表容器,寫起來就像下面這樣:

<RecyclerLayout
userId="recycler"
width="match_parent"
height="match_parent"
dataSource="@data{itemList}"
backgroundColor="@triple{@getEngineStorage{backgroundColor}, @getEngineStorage{backgroundColor}, '#ffffff'}"
columnCount="2"
columnGap="4"
isOpenPullToRefresh="True"
refreshPullText="下拉即可刷新..."
refreshReleaseText="釋放即可刷新..."
refreshLoadingText="加載中..."
loadMoreFailText="加載失敗"
loadMoreLoadingText="加載中..."
loadMoreNoMoreDataText="到底了"
onPullToRefresh="@dxEventHandler{'refreshTest'}"
onEndReached="@dxEventHandler{'loadMoreTest'}"
>
<Template
if="@subdata{span}"
sticky="True"
colspan="2"
name="aa"
>
<TextView
width="match_parent"
height="100"
text="@data{text}"
textSize="15"
backgroundColor="#FFFF55"
borderColor="#FF9911"
borderWidth="2"
/>


</Template>
<Template
if="@subdata{recyclerInsertItems}"
name="recycler_sub_template1"
version="2"
/>
</RecyclerLayout>

目前列表容器已覆蓋了多個淘寶和集團內重要業務場景,支持了嵌套容器/聯動框架/動態Template/Slot等能力,下一年我們也會推廣到更多的業務。

事件鏈

第三是事件鏈,過去DX只支持UI的動態化,有限的邏輯控制只能通過表達式來實現,其他的邏輯變更都依賴發版,而隨着業務對發佈上線的時效要求越來越高,邏輯動態化的訴求也愈發強烈。於是,面對這個訴求,我們經過反覆的討論和思考,綜合考慮了蘋果合規、性能、穩定性、開發效率,提供了事件鏈的方案。

在事件鏈方案中,開發者在XML對應的eventchain.json中使用原子能力和表達式進行邏輯組裝,在研發期IDE提供了事件鏈JSON的智能感知能力(包括補全/提示/跳轉/格式化/摺疊/高亮等),可以通過事件鏈回放功能,來圖形化顯示事件鏈執行的流程以及每個原子能力的出入參和上下文,來便捷問題的排查。開發完成後,在編譯階段,DX編譯服務會把該JSON編譯成二進制,與模版二進制一起下發,確保性能和一致性,在端側有事件鏈引擎來負責二進制的解析,以及原子能力的調度。

想了解列表容器和事件鏈更多的技術細節,可以期待和閲讀本週四(5.26)上線的系列文章《列表容器&事件鏈如何助力業務快速迭代 |DX研發模式 》。

關於性能優化的思考和實踐

過去兩年,DX的能力越來越強大,功能越來越豐富(動畫動態化、事件鏈、複雜嵌套容器、直播/視頻組件、3D組件等),那DX一直以來的性能優勢,會不會有所影響或下降?我們又是如何在不斷加入新功能的同時,做到性能不退反升呢?面對越來越複雜的模版,如何幫助開發者在面臨性能問題時,有排查和優化的抓手,而不是一無所措呢?

這就要説下DX的渲染管線,如果説Flutter是接管整個系統渲染的革命派,那DX就是基於原生系統渲染的改良派。DX的主要設計思路是基於Platform First來改良系統原生渲染管線/機制中的性能瓶頸和問題,並做到兩端統一。

從DX管線各階段的耗時分佈來看,主要大頭在load和render,所以我們主要通過異步化管線來解決load的耗時問題,通過異步繪製和高性能組件來解決render的耗時問題,通過計算資源管控來儘量保障資源的合理分配。

異步化管線和異步繪製,主要是讓更多工作能夠在子線程執行,或者並行調度,降低主線程的負擔,合理利用多核計算資源,在DX列表容器中,我們內置了該能力,可以做到開箱即用,而在業務容器中,需要業務方按照我們建議的時機/業務認為合適的時機來調用相應API,來獲得異步化的調度。

高性能組件方面,我們主要優化了圖片組件和自研了富文本組件,尤其是富文本組件,我們基於系統TextKit/TextLayout實現了自測自繪,提供了TextSpan/ImageSpan/展開收起等能力,相比原生組件,內存降低(iOS 70% Android 8%),性能提升(iOS 20% Android 10%)。

計算資源管控方面,我們主要設計和實現了離屏計算資源管控框架,用來實現視頻/直播/動圖的播控問題,且提供了規則配置能力,在多視頻情況下,iOS CPU佔用率降低66%/Android降低25%,目前在淘寶的一些重要信息流場景已上線。

性能工具方面,過去我們主要是在運行時進行各種底層優化和編譯期的性能預警提示,在遇到模版性能問題時,通常需要業務方和DX同學分別打Log來看時間的消耗和定位問題的所在,雙方都耗時耗力。會出現這種情況,一部分原因是DX與Native的結合度較高,一次渲染過程中有大量的DX內部代碼和業務方自定義代碼交織在一起,導致無法快速精準定位問題所在;另一部分原因是DX的渲染過程對業務方來説相對黑盒,業務方也沒有進行排查和優化的有效抓手。

為了擺脱這種場景,我們要讓整個模版渲染過程在開發階段進行一定的白盒化,以可視化圖形方式展現模版各階段的渲染耗時及其歸屬(DX內部還是業務方自定義部分,具體到是哪個Widget的什麼階段/DataParser/EventHandler),同時通過不斷累積的常見性能問題,進行模版自動分析並提供一定的優化建議。

關於性能優化的思考和實踐,可以期待和閲讀5月31日上線的系列文章《如何持續突破性能表現?|  DX研發模式 》。

技術大圖

總結一下,這是目前DX技術體系的大圖,研發支撐層,我們通過IDE和平台來滿足ProCode和LowCode兩種生產模式的訴求,核心運行時層,我們不斷增強容器/組件/佈局等視圖能力的同時,引入一定的動態邏輯能力,通過共建不斷沉澱原子能力庫,業務框架層,我們也與淘寶內團隊合作,把複雜狀態管理、流程編排等能力引入DX技術生態中,業務可按需接入。

未來展望

從技術演進上,我們認為DX的下一階段,要實現三化:

  • 標準化,目前DX的DSL偏向私有標準,開發門檻較高,不利於擴大開發者羣體,接下來我們要向客户端行業標準靠齊,吸引更多的開發者;

  • 現代化,目前DX通過命令式來描述UI,而行業已經向聲明式邁進,從技術演進路線上,我們也要擁抱聲明式,進一步提升開發體驗和效率,此外,研發支撐方面,我們這個財年從0到1打造了DX IDE,在本地進行安裝和運行,已經能較大程度提升複雜頁面/模版的研發效率,但我們不會停下研發提效的腳步,接下來還要嘗試通過雲端部署的方式,達到免安裝/開箱即用/工作空間共享等,進一步提升研發和協作效率;

  • 一體化,目前我們已經通過DX IDE實現了部分的工程一體化,未來為了進一步提升前後端協作效率,也為了把Serverless打造成客户端的基礎能力之一,我們要實現端雲一體,在一個集成研發環境中,以同一個技術棧,同時開發端側和雲側代碼,簡化端雲遠程調度開發成本,發佈期通過編譯技術部署到不同的目標,提升前後端協作效率和端側技術方案自主性。

當然要實現這些,還有大量的技術挑戰在前方等待着我們,歡迎有興趣的同學和我們進行技術交流,或者加入我們(聯繫郵箱:[email protected]),大家攜手一起創造客户端的未來!

關注我們,阿里前沿移動乾貨&實踐給你思考!