作者；京東零售 李偉濤

背景

純血鴻蒙逐漸成為全球第三大操作系統，業界也掀起了適配鴻蒙原生的浪潮，用戶遷移趨勢明顯，京東作為國民應用，為鴻蒙用戶提供完整的購物體驗至關重要。

去年 9 月，京東 APP 純血鴻蒙 在鴻蒙應用商城正式上線，APP 中核心購物鏈路，如首頁、搜索、商詳、購物車、訂單、結算和我京等頁面，都是通過 Taro on Harmony 方案進行開發，并且一上線就獲得了華為的 S 級應用認證。

Taro 介紹

Taro 是由京東發起并維護的開放式跨端跨框架解決方案，支持以 Web 的開發范式來實現小程序、H5、原生 APP 的跨端統一開發，從 18 年開源至今，在 GitHub 已累計獲得 36,000+ Stars。

在過去的一年中，Taro 完成了鴻蒙適配方案的開發，Taro on Harmony 方案支持開發者使用 React DSL 來快速開發高性能原生鴻蒙應用，讓 Taro 具備了一份代碼同時跨鴻蒙、小程序、H5、React Native 多端的能力，可以讓開發者以熟悉的方式來開發鴻蒙應用，大幅降低鴻蒙開發門檻，并且存量的 Taro 業務也能快速轉成鴻蒙原生應用，可以節約大量研發成本。

Taro on Harmony 適配方案的演進

基于 ArkTS 的初始版本

Taro 適配鴻蒙方案經過了多個版本的演進迭代，最初版本我們采用的是對接到鴻蒙原生 ArkTS 語言的方式來實現，這和 Taro 適配微信小程序的方案類似，都是通過模擬瀏覽器 DOM/BOM 環境，然后運行 React 代碼構建出虛擬 DOM 樹，再將虛擬 DOM 樹以遞歸遍歷的方式構建出宿主環境（小程序/鴻蒙）的渲染節點樹，從而實現頁面渲染。

但這個方案的缺陷非常明顯，那就是在 ArkTS 之上再橋接一層轉換，導致性能相比原生存在一定差異，并且這個差異幾乎沒有辦法可以抹平。

基于 C API 的全新版本

恰逢此時，鴻蒙為了方便三方框架與應用接入鴻蒙生態，在官方開發語言 ArkTS 之外，開放了更底層 C API 能力，提供了 C++ 層的 UI 節點創建、屬性設置等能力（類似于 C++ 版本的 DOM），三方框架和應用可以基于 C API 構建高性能的解決方案和應用。

C API 就是 Taro 想要的能力，與 Taro 的架構完美契合，Taro React 構建出來的虛擬 DOM 樹可以通過 C API 直接去創建原生 UI 節點，省去了很多流程環節，并且可以將我們大部分的渲染管線處理沉到 C++ 中去，獲得飛躍式的性能提升，所以基于 C API 我們首先設計并開發了單線程架構版本。

單線程架構版本

單線程架構版本的示意圖如下，整個渲染過程均在主線程實現，業務代碼在 ArkVM 中執行獲得虛擬 DOM 樹，同時讀取樣式數據，通過 React Reconciler ，在構建虛擬樹時會調用 NAPI 在 C++ 側構建出對應的 Element Tree，同時也會進行樣式數據的解析處理，從而構建出 CSSOM 對象，Element Tree 和 CSSOM 對象會進行匹配從而構建出帶有樣式的 Render Tree，在這一步也會同時創建 yoga 節點，進行布局計算，最后會再基于布局計算的結果生成 C API 的 ArkNode Tree，從而實現上屏渲染。

目前京東鴻蒙 APP 中首頁、搜推、我京、核心購物流程均是使用 Taro 單線程版本進行開發，性能和穩定性位于第一梯隊。

多線程架構版本

單線程版本上線之后，我們也發現了單線程架構的不足，① 從業務代碼的執行到渲染流程的處理都發生在主線程上，這導致了主線程的過載，使得應用無法及時響應用戶的操作，從而引發了用戶體驗上的卡頓，隨著業務邏輯的增加和復雜性的提升，這種卡頓現象會越發明顯；② 在單線程架構下，代碼都是需要內置到應用包里，這樣就無法實現業務代碼的動態下發更新。

所以，為了解決以上問題，進一步提升應用性能，和應對未來更多業務場景需求的可能性，我們實現了多線程架構。

相較于單線程架構，多線程架構將整個業務代碼執行和渲染的過程拆分到了三個線程，每個線程各司其職，讓任務的執行更加合理，不會造成主線程的堵塞，這樣的架構主要帶來三個好處。

