作者；京東科技 胡大海

前言

動態(tài)化-羅碼（后文統(tǒng)稱動態(tài)化）是一個全自主研發(fā)的一站式跨平臺解決方案，一份代碼，可以在iOS、Android、H5及華為HarmonyOS運行。在研發(fā)團(tuán)隊使用后可大幅降低研發(fā)人力成本；為業(yè)務(wù)提供實時觸達(dá)、A/B觸達(dá)等能力以提升業(yè)務(wù)投放效率；同時保障了C端用戶優(yōu)秀的用戶體驗。

一、背景

市面上的APP，一般使用兩種技術(shù)方式承載業(yè)務(wù)：

1、原生開發(fā)方式：優(yōu)勢是可以充分使用系統(tǒng)能力，帶來極致的用戶體驗；劣勢是動態(tài)性差、發(fā)布周期長、無法跨平臺。

2、H5開發(fā)方式：優(yōu)勢是動態(tài)性好、可隨時發(fā)布、支持多平臺；劣勢是體驗相對較差、系統(tǒng)能力使用受限（需要通過橋接使用系統(tǒng)原生能力）。

我們從業(yè)務(wù)效率、用戶體驗、研發(fā)成本三個維度總結(jié)以上兩種技術(shù)存在的問題：

1、業(yè)務(wù)效率

公司端內(nèi)業(yè)務(wù)需求一般需要集中在某一個固定時間發(fā)版，且各個應(yīng)用市場對于APP的發(fā)版都有審核的周期，這樣原生開發(fā)的業(yè)務(wù)就無法及時觸達(dá)用戶，甚至對于未升級的舊版用戶無法觸達(dá)。

2、用戶體驗

研究表明，如果一個移動端頁面加載時長超過 3 秒，用戶就會放棄等待；網(wǎng)頁加載時長每增加1 秒，用戶就會流失 10%，但是由于WebView本身的歷史包袱，渲染性能差、JS執(zhí)行效率低、用戶體驗差的問題一直無法徹底解決。

3、研發(fā)成本

同一個業(yè)務(wù)如果四端(H5、Android、iOS、Harmony)同時開發(fā)，需要投入四端人員，開發(fā)成本高。

二、方案實踐

1、方案簡介

針對上述背景中兩種技術(shù)存在的問題，業(yè)界相繼出現(xiàn)了FaceBook公司的ReactNative、阿里巴巴公司的Weex、騰訊公司的微信小程序、京東的Taro(RN原生部分)、Google公司的的Flutter、華為的ArkUI-X等各種跨端解決方案。

幾乎每個跨端解決方案追求的就是在保證C端用戶良好的用戶體驗的同時，讓業(yè)務(wù)以最小的人力成本和最快的速度觸達(dá)用戶；下面我們從開發(fā)效率、性能、動態(tài)性、渲染方式、上手難度等維度對業(yè)界跨端方案及我們自研的動態(tài)化跨端方案做對一個對比：

通過上述表格對比發(fā)現(xiàn)，每一個框架都有很多優(yōu)劣和部分劣勢，那么為什么要自己再做一個動態(tài)化方案而不直接使用現(xiàn)有方案呢？

1、React Native和Weex是兩個比較相似的技術(shù)方案，Weex在核心開發(fā)語言和包大小(React Native可以通過業(yè)務(wù)拆包減小包大小)相比React Native具有一定的優(yōu)勢，但是都存在兩個共性的問題，第一對于常用的長列表渲染、瀑布流渲染都存在渲染瓶頸，第二在框架每次升級后都需要所有存量業(yè)務(wù)測試驗證，造成測試成本突增、業(yè)務(wù)穩(wěn)定性被破壞。

2、H5通過離線化技術(shù)能夠一定程度緩解渲染速度，但在復(fù)雜場景交互仍然存在較多交互問題，甚至在運營商被劫持、Cookie丟失等場景會導(dǎo)致頁面直接白屏。

3、小程序可以看做是一個特殊的H5技術(shù)，它使用了雙線程模型將UI渲染和業(yè)務(wù)邏輯分散到兩個線程執(zhí)行。

4、Flutter的Dart開發(fā)語言相比其他框架學(xué)習(xí)門檻較高，并且因為沒有動態(tài)更新能力，無法滿足業(yè)務(wù)熱更新的訴求，雖然可以通過一定的技術(shù)手段達(dá)到動態(tài)發(fā)布的目的，但整個鏈路就會變得復(fù)雜，導(dǎo)致業(yè)務(wù)維護(hù)、排查問題成本直線上升。

