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

語言: CN / TW / HK
時間 2022-06-20 20:15:13
主題:

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

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更詳細的介紹，可以期待和閱讀本系列文章的第二篇。

列表容器

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

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

```` 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'}" >

「」