2025 年 6 月，在華為開發(fā)者大會 2025 開發(fā)者場景技術(shù)共建分論壇，本文作者進行了《京東 Taro 框架鴻蒙版本正式開源 助力鴻蒙版三方應用開發(fā)》專題演講。期間闡述了 Taro on HarmonyOS 的技術(shù)實現(xiàn)方案、核心優(yōu)化策略，以及開源版本的主要特性。

本文將詳細介紹 Taro on HarmonyOS 的技術(shù)架構(gòu)、性能優(yōu)化實踐和開源進展，分享我們在跨端開發(fā)中遇到的問題和解決思路。

期待更多人可以參與開源共建，一起交流討論！

背景

回顧 Taro 的發(fā)展歷程，從 2018 年 6 月開源至今，作為開放式的跨端跨框架解決方案在眾多熱心開源貢獻者的支持下，從初出茅廬逐步邁向成熟。

從最初僅支持面向編譯時的小程序端解決方案，到如今擁有支持多種前端框架和 UI 庫的強大能力；從單一的構(gòu)建工具，到通過開放生態(tài)為開發(fā)者提供 Webpack、Vite、ESBuild 等豐富的工具選擇，讓團隊能夠定制專屬的研發(fā)流程；從專注小程序開發(fā)，到覆蓋各大小程序平臺以及 Web、iOS、Android、HarmonyOS 等移動端場景——Taro 的每一步成長都離不開社區(qū)的力量。

這些年來，我們在 GitHub 上收獲了 36,000+ star 和近 5,000 fork，更重要的是得到了眾多企業(yè)團隊和個人開發(fā)者貢獻的寶貴功能特性。在此，我們要向所有支持 Taro 發(fā)展的朋友們表示衷心的感謝！

技術(shù)架構(gòu)演進

說到 HarmonyOS，Taro 從 2022 年開始布局鴻蒙適配，走過了一條持續(xù)演進的技術(shù)路徑。最初我們推出了 JSUI 版本的端平臺插件，為鴻蒙支持打下基礎(chǔ)；2023 年開源了 ETS 版本的端平臺插件，大幅提升了開發(fā)體驗和業(yè)務性能；而在最近釋出的 4.1 版本中，C-API 版本的 Harmony 端平臺插件也正式發(fā)布了，這標志著 Taro 鴻蒙支持能力的重要突破。

目前，我們?nèi)栽诔掷m(xù)優(yōu)化 Harmony C-API 插件的性能表現(xiàn)。團隊正在推進多線程以及更多版本特性的內(nèi)部驗證，期待在驗證完成后能夠?qū)⑵溟_源，為開發(fā)者在鴻蒙端帶來更優(yōu)秀的研發(fā)體驗。

面向多端研發(fā)

面向多端的復雜場景，從來都不是一件容易的事情。在傳統(tǒng)的多端開發(fā)中，開發(fā)者往往需要面對各端語法標準不統(tǒng)一、組件和 API 接口各異、開發(fā)環(huán)境復雜多樣等諸多挑戰(zhàn)。當業(yè)務邏輯需要調(diào)整時，開發(fā)者必須在多個平臺上重復實現(xiàn)相同功能，代碼復用率極低，維護工作量成倍增長。

如圖所示，Taro 現(xiàn)已成功在 HarmonyOS 平臺上實現(xiàn)了與 Web 端、小程序及其他平臺一致的 UI 呈現(xiàn)效果。

基于 Taro 跨端研發(fā)標準推進業(yè)務實現(xiàn)，開發(fā)者只需編寫一套代碼，就能夠在多個平臺上獲得統(tǒng)一的用戶體驗，最大限度地節(jié)省多端業(yè)務的研發(fā)成本，讓團隊能夠?qū)⒏嗑ν度氲綐I(yè)務創(chuàng)新上。

京東鴻蒙版

以京東鴻蒙版本為例，基于 Taro on HarmonyOS 解決方案，成功在研發(fā)效率與應用性能之間達成了理想平衡，其性能表現(xiàn)和穩(wěn)定性均位居行業(yè)前列。

對于商品詳情頁等高復雜度、高數(shù)據(jù)量的核心業(yè)務場景，該方案展現(xiàn)出強大的技術(shù)適配能力。僅是在單線程 C-API 架構(gòu)的支持下，這些重載業(yè)務場景的運行性能已達到與原生應用相當?shù)乃疁剩浞烛炞C了跨端技術(shù)在復雜場景下的可行性。

技術(shù)架構(gòu)

為了達成這一目標，我們需要在技術(shù)架構(gòu)層面進行深度優(yōu)化。

Taro 在各平臺的適配邏輯保持高度一致性。開發(fā)者通過統(tǒng)一的 DSL以及標準化的組件和 API 庫即可完成全部代碼開發(fā)，樣式規(guī)范完全遵循 W3C 標準，使前端開發(fā)者能夠以極低的學習成本快速上手。