每一個框架都有很多先進(jìn)理念值得我們學(xué)習(xí)，站在巨人的肩膀上，我們吸取了各個框架的優(yōu)勢，加上自主創(chuàng)新，發(fā)明了卡片級動態(tài)化渲染技術(shù)、高性能列表技術(shù)、底層框架升級業(yè)務(wù)無感技術(shù)、業(yè)務(wù)天然分包技術(shù)、多端分布式實時預(yù)覽等一系創(chuàng)新，打造了自主可控的動態(tài)化跨端解決方案。

2、實現(xiàn)方案

2.1、源代碼

分為JSEngine和業(yè)務(wù)代碼(Hello.jue)兩個部分，JSEngine即為我們自主研發(fā)的業(yè)務(wù)代碼運行時環(huán)境，在產(chǎn)物運行階段會第一時間被加載，負(fù)責(zé)業(yè)務(wù)代碼實例管理、任務(wù)管理、虛擬Dom樹管理、虛擬Dom樹Differ、業(yè)務(wù)頁面渲染管理、生命周期管理、事件分發(fā)、業(yè)務(wù)邏輯處理等一系列功能；業(yè)務(wù)代碼即具體的業(yè)務(wù)代碼，其結(jié)構(gòu)和Vue一致，包含了描述業(yè)務(wù)UI的template、業(yè)務(wù)邏輯表達(dá)的script以及業(yè)務(wù)UI樣式的style三個部分，語法和Vue幾乎一致，但是具備了標(biāo)簽擴(kuò)展能力，比如在長列表和瀑布流場景我們可以通過結(jié)合原生列表及瀑布流控件快速打造出一個高性能的列表標(biāo)簽。

2.2、腳手架

腳手架方便開發(fā)者進(jìn)行項目工程化管理，通過我們自研的complier loader完成業(yè)務(wù)代碼及JSEngine的編譯工作，借助Babel插件支持了ES6語法，支持圖片Base64轉(zhuǎn)換、產(chǎn)物Zip壓縮、熱重載等一系列能力；為保障業(yè)務(wù)構(gòu)建產(chǎn)物安全，目前腳手架構(gòu)建能力已經(jīng)以云端構(gòu)建方式運行，提供了統(tǒng)一的構(gòu)建環(huán)境。

2.3、產(chǎn)物管理

云端構(gòu)建的產(chǎn)物，可以直接發(fā)布到動態(tài)化資源管理后臺，后臺提供了資源加密、灰度發(fā)布、長連接推送等強大的管理能力，滿足了業(yè)務(wù)人群灰度、AB發(fā)布等訴求，為業(yè)務(wù)快速試錯提供了有力保障。

2.4、產(chǎn)物運行

這里分為兩種類型產(chǎn)物的運行，首先是JSEngine，在iOS系統(tǒng)使用系統(tǒng)提供的JSCore、在安卓系統(tǒng)使用V8引擎、在Web使用瀏覽器的WebKit，由一個專門的JS線程在一個最早的時機(jī)(比如APP啟動)進(jìn)行JSEngine的加載，加載完畢后，就形成了了業(yè)務(wù)產(chǎn)物運行的環(huán)境；然后客戶端通過下載后臺對應(yīng)的產(chǎn)物，經(jīng)過解密及解壓縮后就得到了業(yè)務(wù)原始JS文件，業(yè)務(wù)資源的運行過程，是一個創(chuàng)建業(yè)務(wù)實例的過程，由JSEngine統(tǒng)一管理。

2.5、統(tǒng)一接口聲明

JSEngine統(tǒng)一創(chuàng)建業(yè)務(wù)實例的過程是統(tǒng)一的，而真正渲染的客戶端是多個(iOS、Android、H5、HarmonyOS等)，通過制定統(tǒng)一的接口規(guī)范客戶端標(biāo)準(zhǔn)化對接及擴(kuò)展（比如在華為鴻蒙系統(tǒng)適配只需實現(xiàn)統(tǒng)一接口即可），接口包含了實例創(chuàng)建聲明周期、元素的增刪改查、JS和原生的雙向通訊、熱重載交互等各種能力。

2.6、接口實現(xiàn)