1.業務邏輯不再堵塞主流程，完全剝離到了單獨的線程執行，之前容易出現卡頓、甚至 APP Freeze 的頁面基本不再有問題，例如商詳接入之后滑動頁面變得更加流暢；

2.動畫執行和渲染不再卡頓，動畫的執行交由 Background 線程管控，不再和 JS 線程有沖突問題，動畫支持滿幀渲染；

3.支持動態化的能力，在性能上可以與原生相媲美，同時還能支持動態下發，支持更新遠端 JS 資源來實現 APP 內容的更新，讓業務具備快速驗證和免發版的能力。

目前多線程版本正在我們的業務中進行試點接入，很快就會正式上線。

Taro on Harmony 方案特性

豐富的能力支持

常用組件和 API 支持

在 C-API 版本的 Taro For Harmony 中，我們不僅完整支持了 React 18+，另外支持了 View、Text、Image、Video 等近 33 個 Taro 組件，對于常用的 API，如 getSystemInfo、getStorage 等也是在 C-API 版本中得到了完整的支持，而且針對邏輯較為復雜的 API 如：createSelectorQuery 以及 createIntersectionObserver，我們將這些 API 在 C++ 側進行了重新的實現，大幅提升了他們的執行性能。

常用樣式支持

在 C-API 版本中，我們對支持了大部分常見的 CSS 能力：

?支持常見的 CSS 樣式和布局，支持 flex、偽類和偽元素

?支持常見的 CSS 定位，絕對定位、fixed 定位

?支持常見的 CSS 選擇器和媒體查詢

?支持常見的 CSS 單位，比如 vh、vw 以及計算屬性 calc

?支持 CSS 變量以及安全區域等預定義變量

同時，我們參考瀏覽器 CSSOM 的實現方式，在 C++ 實現了一套 CSSOM 邏輯，里面包含了樣式解析、樣式匹配、樣式合成和應用整個鏈路的樣式處理邏輯。

另外，Taro 引入了 Yoga 布局引擎來計算渲染節點的位置和大小，最大程度保證 Taro 構建出來的鴻蒙應用中渲染樣式和 W3C 規范的一致性。

媲美原生 ArkTS 的高性能

運行時邏輯下沉至 C++

在 C-API 的版本中，我們將 ArkVM 層的 Taro 運行時內容削減到極致的薄，將 TaroElement 的大部分內容都下沉到了 C++ 側，并在 ArkVM 層取消了他們之間父子關系的綁定，極大地提升了 TaroElement 相關邏輯的性能。

另一方面，在 C++ 側 Taro 會指令式地調用 ArkUI 在 C++ 側提供的 API，來高效地創建節點、設置屬性、綁定事件以及繪制上屏。

提供長列表組件應對長列表場景

Taro 還針對長列表場景針對性地提供了長列表類型組件，并對長列表類型組件進行了優化，提供了懶加載、預加載和節點復用等功能，有效地解決大數據量下的性能問題，提高應用的流暢度和用戶體驗。

支持 C API 混合原生的渲染模式

Taro 的組件和 API 是以小程序作為基準來進行設計的，因此在實際的鴻蒙應用開發過程中，會出現部分所需的組件和 API 在 Taro 中不存在的情況，因為針對這種情況，在 C-API 版本中，Taro 提供了原生混合開發的能力，支持將原生頁面或者原生組件混合編譯到 Taro 鴻蒙項目中，支持 Taro 組件和鴻蒙原生組件在頁面上的混合使用。

總結

Taro 鴻蒙方案基于鴻蒙 CAPI 進行構建，實現了將 React DSL 直接對接到 C++ 側來運行整體渲染管線，從而實現了與原生齊平的渲染性能，同時 Taro 鴻蒙方案是多線程架構的方案，在應用渲染性能、操作響應時延上都在業界做到極致，并且 Taro 鴻蒙方案支持動態更新，是行業首創且經過大規模 APP 應用場景驗證的開發框架，綜合性能、生態以及開發體驗來講，毫無疑問已經成為了開發鴻蒙應用的最佳框架選型之一。

目前，我們也仍然在不斷完善著鴻蒙的適配方案，目前在渲染性能提升方面我們正在進行 React C++ 化的探索，整體進展也已經處于驗證和測試階段，同時也在進行自研布局引擎的探索，在進一步提升渲染性能的同時，為業務提供更豐富的樣式寫法支持；此外，在開發效率提升方面，我們也正在進行開發調試工具的探索開發，為業務提供熱重載、源碼定位、斷點調試、元素審查等能力，提升效率和開發體驗。

在近期，我們會將已經在京東鴻蒙 APP 久經考驗的單線程架構版本開源出來，為開源社區貢獻一份力量，為鴻蒙應用生態的豐富注入強大的動力。

審核編輯 黃宇