在編譯層面，Taro 通過 CLI 工具和插件系統(tǒng)實現(xiàn)各端的差異化處理。各個端平臺插件可以在編譯核心中選擇基于 Webpack、Vite 或 Metro 為基礎(chǔ)的編譯流程，將開發(fā)者的源代碼高效轉(zhuǎn)換為各目標平臺的可執(zhí)行代碼。

在運行時中，通過集成語法適配器、DOM、BOM 模擬實現(xiàn)以及其他核心模塊，確保開發(fā)者項目能夠在 HarmonyOS 等各類平臺上穩(wěn)定運行，真正實現(xiàn)一碼多端的開發(fā)愿景。

渲染層適配

盡管 Taro 在 HarmonyOS 平臺的插件架構(gòu)歷經(jīng)多輪重大版本升級，但其核心架構(gòu)設計依舊可從以下幾個維度來理解：

代碼轉(zhuǎn)換流程：從開發(fā)者編寫的 React 代碼出發(fā)，通過與 React Reconciler 的深度集成，系統(tǒng)構(gòu)建出完整的虛擬節(jié)點樹。隨后，運行時環(huán)境通過模擬的 DOM 和 BOM API，實現(xiàn) React 節(jié)點樹與 Taro 內(nèi)部節(jié)點樹的精確映射。

平臺適配實現(xiàn)：結(jié)合標準化的組件庫和 API 庫，系統(tǒng)將抽象的節(jié)點結(jié)構(gòu)轉(zhuǎn)換為 HarmonyOS 平臺的原生原子組件，最終構(gòu)建出完整的 ArkUI 渲染樹，并呈現(xiàn)在用戶界面上。

擴展能力支持：除了核心渲染流程外，運行時還集成了布局計算、事件處理、動畫效果等關(guān)鍵模塊，并持續(xù)接入更多 HarmonyOS 平臺特有能力，為開發(fā)者提供完整的跨平臺開發(fā)體驗。

架構(gòu)方案迭代

在技術(shù)架構(gòu)層面，ETS 方案與 C-API 方案本質(zhì)上都遵循著相同的設計理念。兩者均構(gòu)建了一套完整的三層節(jié)點樹體系：應用層的 React 節(jié)點樹首先轉(zhuǎn)換為中間層的 Taro 節(jié)點樹，隨后進一步映射到底層的 ArkUI 節(jié)點樹，最終實現(xiàn)界面的完整渲染。

然而，盡管在宏觀架構(gòu)上兩種方案展現(xiàn)出高度的相似性，我們?nèi)匀粓远ǖ赝七M從 ETS 向 C-API 的技術(shù)轉(zhuǎn)型。這一決策的背后，是團隊對性能極致追求的不懈努力。在移動應用開發(fā)的激烈競爭中，每一毫秒的性能提升都可能成為用戶體驗的關(guān)鍵差異點，而 C-API 方案正是在這樣的背景下應運而生的技術(shù)選擇。

C-API 方案帶來的性能提升是全方位的。在節(jié)點操作層面，我們徹底摒棄了傳統(tǒng)的聲明式遞歸構(gòu)建模式，轉(zhuǎn)而采用更加靈活的實現(xiàn)方式，這為底層節(jié)點 API 的深度優(yōu)化創(chuàng)造了前所未有的空間。同時，通過引入指令式節(jié)點操作機制，不同節(jié)點樹之間的數(shù)據(jù)交互效率得到了顯著改善，原本復雜的跨樹通信變得更加高效流暢。

更為重要的是，我們將樣式處理、布局計算、事件管理等核心功能模塊全面下沉至 C++ 原生層。這一架構(gòu)調(diào)整不僅大幅減少了跨語言調(diào)用的頻次和開銷，更從根本上提升了系統(tǒng)的執(zhí)行效率。通過這些多維度的優(yōu)化措施，整個應用的性能表現(xiàn)實現(xiàn)了質(zhì)的飛躍。

跨端研發(fā)標準

在適配鴻蒙和其他各端能力的基礎(chǔ)上，Taro 正在構(gòu)建一套完整的跨端研發(fā)標準體系。這套標準不僅能夠最大限度地節(jié)約不同端之間的適配成本，更重要的是能夠充分兼容現(xiàn)有的前端生態(tài)系統(tǒng)，讓團隊多年積累的組件庫、工具鏈和技術(shù)沉淀得以無縫復用。

