作者；京東科技 胡大海

前言

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

一、背景

市面上的APP，一般使用兩種技術方式承載業務：

1、原生開發方式：優勢是可以充分使用系統能力，帶來極致的用戶體驗；劣勢是動態性差、發布周期長、無法跨平臺。

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

我們從業務效率、用戶體驗、研發成本三個維度總結以上兩種技術存在的問題：

1、業務效率

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

2、用戶體驗

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

3、研發成本

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

二、方案實踐

1、方案簡介

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

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

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

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

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

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

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

每一個框架都有很多先進理念值得我們學習，站在巨人的肩膀上，我們吸取了各個框架的優勢，加上自主創新，發明了卡片級動態化渲染技術、高性能列表技術、底層框架升級業務無感技術、業務天然分包技術、多端分布式實時預覽等一系創新，打造了自主可控的動態化跨端解決方案。

2、實現方案

2.1、源代碼

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

2.2、腳手架

腳手架方便開發者進行項目工程化管理，通過我們自研的complier loader完成業務代碼及JSEngine的編譯工作，借助Babel插件支持了ES6語法，支持圖片Base64轉換、產物Zip壓縮、熱重載等一系列能力；為保障業務構建產物安全，目前腳手架構建能力已經以云端構建方式運行，提供了統一的構建環境。

2.3、產物管理

云端構建的產物，可以直接發布到動態化資源管理后臺，后臺提供了資源加密、灰度發布、長連接推送等強大的管理能力，滿足了業務人群灰度、AB發布等訴求，為業務快速試錯提供了有力保障。

2.4、產物運行

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

2.5、統一接口聲明

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

2.6、接口實現

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

三、應用場景

1、卡片場景

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

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

2、頁面場景

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

3、未來適用的場景

通過進一步擴展APP級基礎能力，可用于一個完整APP的開發。

四、未來規劃

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

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

五、寫在最后

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

審核編輯 黃宇