作者：京東科技 胡大海

前言

動(dòng)態(tài)化跨端框架（后文統(tǒng)稱(chēng)“動(dòng)態(tài)化”）是一個(gè)由京東金融大前端團(tuán)隊(duì)全自主研發(fā)的，一份代碼，可以在HarmonyOS、iOS、Android、Web四端運(yùn)行的跨平臺(tái)解決方案。在研發(fā)團(tuán)隊(duì)使用后可大幅降低研發(fā)人力成本；為業(yè)務(wù)提供實(shí)時(shí)觸達(dá)、A/B觸達(dá)等能力以提升業(yè)務(wù)投放效率；同時(shí)保障了C端用戶(hù)優(yōu)秀的用戶(hù)體驗(yàn)。

一、動(dòng)態(tài)化跨端框架原理介紹

??

通過(guò)上圖，我們先了解一下動(dòng)態(tài)化跨端框架在iOS、Android等多個(gè)平臺(tái)實(shí)現(xiàn)跨端的原理：

① 業(yè)務(wù)層：業(yè)務(wù)代碼經(jīng)過(guò)打包后形成business.js發(fā)布到云端，被Harmony、iOS、Android、H5四端共用。

② 虛擬機(jī)層：虛擬機(jī)的核心職責(zé)是運(yùn)行js代碼，這也是跨平臺(tái)框架的基礎(chǔ)，在iOS使用系統(tǒng)內(nèi)置的JSCore，在Android使用V8，在瀏覽器使用Webkit，在鴻蒙系統(tǒng)我們依然需要一個(gè)能夠運(yùn)行js代碼的虛擬機(jī)。

③ 通訊層：在iOS和Android端使用了json數(shù)據(jù)格式進(jìn)行通訊數(shù)據(jù)的傳輸，在鴻蒙系統(tǒng)也可以使用該方案。

④ 渲染層：使用各個(gè)系統(tǒng)的系統(tǒng)組件進(jìn)行UI元素的渲染。

二、基于方舟虛擬機(jī)的方案探索

1、方舟字節(jié)碼概念

方舟字節(jié)碼（Ark Bytecode），是由方舟編譯器編譯ArkTS/TS/JS生成的，提供給方舟運(yùn)行時(shí)解釋執(zhí)行的二進(jìn)制文件，字節(jié)碼中的主要內(nèi)容是方舟字節(jié)碼指令。

2、在方舟虛擬機(jī)中運(yùn)行JS

方舟虛擬機(jī)不能直接運(yùn)行當(dāng)前在V8中運(yùn)行的js代碼，但是能夠執(zhí)行方舟字節(jié)碼，所以我們可以借助鴻蒙提供的工具將js代碼轉(zhuǎn)化為方舟字節(jié)碼，這樣就能利用鴻蒙系統(tǒng)的方舟虛擬機(jī)執(zhí)行我們的js代碼了。

??

3、存在的問(wèn)題

3.1、業(yè)務(wù)無(wú)法熱更新

在iOS和Android端，業(yè)務(wù)可以隨時(shí)打包后在云端發(fā)布新的版本，借助于JSCore或者V8就可以直接運(yùn)行新的版本的js，這樣就支持了業(yè)務(wù)的熱更新發(fā)布。但在鴻蒙系統(tǒng)上，華為基于安全考慮，business.abc這樣的字節(jié)碼文件不支持動(dòng)態(tài)下發(fā)，需要內(nèi)置到APP中，這樣就失去了業(yè)務(wù)熱更新的能力。

3.2、單線(xiàn)程性能問(wèn)題

在其他兩端我們是開(kāi)啟了一個(gè)單獨(dú)的JS線(xiàn)程，進(jìn)行business.js文件的執(zhí)行，但是如果我們使用方舟虛擬機(jī)執(zhí)行business.js轉(zhuǎn)換來(lái)的business.abc的時(shí)候，其實(shí)是在方舟虛擬機(jī)的UI主線(xiàn)程運(yùn)行了這個(gè)文件。在其他兩端js文件在JS線(xiàn)程執(zhí)行的時(shí)候，UI渲染和交互是并行不受影響的，但是在方舟虛擬機(jī)單線(xiàn)程下abc文件的執(zhí)行和UI渲染&交互變成了串行，這樣必然會(huì)嚴(yán)重影響頁(yè)面渲染速度和交互的流暢度。

業(yè)務(wù)不能熱更新以及單線(xiàn)程性能不佳等問(wèn)題的存在，我們決定使用另一種方案-V8虛擬機(jī)。

三、基于V8虛擬機(jī)的方案落地

1、在V8虛擬機(jī)中運(yùn)行JS

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

??

2、高性能核心方案

2.1、多線(xiàn)程架構(gòu)

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