目前，以 React 作為 UI 基礎(chǔ)庫，該標準已涵蓋了 View、Text 等 26 個常用組件和網(wǎng)絡請求、圖片等 88 個常用 API。在樣式規(guī)范方面，我們遵循 W3C 標準實現(xiàn)了包含 93 條常用規(guī)范的樣式子集。與此同時，我們正在持續(xù)努力擴充這套標準體系，不斷增加新的組件類型、API 接口和樣式規(guī)范，以滿足日益復雜的業(yè)務場景需求。

更為關(guān)鍵的是，這套不斷完善的標準體系具備良好的擴展性和兼容性，能夠與團隊現(xiàn)有的 UI 組件庫、業(yè)務組件以及各類前端工具庫形成有機整合。我們致力于通過標準的持續(xù)演進，確保開發(fā)團隊能夠在跨端開發(fā)中充分發(fā)揮既有技術(shù)資產(chǎn)的價值，避免重復建設帶來的資源浪費，同時為未來更多端側(cè)適配需求預留充足的擴展空間。

為實現(xiàn)跨平臺開發(fā)的一致性標準，我們設計了 C++ 底層樣式處理架構(gòu)。該架構(gòu)整合了包括 Yoga 這類成熟布局引擎，構(gòu)建統(tǒng)一的布局計算體系，保障各端樣式渲染的視覺一致性。通過將樣式計算邏輯完全遷移至 C-API 底層，系統(tǒng)獲得了顯著的性能優(yōu)化潛力——不僅消除了對主渲染線程和業(yè)務邏輯的性能干擾，還通過 C++ 的高效執(zhí)行特性實現(xiàn)了跨端樣式處理的統(tǒng)一化管理，從根本上提升了整體渲染效率。

針對鴻蒙端的特殊需求，我們在編譯階段引入了創(chuàng)新的預處理機制。通過在編譯流程中的 Rust 插件集成 lightingCSS，我們能夠?qū)藴蕵邮筋A先轉(zhuǎn)換為鴻蒙平臺可以識別的樣式，進一步節(jié)省運行時運算的負擔。這一機制不僅實現(xiàn)了 W3C 標準屬性到各端專用單位和屬性值的智能轉(zhuǎn)換，更為跨端樣式的統(tǒng)一管理奠定了堅實的底層基礎(chǔ)。

基于這套完善的 C++ 樣式處理體系，UI 庫和業(yè)務團隊能夠輕松應對各種復雜場景的適配需求。無論是折疊屏的多形態(tài)展示、關(guān)懷模式的無障礙優(yōu)化，還是暗黑模式的主題切換，都可以通過靈活的樣式選擇器機制實現(xiàn)精準控制。同時，動畫效果和過渡轉(zhuǎn)場也能夠通過高效的樣式更新和節(jié)點刷新機制，呈現(xiàn)出極為流暢的用戶體驗。

方案特性

基于此架構(gòu)，Taro on HarmonyOS 方案積累了豐富的核心特性。

研發(fā)效能層面：通過兼容 React 生態(tài)體系和 W3C 樣式規(guī)范，開發(fā)者能夠充分利用前端成熟的工具鏈和生態(tài)資源，高效完成業(yè)務功能迭代與開發(fā)調(diào)試工作，完善鴻蒙端的開發(fā)體驗。同時，開發(fā)者編寫的樣式代碼可在鴻蒙、小程序和 Web 端無縫復用，實現(xiàn)真正的"一次編寫，多端運行"。

生態(tài)擴展層面：提供靈活的組件和 API 擴展機制，支持業(yè)務團隊根據(jù)實際需求定制運行時環(huán)境。更重要的是，通過跨端統(tǒng)一的原生混合調(diào)用方案，Taro C++ 模塊與 ArkTS 原生模塊可實現(xiàn)雙向互調(diào)，為團隊間協(xié)作提供了更多可能性，有效避免重復開發(fā)，提升整體研發(fā)效率。

性能體驗

在 C-API 方案中，我們圍繞卓越性能體驗實現(xiàn)了多項核心特性：

運行時性能優(yōu)化

將 DOM Tree、事件處理、樣式計算等高頻操作模塊完全下沉至 C++ 層，顯著提升運行時執(zhí)行效率。通過底層優(yōu)化，減少了 JavaScript 與原生層之間的頻繁通信開銷，避免了數(shù)據(jù)序列化/反序列化的性能損耗。同時，C++ 層的內(nèi)存管理更加高效，能夠更好地控制對象生命周期，減少內(nèi)存碎片，為復雜應用場景提供更穩(wěn)定的性能表現(xiàn)。

高階組件能力

基于 HarmonyOS 原生的 List、WaterFlow 等組件特性，深度定制實現(xiàn)虛擬列表、瀑布流等高性能組件，充分發(fā)揮系統(tǒng)級優(yōu)勢。

