作者：京東科技 胡大海

前言

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

一、動態化跨端框架原理介紹

??

通過上圖，我們先了解一下動態化跨端框架在iOS、Android等多個平臺實現跨端的原理：

① 業務層：業務代碼經過打包后形成business.js發布到云端，被Harmony、iOS、Android、H5四端共用。

② 虛擬機層：虛擬機的核心職責是運行js代碼，這也是跨平臺框架的基礎，在iOS使用系統內置的JSCore，在Android使用V8，在瀏覽器使用Webkit，在鴻蒙系統我們依然需要一個能夠運行js代碼的虛擬機。

③ 通訊層：在iOS和Android端使用了json數據格式進行通訊數據的傳輸，在鴻蒙系統也可以使用該方案。

④ 渲染層：使用各個系統的系統組件進行UI元素的渲染。

二、基于方舟虛擬機的方案探索

1、方舟字節碼概念

方舟字節碼（Ark Bytecode），是由方舟編譯器編譯ArkTS/TS/JS生成的，提供給方舟運行時解釋執行的二進制文件，字節碼中的主要內容是方舟字節碼指令。

2、在方舟虛擬機中運行JS

方舟虛擬機不能直接運行當前在V8中運行的js代碼，但是能夠執行方舟字節碼，所以我們可以借助鴻蒙提供的工具將js代碼轉化為方舟字節碼，這樣就能利用鴻蒙系統的方舟虛擬機執行我們的js代碼了。

??

3、存在的問題

3.1、業務無法熱更新

在iOS和Android端，業務可以隨時打包后在云端發布新的版本，借助于JSCore或者V8就可以直接運行新的版本的js，這樣就支持了業務的熱更新發布。但在鴻蒙系統上，華為基于安全考慮，business.abc這樣的字節碼文件不支持動態下發，需要內置到APP中，這樣就失去了業務熱更新的能力。

3.2、單線程性能問題

在其他兩端我們是開啟了一個單獨的JS線程，進行business.js文件的執行，但是如果我們使用方舟虛擬機執行business.js轉換來的business.abc的時候，其實是在方舟虛擬機的UI主線程運行了這個文件。在其他兩端js文件在JS線程執行的時候，UI渲染和交互是并行不受影響的，但是在方舟虛擬機單線程下abc文件的執行和UI渲染&交互變成了串行，這樣必然會嚴重影響頁面渲染速度和交互的流暢度。

業務不能熱更新以及單線程性能不佳等問題的存在，我們決定使用另一種方案-V8虛擬機。

三、基于V8虛擬機的方案落地

1、在V8虛擬機中運行JS

如果能把V8移植到鴻蒙系統中，我們就可以像其他兩端一樣使用多線程并且能實現業務熱更新等特性，但是V8是一個近千萬級代碼的龐大倉庫，需要掌握CMake、Clang、LLVM、Ninja等一系列交叉編譯知識(嵌入式范疇)，對于應用開發者是一個巨大的挑戰，雖然我們已經掌握了V8移植到鴻蒙的技術，但從包大小、穩定性、兼容性、維護成本等維度看，華為廠商內置V8是一個具有長期收益的重大事項，通過和華為持續溝通，最終華為將V8內置到了操作系統，業界所有類動態化框均可直接使用內置V8虛擬機進行跨端框架的適配。

??

2、高性能核心方案

2.1、多線程架構

多線程是提高程序性能最直接、最有效的手段之一，借助于鴻蒙系統內置的V8虛擬機，我們就能像iOS、Android兩端一樣使用三線程模型完成動態化跨端框架在鴻蒙系統的渲染過程。

JS線程負責將業務代碼解析為一顆虛擬Dom樹、發出渲染命令、處理業務邏輯等，通過接口定義的橋方法發送給組件線程進行處理。我們以添加一個點擊按鈕節點為例，JS線程會通過“添加節點”這個接口以JSON描述的方式，將信息傳遞給組件線程,組件線程根據JSON描述將這個點擊按鈕節點添加到組件樹中，然后觸發UI線程創建系統組件，比如在鴻蒙系統會創建一個ArkTS的按鈕組件，在iOS系統會創建一個UIButton組件。

