京東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 應用生態繁榮。