JS線(xiàn)程負(fù)責(zé)將業(yè)務(wù)代碼解析為一顆虛擬Dom樹(shù)、發(fā)出渲染命令、處理業(yè)務(wù)邏輯等，通過(guò)接口定義的橋方法發(fā)送給組件線(xiàn)程進(jìn)行處理。我們以添加一個(gè)點(diǎn)擊按鈕節(jié)點(diǎn)為例，JS線(xiàn)程會(huì)通過(guò)“添加節(jié)點(diǎn)”這個(gè)接口以JSON描述的方式，將信息傳遞給組件線(xiàn)程,組件線(xiàn)程根據(jù)JSON描述將這個(gè)點(diǎn)擊按鈕節(jié)點(diǎn)添加到組件樹(shù)中，然后觸發(fā)UI線(xiàn)程創(chuàng)建系統(tǒng)組件，比如在鴻蒙系統(tǒng)會(huì)創(chuàng)建一個(gè)ArkTS的按鈕組件，在iOS系統(tǒng)會(huì)創(chuàng)建一個(gè)UIButton組件。

UI線(xiàn)程負(fù)責(zé)用戶(hù)頁(yè)面滑動(dòng)、點(diǎn)擊事件等交互行為，當(dāng)發(fā)生比如用戶(hù)點(diǎn)擊事件后，同樣通過(guò)接口定義的橋方法“調(diào)用JS”，將點(diǎn)擊事件傳遞給JS線(xiàn)程進(jìn)行處理，緊接著繼續(xù)處理UI線(xiàn)程的任務(wù)，這樣UI線(xiàn)程的交互效率就高了，充分保障了用戶(hù)良好的操作體驗(yàn)。

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

2.2、JSI技術(shù)引入

通訊橋存在的問(wèn)題

動(dòng)態(tài)化基于三個(gè)線(xiàn)程并行運(yùn)行的方式，使其渲染性能已經(jīng)接近于原生的渲染性能，但是在一些頻繁通訊場(chǎng)景，通訊橋會(huì)“堵塞”，比如當(dāng)業(yè)務(wù)需要監(jiān)聽(tīng)一個(gè)頁(yè)面的滑動(dòng)而改變另外一個(gè)元素背景色的透明度，那么JS線(xiàn)程大部分時(shí)間在處理接收列表滑動(dòng)距離，改變?cè)乇尘吧该鞫冗@個(gè)任務(wù)中，其他任務(wù)的執(zhí)行會(huì)被嚴(yán)重影響。另外JSON數(shù)據(jù)傳輸?shù)男蛄谢头葱蛄谢^(guò)程也會(huì)帶來(lái)很大的線(xiàn)程性能損耗。

??

解決方案-JSI

之前使用通訊橋的一個(gè)主要原因就是 C++ 中的函數(shù)沒(méi)辦法完整映射到 JavaScript 中，讓 JavaScript 直接調(diào)用，所以只能選擇以序列化字符串的形式通過(guò)通訊橋傳輸。而JSI做的事情就是將 C++ 中的常用類(lèi)型（函數(shù)、對(duì)象等）一一映射到 JavaScript 中，我們就能在JS中直接調(diào)用C++的函數(shù)和對(duì)象了。因?yàn)橄藰蛲ㄓ崕?lái)的序列化和異步調(diào)用的開(kāi)銷(xiāo)，大大提升了線(xiàn)程通訊性能。

??

四、進(jìn)一步優(yōu)化的方向

1、減少UI層級(jí)

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

@Componentexport 
struct RomaDiv 
{ 
    build()
    { 
        Stack(){
         //借助wrapBuilder實(shí)現(xiàn)遞歸 
         ForEach(this.childrenTags, (childrenTag) => 
             { 
                 RomaComponentFactory.builder()//RomaComponentFactory就是對(duì)應(yīng)鴻蒙系統(tǒng)提供的WrappedBuilder 
             }) 
         } 
    } 
}

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

2、降低通訊成本

當(dāng)前JSI在鴻蒙系統(tǒng)的應(yīng)用中通過(guò)JSI打通C++，再通過(guò)NAPI從C++打通ArkTS，跨語(yǔ)言通訊成本高。如果接入了C-API，就避免了C++和ArkTS之間類(lèi)型互相轉(zhuǎn)換和跨語(yǔ)言調(diào)用的開(kāi)銷(xiāo)，也能帶來(lái)不少的性能提升。

3、JS邏輯下沉到C++

在當(dāng)前架構(gòu)中，JS線(xiàn)程運(yùn)行著V-Dom樹(shù)創(chuàng)建、對(duì)比，樣式&屬性解析等一系列繁重的框架邏輯，如果我們能將這些JS代碼邏輯下沉到C++，框架邏輯運(yùn)行效率會(huì)進(jìn)一步提升。

總結(jié)

本文講述了如何在鴻蒙系統(tǒng)中實(shí)現(xiàn)“動(dòng)態(tài)化”跨端框架的高性能運(yùn)行。包含探索方舟虛擬機(jī)運(yùn)行方案時(shí)遇到的問(wèn)題，以及基于V8虛擬機(jī)方案的具體提升手段和后續(xù)進(jìn)一步提升的方案。通過(guò)閱讀，你將能夠更好地理解和應(yīng)用這些技術(shù)，提高跨端框架的性能，提升C端用戶(hù)體驗(yàn)。

審核編輯 黃宇