?背景

2022.7.27日，在《開放原子全球開源峰會(huì)》-OpenHarmony分論壇上，京東作為分享嘉賓，為大家?guī)砹司实姆窒怼＞〇|積極擁抱 OpenHarmony，并參與 OpenHarmony 應(yīng)用生態(tài)建設(shè)，分享中介紹了京東App適配 OpenHarmony 的探索，重點(diǎn)呈現(xiàn)了京東跨平臺(tái)方案Aotu Taro 和 JD MCube 在 OpenHarmony 上的實(shí)踐。

其中Aotu Taro 框架是業(yè)界領(lǐng)先的跨端跨框架解決方案，并在 OpenHarmony 開源項(xiàng)目組主導(dǎo)成立了 CrossPlatformUI-SIG，通過Aotu Taro 可以很便捷地開發(fā)、調(diào)試、發(fā)布鴻蒙及 OpenHarmony 應(yīng)用，幫助開發(fā)人員快速構(gòu)建鴻蒙及 OpenHarmony 應(yīng)用。

JD MCube 框架是京東自研的原生動(dòng)態(tài)化框架，覆蓋了京東app黃金流程業(yè)務(wù)，并賦能集團(tuán)其他app，目前正在聯(lián)合京東集團(tuán)內(nèi)部力量進(jìn)行共建，暫未對(duì)外開源。

精彩回顧

京東App技術(shù)架構(gòu)總監(jiān)蓋旭天為大家現(xiàn)場(chǎng)講解京東App適配復(fù)雜度和在OpenHarmony平臺(tái)的適配進(jìn)展

由于論壇上分享時(shí)間有限，很多細(xì)節(jié)無法展現(xiàn)，Aotu Taro目前是開源項(xiàng)目，歡迎大家到社區(qū)參與共建。應(yīng)眾多聽眾要求，這篇文章會(huì)細(xì)致的向大家介紹 暫未開源的JD MCube 框架在 OpenHarmony 的適配進(jìn)展。

01京東App 適配現(xiàn)狀分析

我們對(duì)京東App 適配OpenHarmony 系統(tǒng)，從業(yè)務(wù)角度和技術(shù)棧角度進(jìn)行了分析。

1.1 業(yè)務(wù)多樣性

目前京東App年度活躍用戶5.8億+，且90%以上都是通過客戶端下單。京東App作為京東的主應(yīng)用，承接了京東集團(tuán)內(nèi)各個(gè)BG\BU的業(yè)務(wù)需求，業(yè)務(wù)形態(tài)眾多，需求迭代頻繁，每個(gè)迭代版本承接業(yè)務(wù)方需求3000+，對(duì)應(yīng)的研發(fā)團(tuán)隊(duì)規(guī)模上千人，分布在北京、上海、深圳、成都、南京等職場(chǎng)。在功能上，涵蓋用戶可見的復(fù)雜業(yè)務(wù)和用戶不可見的底層能力以及支撐App的周邊生態(tài)。

綜合來看，京東App適配 OpenHarmony 涉及的團(tuán)隊(duì)和業(yè)務(wù)都非常多，適配難度也非常大。

1.2 技術(shù)棧多樣性

我們看一下京東App內(nèi)所用到的技術(shù)棧。京東App內(nèi)用到的技術(shù)棧也很多，主要包括原生、H5&小程序、跨端，占比分別是55%、40%、5%（其中RN、Flutter 占比較少，所以不展開介紹）。

在占比較多的原生、小程序、H5這部分，從代碼量看，原生代碼行數(shù)已經(jīng)達(dá)到了千萬級(jí)，H5與小程序在App內(nèi)代碼行數(shù)百萬級(jí)，所以通過重寫代碼來適配 OpenHarmony 幾乎不可能短期完成。

目前在原生開發(fā)方式上，我們自研的JD MCube 原生動(dòng)態(tài)化框架在業(yè)務(wù)中覆蓋占比近50%，而且后續(xù)我們也會(huì)持續(xù)提高JD MCube 的占比；H5 & 小程序 目前主要是使用我們的 Aotu Taro 框架開發(fā)。分析看來，通過將JD MCube&Aotu Taro 適配到 OpenHarmony 可以極大降低整個(gè)App的適配工作量。

02JD MCube 動(dòng)態(tài)化框架簡(jiǎn)介

JD MCube 全景圖

簡(jiǎn)單來說，JD MCube 使用統(tǒng)一的一套 DSL 來描述UI和事件，在各個(gè)平臺(tái)上進(jìn)行解析并映射成各平臺(tái)的UI控件，最終渲染展示。具體可以參考我們之前發(fā)布的文章 京東App MCube動(dòng)態(tài)化實(shí)踐 。

03JD MCube 適配 OH 探索

我們期望通過JD MCube 適配 OpenHarmony，為京東集團(tuán)內(nèi)應(yīng)用快速遷移 OpenHarmony 平臺(tái)提供解決方案。

3.1 技術(shù)方案對(duì)比‘

在進(jìn)行適配之前，我們先回顧下現(xiàn)有的 OpenHarmony UI 框架，現(xiàn)有的 UI 框架分為兩類：類 Web UI 范式和聲明式 UI 范式。（Java UI 后續(xù)不再更新維護(hù)，所以不再介紹）。

類Web UI 開發(fā)范式主要使用 HML + JS + CSS來搭建UI頁(yè)面和處理相關(guān)邏輯；聲明式 UI 開發(fā)范式基于擴(kuò)展的 TS 語(yǔ)言(Ets)來開發(fā)，開發(fā)方式更類似 Flutter，通過改變數(shù)據(jù)來改變 UI 狀態(tài)。