這個過程的核心任務(wù)是在iOS、Android等系統(tǒng)上，實現(xiàn)統(tǒng)一接口聲明的方法，創(chuàng)建出業(yè)務(wù)對應(yīng)的頁面和處理業(yè)務(wù)交互邏輯。通過完成統(tǒng)一接口的元素增刪改操作及其他指令后就構(gòu)建出了一個組件樹，再經(jīng)過布局引擎布局后，就顯示出了業(yè)務(wù)具體的頁面效果；當(dāng)用戶在業(yè)務(wù)頁面發(fā)生了交互事件后，通過統(tǒng)一接口的JS和原生的雙向通訊調(diào)用到業(yè)務(wù)方，當(dāng)業(yè)務(wù)方需要改變UI布局的時候，同樣通過JS和原生的雙向通訊觸發(fā)布局引擎重新布局，由于JS語言本身是圖靈完備的，所以任何業(yè)務(wù)邏輯都可以在JS中實現(xiàn)而不會收到任何限制；這樣就完成了業(yè)務(wù)UI渲染和交互邏輯的處理過程。

三、應(yīng)用場景

1、卡片場景

動態(tài)化項目孵化于京東金融APP實際業(yè)務(wù)場景，京東金融APP的積木式構(gòu)建頁面的技術(shù)，一定程度上能夠根據(jù)接口數(shù)據(jù)驅(qū)動預(yù)埋在客戶端的積木卡片自由組合一個頁面，但是存量積木卡片修改及新增依然需要發(fā)版。當(dāng)時通過調(diào)研發(fā)現(xiàn)，市面上的跨端技術(shù)多以頁面維度進(jìn)行支持，對于局部卡片模式的跨端沒有很好的解決方案，我們決定自研一個能夠和原生卡片共存的區(qū)域卡片動態(tài)化技術(shù)，目標(biāo)如下圖所示，被放大的兩個卡片使用動態(tài)化技術(shù)實現(xiàn)，不改變其余樓層的原生實現(xiàn)方式。

區(qū)域動態(tài)化技術(shù)是我們自研的一套跨平臺、動態(tài)化的樓層卡片解決方案，渲染速度幾乎可以和原生同步，用戶體驗好，并無縫對接了公司內(nèi)部運營系統(tǒng)及埋點曝光等功能。

2、頁面場景

頁面動態(tài)化技術(shù)是在區(qū)域動態(tài)化基礎(chǔ)上的進(jìn)一步擴(kuò)展，提供了頁面常用的列表組件、瀑布流組件、下拉刷新組件等，進(jìn)一步提供的混合路由模塊和以及沉浸式導(dǎo)航能力使動態(tài)化形成了區(qū)域到頁面級別的升級。對于業(yè)界跨端方案普遍面臨的埋點、曝光難題，我們設(shè)計實現(xiàn)了一套無侵入自動化埋點和曝光的協(xié)議接口，并在金融APP無縫對接了埋點、曝光通道。

3、未來適用的場景

通過進(jìn)一步擴(kuò)展APP級基礎(chǔ)能力，可用于一個完整APP的開發(fā)。

四、未來規(guī)劃

在渲染性能方向，探索抽取Flutter底層SKIA渲染引擎作為動態(tài)化的渲染引擎，進(jìn)一步提升渲染速度和渲染一致性，降低未來多端長期維護(hù)成本。

在DSL支持方向，基于Vue3的虛擬Dom接口分離設(shè)計，以及ReactNative最新的渲染流程架構(gòu)設(shè)計，為虛擬Dom技術(shù)思想打造的跨端框架對接多個前端DSL提供了空間，未來Vue3和React開發(fā)的項目可以結(jié)合動態(tài)化實現(xiàn)跨端，充分發(fā)揮動態(tài)化原生渲染優(yōu)勢，使前端業(yè)務(wù)低成本享受原生絲滑體驗。

五、寫在最后

動態(tài)化是一個涉及JavaScript、iOS、Android、Java、Harmony、Vue、Node、Webpack等眾多領(lǐng)域的綜合解決方案，我們有各個領(lǐng)域優(yōu)秀的小伙伴共同前行，大家如果想深入了解某個領(lǐng)域的具體實現(xiàn)，千萬別忘了點贊+收藏，方便以后隨時閱讀和提出寶貴意見。

審核編輯 黃宇