京東APP OpenHarmony 化的跨端開發探索
背景
2022.7.27日,在《開放原子全球開源峰會》-OpenHarmony分論壇上,京東作為分享嘉賓,為大家帶來了精彩的分享。京東積極擁抱 OpenHarmony,並參與 OpenHarmony 應用生態建設,分享中介紹了京東App適配 OpenHarmony 的探索,重點呈現了京東跨平臺方案Aotu Taro 和 JD MCube 在 OpenHarmony 上的實踐。
其中Aotu Taro 框架是業界領先的跨端跨框架解決方案,並在 OpenHarmony 開源專案組主導成立了 CrossPlatformUI-SIG,通過Aotu Taro 可以很便捷地開發、除錯、釋出鴻蒙及 OpenHarmony 應用,幫助開發人員快速構建鴻蒙及 OpenHarmony 應用。
JD MCube 框架是京東自研的原生動態化框架,覆蓋了京東app黃金流程業務,並賦能集團其他app,目前正在聯合京東集團內部力量進行共建,暫未對外開源。
精彩回顧
京東App技術架構總監蓋旭天為大家現場講解京東App適配複雜度和在OpenHarmony平臺的適配進展
由於論壇上分享時間有限,很多細節無法展現,Aotu Taro目前是開源專案,歡迎大家到社群參與共建。應眾多聽眾要求,這篇文章會細緻的向大家介紹 暫未開源的JD MCube 框架在 OpenHarmony 的適配進展。
01京東App 適配現狀分析
我們對京東App 適配OpenHarmony 系統,從業務角度和技術棧角度進行了分析。
1.1 業務多樣性
目前京東App年度活躍使用者5.8億+,且90%以上都是通過客戶端下單。京東App作為京東的主應用,承接了京東集團內各個BG\BU的業務需求,業務形態眾多,需求迭代頻繁,每個迭代版本承接業務方需求3000+,對應的研發團隊規模上千人,分佈在北京、上海、深圳、成都、南京等職場。在功能上,涵蓋使用者可見的複雜業務和使用者不可見的底層能力以及支撐App的周邊生態。
綜合來看,京東App適配 OpenHarmony 涉及的團隊和業務都非常多,適配難度也非常大。
1.2 技術棧多樣性
我們看一下京東App內所用到的技術棧。京東App內用到的技術棧也很多,主要包括原生、H5&小程式、跨端,佔比分別是55%、40%、5%(其中RN、Flutter 佔比較少,所以不展開介紹)。
在佔比較多的原生、小程式、H5這部分,從程式碼量看,原生程式碼行數已經達到了千萬級,H5與小程式在App內程式碼行數百萬級,所以通過重寫程式碼來適配 OpenHarmony 幾乎不可能短期完成。
目前在原生開發方式上,我們自研的JD MCube 原生動態化框架在業務中覆蓋佔比近50%,而且後續我們也會持續提高JD MCube 的佔比;H5 & 小程式 目前主要是使用我們的 Aotu Taro 框架開發。分析看來,通過將JD MCube&Aotu Taro 適配到 OpenHarmony 可以極大降低整個App的適配工作量。
02JD MCube 動態化框架簡介
JD MCube 全景圖
簡單來說,JD MCube 使用統一的一套 DSL 來描述UI和事件,在各個平臺上進行解析並對映成各平臺的UI控制元件,最終渲染展示。具體可以參考我們之前釋出的文章 京東App MCube動態化實踐 。
03JD MCube 適配 OH 探索
我們期望通過JD MCube 適配 OpenHarmony,為京東集團內應用快速遷移 OpenHarmony 平臺提供解決方案。
3.1 技術方案對比‘
在進行適配之前,我們先回顧下現有的 OpenHarmony UI 框架,現有的 UI 框架分為兩類:類 Web UI 正規化和宣告式 UI 正規化。(Java UI 後續不再更新維護,所以不再介紹)。
類Web UI 開發正規化主要使用 HML + JS + CSS來搭建UI頁面和處理相關邏輯;宣告式 UI 開發正規化基於擴充套件的 TS 語言(Ets)來開發,開發方式更類似 Flutter,通過改變資料來改變 UI 狀態。
接著我們和 OpenHarmony 技術專家基於我們的MCube實現原理進行了技術交流,他們提供了額外的選擇,利用更為底層的UI框架,使用C++相關API來完成UI的建立,再通過ETS的XComponent元件完成渲染。我們分別分析了使用這三種不同方案,應該怎麼落地。
1. 類Web UI:使用此方案,需要 OpenHarmony 提供Dom Api,類似於React 的JSX,用於動態的建立和更新View,當資料改變需要更新View屬性時,需要開發者自己實現一套Diff機制來實現增量更新。
2. 宣告式UI:使用此方案,需要 OpenHarmony 提供相關的 Ets 命令式API,用於動態的建立和更新View,當資料改變需要更新View屬性時,仍可以基於現有的狀態管理機制做到View的自動更新,開發者不需要額外處理。
3. C++ API:使用此方案,由於目前這一層面的API還沒有對開發者暴露,需要 OpenHarmony 提供相應的開發環境,在View更新上,需要由開發者來實現狀態管理。並且由於該方案使用了較為底層的API, OpenHarmony 的技術專家擔心會對App及系統造成不穩定,不太建議該方案。
基於以上的分析,我們綜合對比了開發友好性、元件豐富度、UI 更新方式、以及 OpenHarmony 技術專家的建議,最終選擇使用宣告式UI 開發正規化作為實施方案。
3.2 落地情況及階段性成果
通過和 OpenHarmony 技術專家緊密配合,在臨時提供的SDK上,我們使用Ets命令式API,完成了JD MCube 模板解析 -> 資料繫結 -> 檢視對映 ->渲染流程,同時實現了通過修改資料來源驅動檢視更新的邏輯。主要流程如下圖:
關鍵步驟詳解:
1、外層容器(Column)
首先建立一個容器,這裡我們是用的 Column 元件,將模板檔案解析命令傳送至worker執行緒,在worker執行緒內解析模板檔案並生成ViewNode Tree後,回撥至主執行緒中。資料更新後,觸發容器的build,內部解析ViewNode Tree。
2、解析ViewNode -> View
每個ViewNode的名字對應一個檢視解析器,用於建立對應View和解析相關屬性。
ViewNode Tree 的解析入口,會遞迴解析ViewNode Tree,並會根據快取來判斷是要建立一個View還是更新已有View的屬性。
建立View,其實是先構建了一個Row元件,內部呼叫解析方法,將構建出來的View新增到該Row元件上,同時也被新增到了最外層的Column上。
3、建立\更新View,屬性賦值
以 FlexboxLayout 和 TextView 解析器為例,通過命令式API,創建出對應Flex和Text元件並對其設定相應的屬性。這裡需要注意的是,建立和更新的場景相應的程式碼是一致的,其區別只是有沒有被新增到外層容器上。
效果
我們將xml模板檔案+JSON資料通過上述流程之後,最終執行到了開發版上之後,渲染出了一個列表條目。
目前我們在 OpenHarmony 平臺上,已通過Demo驗證了 JDMCube 框架適配 OpenHarmony 平臺的可行性。後續仍有很多工作要做,在和 Android\iOS 平臺功能對齊上,我們的自研表示式解析引擎、二進位制編解碼、事件處理、模板管理、生命週期監聽等等仍需要改造適配至 OpenHarmony 平臺。在效能優化方面,模板檔案的解析效率、使用命令式API建立和更新檢視的效率也是我們發力的重點。
3.3 後續規劃
大型APP適配 OpenHarmony 是北向應用生態面臨的重要課題。在技術上,京東將持續推進自研原生動態化框架JDMCube和跨端跨框架解決方案Aotu Taro適配 OpenHarmony 的進展,未來目標是作為應用低成本適配 OpenHarmony 平臺的技術方案,以助力行業發展與 OpenHarmony 應用生態繁榮。
- Spring中實現非同步呼叫的方式有哪些?
- 帶引數的全型別 Python 裝飾器
- 整理了幾個Python正則表示式,拿走就能用!
- SOLID:開閉原則Go程式碼實戰
- React中如何引入CSS呢
- 一個新視角:前端框架們都卷錯方向了?
- 編碼中的Adapter,不僅是一種設計模式,更是一種架構理念與解決方案
- 手寫程式語言-遞迴函式是如何實現的?
- 一文搞懂模糊匹配:定義、過程與技術
- 新來個阿里 P7,僅花 2 小時,做出一個多執行緒永動任務,看完直接跪了
- Puzzlescript,一種開發H5益智遊戲的引擎
- @Autowired和@Resource到底什麼區別,你明白了嗎?
- CSS transition 小技巧!如何保留 hover 的狀態?
- React如此受歡迎離不開這4個主要原則
- LeCun再炮轟Marcus: 他是心理學家,不是搞AI的
- Java保證執行緒安全的方式有哪些?
- 19個殺手級 JavaScript 單行程式碼,讓你看起來像專業人士
- Python 的"self"引數是什麼?
- 別整一坨 CSS 程式碼了,試試這幾個實用函式
- 再有人問你什麼是MVCC,就把這篇文章發給他!