這些高階組件不僅繼承了系統(tǒng)組件的原生性能，還針對前端開發(fā)習慣進行了接口封裝，支持動態(tài)數(shù)據(jù)加載、智能緩存策略、滾動性能優(yōu)化等特性。開發(fā)者可以像使用傳統(tǒng)前端組件一樣輕松實現(xiàn)大數(shù)據(jù)量的列表展示，無需關(guān)心底層的復雜優(yōu)化邏輯。

圖片處理模塊

構(gòu)建專門服務于樣式渲染、背景繪制、Image 組件的圖片處理系統(tǒng)，實現(xiàn)更優(yōu)秀的圖片加載性能和內(nèi)存管理。該模塊集成了多級緩存機制，支持內(nèi)存緩存、磁盤緩存和網(wǎng)絡緩存的智能調(diào)度，大幅減少重復加載時間。

同時提供了圖片壓縮、格式轉(zhuǎn)換、尺寸適配等功能，能夠根據(jù)設備性能和網(wǎng)絡狀況自動選擇最優(yōu)的圖片處理策略，有效降低內(nèi)存占用和網(wǎng)絡帶寬消耗。

文字與繪圖支持

通過 PixelMap 技術(shù)為文字組件提供豐富的字體屬性和渲染能力，同時為 Canvas 組件及相關(guān) API 提供底層支持，覆蓋分享海報生成等復雜業(yè)務繪制場景。文字渲染支持多種字體格式、文字效果（陰影、描邊、漸變等）和排版布局，滿足不同設計需求。

Canvas 繪圖能力則支持路徑繪制、圖形變換、濾鏡效果等高級功能，為數(shù)據(jù)可視化、游戲開發(fā)、創(chuàng)意設計等場景提供強大的圖形處理能力。

視頻播放能力

基于 AVPlayer 重構(gòu) Video 組件和相關(guān) API 實現(xiàn)，在 C-API 層直接接入，減少調(diào)用鏈路，為業(yè)務提供更靈活的視頻適配方案。新的視頻播放架構(gòu)支持多種視頻格式和編碼標準，提供了精確的播放控制、實時進度反饋、音視頻同步等核心功能。

總結(jié)展望

Taro 在 HarmonyOS 平臺的深度適配，旨在為全場景應用開發(fā)開辟新的技術(shù)路徑。通過構(gòu)建完善的鴻蒙端能力體系，我們致力于為更廣泛的業(yè)務場景提供技術(shù)支撐，推動跨平臺開發(fā)在鴻蒙生態(tài)中的創(chuàng)新應用。

在實際應用中，Taro 成功支撐了京東鴻蒙 APP 的商業(yè)化落地。該應用的首頁、搜索推薦以及核心購物流程等關(guān)鍵業(yè)務模塊均基于 Taro 技術(shù)棧開發(fā)，在確保快速迭代交付的同時，實現(xiàn)了業(yè)界領(lǐng)先的性能表現(xiàn)和系統(tǒng)穩(wěn)定性。應用上線后迅速在華為應用市場購物類別中登頂，充分驗證了技術(shù)方案的商業(yè)價值。

生態(tài)建設與合作拓展

基于成功實踐的示范效應，更多京東生態(tài)應用正在加速鴻蒙化進程，包括一號會員店、七鮮等重要業(yè)務線的鴻蒙版本已上架鴻蒙應用市場或者進入開發(fā)階段。同時，我們的技術(shù)方案也獲得了外部合作伙伴的認可，58同城、樸樸超市等知名企業(yè)均選擇采用 Taro 相關(guān)的鴻蒙開發(fā)解決方案，共同構(gòu)建更加繁榮的鴻蒙應用生態(tài)。

未來展望

我們將持續(xù)深化開源戰(zhàn)略，在內(nèi)部版本充分驗證后，逐步向社區(qū)開放多線程等更多核心技術(shù)特性。同時不斷擴展跨端標準覆蓋范圍，讓更多組件和 API 實現(xiàn)跨平臺一致性，為開發(fā)者提供更優(yōu)質(zhì)的開發(fā)體驗和更完善的調(diào)試工具鏈，也為動態(tài)化能力構(gòu)建更堅實的技術(shù)基礎(chǔ)。

在性能優(yōu)化方面，我們將持續(xù)推進更多核心模塊向 C++ 層遷移，包括 React 的 C++ 版本實現(xiàn)和高頻 API 運行時模塊優(yōu)化，同時積極借鑒節(jié)點樹扁平化等社區(qū)驗證的優(yōu)秀實踐。

雖然 Taro on HarmonyOS 的 C-API 版本插件開源時間不長，但已經(jīng)吸引了眾多開發(fā)者的積極參與。我們期待更多技術(shù)同仁能夠加入這個充滿活力的開源生態(tài)，共同推動 Taro on HarmonyOS 方案的不斷完善，在開源共建的道路上續(xù)寫跨端開發(fā)的新篇章。

審核編輯 黃宇