接著我們和 OpenHarmony 技術(shù)專家基于我們的MCube實(shí)現(xiàn)原理進(jìn)行了技術(shù)交流，他們提供了額外的選擇，利用更為底層的UI框架，使用C++相關(guān)API來完成UI的創(chuàng)建，再通過ETS的XComponent組件完成渲染。我們分別分析了使用這三種不同方案，應(yīng)該怎么落地。

1. 類Web UI：使用此方案，需要 OpenHarmony 提供Dom Api，類似于React 的JSX，用于動(dòng)態(tài)的創(chuàng)建和更新View，當(dāng)數(shù)據(jù)改變需要更新View屬性時(shí)，需要開發(fā)者自己實(shí)現(xiàn)一套Diff機(jī)制來實(shí)現(xiàn)增量更新。

2. 聲明式UI: 使用此方案，需要 OpenHarmony 提供相關(guān)的 Ets 命令式API，用于動(dòng)態(tài)的創(chuàng)建和更新View，當(dāng)數(shù)據(jù)改變需要更新View屬性時(shí)，仍可以基于現(xiàn)有的狀態(tài)管理機(jī)制做到View的自動(dòng)更新，開發(fā)者不需要額外處理。

3. C++ API: 使用此方案，由于目前這一層面的API還沒有對(duì)開發(fā)者暴露，需要 OpenHarmony 提供相應(yīng)的開發(fā)環(huán)境，在View更新上，需要由開發(fā)者來實(shí)現(xiàn)狀態(tài)管理。并且由于該方案使用了較為底層的API, OpenHarmony 的技術(shù)專家擔(dān)心會(huì)對(duì)App及系統(tǒng)造成不穩(wěn)定，不太建議該方案。

基于以上的分析，我們綜合對(duì)比了開發(fā)友好性、組件豐富度、UI 更新方式、以及 OpenHarmony 技術(shù)專家的建議，最終選擇使用聲明式UI 開發(fā)范式作為實(shí)施方案。 

3.2 落地情況及階段性成果

通過和 OpenHarmony 技術(shù)專家緊密配合，在臨時(shí)提供的SDK上，我們使用Ets命令式API，完成了JD MCube 模板解析 -> 數(shù)據(jù)綁定 -> 視圖映射 ->渲染流程，同時(shí)實(shí)現(xiàn)了通過修改數(shù)據(jù)源驅(qū)動(dòng)視圖更新的邏輯。主要流程如下圖：

關(guān)鍵步驟詳解：

1、外層容器(Column)

首先創(chuàng)建一個(gè)容器，這里我們是用的 Column 組件，將模板文件解析命令發(fā)送至worker線程，在worker線程內(nèi)解析模板文件并生成ViewNode Tree后，回調(diào)至主線程中。數(shù)據(jù)更新后，觸發(fā)容器的build，內(nèi)部解析ViewNode Tree。

2、解析ViewNode -> View

每個(gè)ViewNode的名字對(duì)應(yīng)一個(gè)視圖解析器，用于創(chuàng)建對(duì)應(yīng)View和解析相關(guān)屬性。

ViewNode Tree 的解析入口，會(huì)遞歸解析ViewNode Tree，并會(huì)根據(jù)緩存來判斷是要?jiǎng)?chuàng)建一個(gè)View還是更新已有View的屬性。

創(chuàng)建View,其實(shí)是先構(gòu)建了一個(gè)Row組件，內(nèi)部調(diào)用解析方法，將構(gòu)建出來的View添加到該Row組件上，同時(shí)也被添加到了最外層的Column上。

3、創(chuàng)建\更新View，屬性賦值

以 FlexboxLayout 和 TextView 解析器為例，通過命令式API，創(chuàng)建出對(duì)應(yīng)Flex和Text組件并對(duì)其設(shè)置相應(yīng)的屬性。這里需要注意的是，創(chuàng)建和更新的場(chǎng)景相應(yīng)的代碼是一致的，其區(qū)別只是有沒有被添加到外層容器上。

效果

我們將xml模板文件+JSON數(shù)據(jù)通過上述流程之后，最終運(yùn)行到了開發(fā)版上之后，渲染出了一個(gè)列表?xiàng)l目。 

目前我們?cè)?OpenHarmony 平臺(tái)上，已通過Demo驗(yàn)證了 JDMCube 框架適配 OpenHarmony 平臺(tái)的可行性。后續(xù)仍有很多工作要做，在和 Android\iOS 平臺(tái)功能對(duì)齊上，我們的自研表達(dá)式解析引擎、二進(jìn)制編解碼、事件處理、模板管理、生命周期監(jiān)聽等等仍需要改造適配至 OpenHarmony 平臺(tái)。在性能優(yōu)化方面，模板文件的解析效率、使用命令式API創(chuàng)建和更新視圖的效率也是我們發(fā)力的重點(diǎn)。

3.3 后續(xù)規(guī)劃

大型APP適配 OpenHarmony 是北向應(yīng)用生態(tài)面臨的重要課題。在技術(shù)上，京東將持續(xù)推進(jìn)自研原生動(dòng)態(tài)化框架JDMCube和跨端跨框架解決方案Aotu Taro適配 OpenHarmony 的進(jìn)展，未來目標(biāo)是作為應(yīng)用低成本適配 OpenHarmony 平臺(tái)的技術(shù)方案，以助力行業(yè)發(fā)展與 OpenHarmony 應(yīng)用生態(tài)繁榮。