UI線程負責用戶頁面滑動、點擊事件等交互行為，當發生比如用戶點擊事件后，同樣通過接口定義的橋方法“調用JS”，將點擊事件傳遞給JS線程進行處理，緊接著繼續處理UI線程的任務，這樣UI線程的交互效率就高了，充分保障了用戶良好的操作體驗。

//JSON描述示例
{
    "type":"btn",
    "value":"按鈕",
    "childrens":[],
    "id":"238346e885ee",
    "style":{
        "width":"66px"
    },
    "attr":{
        "text-color":"#FFFFFFFF"
    },
    "event":{
        "onclick":"myclick()"
    }
}

2.2、JSI技術引入

通訊橋存在的問題

動態化基于三個線程并行運行的方式，使其渲染性能已經接近于原生的渲染性能，但是在一些頻繁通訊場景，通訊橋會“堵塞”，比如當業務需要監聽一個頁面的滑動而改變另外一個元素背景色的透明度，那么JS線程大部分時間在處理接收列表滑動距離，改變元素背景色透明度這個任務中，其他任務的執行會被嚴重影響。另外JSON數據傳輸的序列化和反序列化過程也會帶來很大的線程性能損耗。

??

解決方案-JSI

之前使用通訊橋的一個主要原因就是 C++ 中的函數沒辦法完整映射到 JavaScript 中，讓 JavaScript 直接調用，所以只能選擇以序列化字符串的形式通過通訊橋傳輸。而JSI做的事情就是將 C++ 中的常用類型（函數、對象等）一一映射到 JavaScript 中，我們就能在JS中直接調用C++的函數和對象了。因為消除了橋通訊帶來的序列化和異步調用的開銷，大大提升了線程通訊性能。

??

四、進一步優化的方向

1、減少UI層級

當前基于多線程和JSI的架構模式在鴻蒙系統的性能還算不差，但是在鴻蒙系統上同樣一個業務的UI層級是其他兩端層級的約2倍。原因在于在鴻蒙系統使用系統組件進行遞歸渲染的時候，需要借助自定義組件進行實現，然而和iOS和Android端的命令式組件渲染不同，比如RomaDiv對應iOS就是直接翻譯為UIView即可，在鴻蒙必須增加一個包裹的容器才是一個合法的自定義組件，比如Stack容器，這樣每個組件的層級就多了一層，層級過多會直接影響渲染性能，在一些復雜業務場景到達一定層級后會造成頁面掉幀和卡頓。

@Componentexport 
struct RomaDiv 
{ 
    build()
    { 
        Stack(){
         //借助wrapBuilder實現遞歸 
         ForEach(this.childrenTags, (childrenTag) => 
             { 
                 RomaComponentFactory.builder()//RomaComponentFactory就是對應鴻蒙系統提供的WrappedBuilder 
             }) 
         } 
    } 
}

面對業界跨端框架面臨的這個共性問題，鴻蒙系統提供了C語言的命令式接口進行組件創建，C組件接口是介于UI組件的Native實現和ArkTS對接層之間的一層C接口封裝，它繞過了狀態管理對組件變化、刷新的自動化管理，因此具有較好的性能。同時經過初步驗證，接入C-API后，UI層級能直接和另外兩端保持一致，同時渲染性能也會得到大幅提升。

2、降低通訊成本

當前JSI在鴻蒙系統的應用中通過JSI打通C++，再通過NAPI從C++打通ArkTS，跨語言通訊成本高。如果接入了C-API，就避免了C++和ArkTS之間類型互相轉換和跨語言調用的開銷，也能帶來不少的性能提升。

3、JS邏輯下沉到C++

在當前架構中，JS線程運行著V-Dom樹創建、對比，樣式&屬性解析等一系列繁重的框架邏輯，如果我們能將這些JS代碼邏輯下沉到C++，框架邏輯運行效率會進一步提升。

總結

本文講述了如何在鴻蒙系統中實現“動態化”跨端框架的高性能運行。包含探索方舟虛擬機運行方案時遇到的問題，以及基于V8虛擬機方案的具體提升手段和后續進一步提升的方案。通過閱讀，你將能夠更好地理解和應用這些技術，提高跨端框架的性能，提升C端用戶體驗。

審核編輯 黃宇