Taro on HarmonyOS 技术架构深度解析

2025 年 6 月,在华为开发者大会 2025 开发者场景技术共建分论坛,本文作者进行了《京东 Taro 框架鸿蒙版本正式开源 助力鸿蒙版三方应用开发》专题演讲。期间阐述了 Taro on HarmonyOS 的技术实现方案、核心优化策略,以及开源版本的主要特性。

本文将详细介绍 Taro on HarmonyOS 的技术架构、性能优化实践和开源进展,分享我们在跨端开发中遇到的问题和解决思路。

期待更多人可以参与开源共建,一起交流讨论!


背景

回顾 Taro 的发展历程,从 2018 年 6 月开源至今,作为开放式的跨端跨框架解决方案在众多热心开源贡献者的支持下,从初出茅庐逐步迈向成熟。

从最初仅支持面向编译时的小程序端解决方案,到如今拥有支持多种前端框架和 UI 库的强大能力;从单一的构建工具,到通过开放生态为开发者提供 WebpackViteESBuild 等丰富的工具选择,让团队能够定制专属的研发流程;从专注小程序开发,到覆盖各大小程序平台以及 Web、iOS、Android、HarmonyOS 等移动端场景------Taro 的每一步成长都离不开社区的力量。

这些年来,我们在 GitHub 上收获了 36,000+ star近 5,000 fork,更重要的是得到了众多企业团队和个人开发者贡献的宝贵功能特性。在此,我们要向所有支持 Taro 发展的朋友们表示衷心的感谢!

技术架构演进

说到 HarmonyOS,Taro 从 2022 年开始布局鸿蒙适配,走过了一条持续演进的技术路径。最初我们推出了 JSUI 版本的端平台插件,为鸿蒙支持打下基础;2023 年开源了 ETS 版本的端平台插件,大幅提升了开发体验和业务性能;而在最近释出的 4.1 版本中,C-API 版本的 Harmony 端平台插件也正式发布了,这标志着 Taro 鸿蒙支持能力的重要突破。

目前,我们仍在持续优化 Harmony C-API 插件的性能表现。团队正在推进多线程以及更多版本特性的内部验证,期待在验证完成后能够将其开源,为开发者在鸿蒙端带来更优秀的研发体验。

面向多端研发

面向多端的复杂场景,从来都不是一件容易的事情。在传统的多端开发中,开发者往往需要面对各端语法标准不统一、组件和 API 接口各异、开发环境复杂多样等诸多挑战。当业务逻辑需要调整时,开发者必须在多个平台上重复实现相同功能,代码复用率极低,维护工作量成倍增长。

如图所示,Taro 现已成功在 HarmonyOS 平台上实现了与 Web 端、小程序及其他平台一致的 UI 呈现效果。

基于 Taro 跨端研发标准推进业务实现,开发者只需编写一套代码,就能够在多个平台上获得统一的用户体验,最大限度地节省多端业务的研发成本,让团队能够将更多精力投入到业务创新上。

京东鸿蒙版

以京东鸿蒙版本为例,基于 Taro on HarmonyOS 解决方案,成功在研发效率与应用性能之间达成了理想平衡,其性能表现和稳定性均位居行业前列。

对于商品详情页等高复杂度、高数据量的核心业务场景,该方案展现出强大的技术适配能力。仅是在单线程 C-API 架构的支持下,这些重载业务场景的运行性能已达到与原生应用相当的水准,充分验证了跨端技术在复杂场景下的可行性。

技术架构

为了达成这一目标,我们需要在技术架构层面进行深度优化。

Taro 在各平台的适配逻辑保持高度一致性。开发者通过统一的 DSL以及标准化的组件和 API 库即可完成全部代码开发,样式规范完全遵循 W3C 标准,使前端开发者能够以极低的学习成本快速上手。

在编译层面,Taro 通过 CLI 工具和插件系统实现各端的差异化处理。各个端平台插件可以在编译核心中选择基于 WebpackViteMetro 为基础的编译流程,将开发者的源代码高效转换为各目标平台的可执行代码。

在运行时中,通过集成语法适配器、DOMBOM 模拟实现以及其他核心模块,确保开发者项目能够在 HarmonyOS 等各类平台上稳定运行,真正实现一码多端的开发愿景。

渲染层适配

尽管 Taro 在 HarmonyOS 平台的插件架构历经多轮重大版本升级,但其核心架构设计依旧可从以下几个维度来理解:

代码转换流程 :从开发者编写的 React 代码出发,通过与 React Reconciler 的深度集成,系统构建出完整的虚拟节点树。随后,运行时环境通过模拟的 DOMBOM API,实现 React 节点树与 Taro 内部节点树的精确映射。

平台适配实现 :结合标准化的组件库和 API 库,系统将抽象的节点结构转换为 HarmonyOS 平台的原生原子组件,最终构建出完整的 ArkUI 渲染树,并呈现在用户界面上。

扩展能力支持:除了核心渲染流程外,运行时还集成了布局计算、事件处理、动画效果等关键模块,并持续接入更多 HarmonyOS 平台特有能力,为开发者提供完整的跨平台开发体验。

架构方案迭代

在技术架构层面,ETS 方案与 C-API 方案本质上都遵循着相同的设计理念。两者均构建了一套完整的三层节点树体系:应用层的 React 节点树首先转换为中间层的 Taro 节点树,随后进一步映射到底层的 ArkUI 节点树,最终实现界面的完整渲染。

然而,尽管在宏观架构上两种方案展现出高度的相似性,我们仍然坚定地推进从 ETSC-API 的技术转型。这一决策的背后,是团队对性能极致追求的不懈努力。在移动应用开发的激烈竞争中,每一毫秒的性能提升都可能成为用户体验的关键差异点,而 C-API 方案正是在这样的背景下应运而生的技术选择。

C-API 方案带来的性能提升是全方位的。在节点操作层面,我们彻底摒弃了传统的声明式递归构建模式,转而采用更加灵活的实现方式,这为底层节点 API 的深度优化创造了前所未有的空间。同时,通过引入指令式节点操作机制,不同节点树之间的数据交互效率得到了显著改善,原本复杂的跨树通信变得更加高效流畅。

更为重要的是,我们将样式处理、布局计算、事件管理等核心功能模块全面下沉至 C++ 原生层。这一架构调整不仅大幅减少了跨语言调用的频次和开销,更从根本上提升了系统的执行效率。通过这些多维度的优化措施,整个应用的性能表现实现了质的飞跃。

跨端研发标准

在适配鸿蒙和其他各端能力的基础上,Taro 正在构建一套完整的跨端研发标准体系。这套标准不仅能够最大限度地节约不同端之间的适配成本,更重要的是能够充分兼容现有的前端生态系统,让团队多年积累的组件库、工具链和技术沉淀得以无缝复用。

目前,以 React 作为 UI 基础库,该标准已涵盖了 ViewText 等 26 个常用组件和网络请求、图片等 88 个常用 API。在样式规范方面,我们遵循 W3C 标准实现了包含 93 条常用规范的样式子集。与此同时,我们正在持续努力扩充这套标准体系,不断增加新的组件类型、API 接口和样式规范,以满足日益复杂的业务场景需求。

更为关键的是,这套不断完善的标准体系具备良好的扩展性和兼容性,能够与团队现有的 UI 组件库、业务组件以及各类前端工具库形成有机整合。我们致力于通过标准的持续演进,确保开发团队能够在跨端开发中充分发挥既有技术资产的价值,避免重复建设带来的资源浪费,同时为未来更多端侧适配需求预留充足的扩展空间。

为实现跨平台开发的一致性标准,我们设计了 C++ 底层样式处理架构。该架构整合了包括 Yoga 这类成熟布局引擎,构建统一的布局计算体系,保障各端样式渲染的视觉一致性。通过将样式计算逻辑完全迁移至 C-API 底层,系统获得了显著的性能优化潜力------不仅消除了对主渲染线程和业务逻辑的性能干扰,还通过 C++ 的高效执行特性实现了跨端样式处理的统一化管理,从根本上提升了整体渲染效率。

针对鸿蒙端的特殊需求,我们在编译阶段引入了创新的预处理机制。通过在编译流程中的 Rust 插件集成 lightingCSS,我们能够将标准样式预先转换为鸿蒙平台可以识别的样式,进一步节省运行时运算的负担。这一机制不仅实现了 W3C 标准属性到各端专用单位和属性值的智能转换,更为跨端样式的统一管理奠定了坚实的底层基础。

基于这套完善的 C++ 样式处理体系,UI 库和业务团队能够轻松应对各种复杂场景的适配需求。无论是折叠屏的多形态展示、关怀模式的无障碍优化,还是暗黑模式的主题切换,都可以通过灵活的样式选择器机制实现精准控制。同时,动画效果和过渡转场也能够通过高效的样式更新和节点刷新机制,呈现出极为流畅的用户体验。

方案特性

基于此架构,Taro on HarmonyOS 方案积累了丰富的核心特性。

研发效能层面:通过兼容 React 生态体系和 W3C 样式规范,开发者能够充分利用前端成熟的工具链和生态资源,高效完成业务功能迭代与开发调试工作,完善鸿蒙端的开发体验。同时,开发者编写的样式代码可在鸿蒙、小程序和 Web 端无缝复用,实现真正的"一次编写,多端运行"。

生态扩展层面:提供灵活的组件和 API 扩展机制,支持业务团队根据实际需求定制运行时环境。更重要的是,通过跨端统一的原生混合调用方案,Taro C++ 模块与 ArkTS 原生模块可实现双向互调,为团队间协作提供了更多可能性,有效避免重复开发,提升整体研发效率。

性能体验

在 C-API 方案中,我们围绕卓越性能体验实现了多项核心特性:

  1. 运行时性能优化

    将 DOM Tree、事件处理、样式计算等高频操作模块完全下沉至 C++ 层,显著提升运行时执行效率。通过底层优化,减少了 JavaScript 与原生层之间的频繁通信开销,避免了数据序列化/反序列化的性能损耗。同时,C++ 层的内存管理更加高效,能够更好地控制对象生命周期,减少内存碎片,为复杂应用场景提供更稳定的性能表现。

  2. 高阶组件能力

    基于 HarmonyOS 原生的 List、WaterFlow 等组件特性,深度定制实现虚拟列表、瀑布流等高性能组件,充分发挥系统级优势。

    这些高阶组件不仅继承了系统组件的原生性能,还针对前端开发习惯进行了接口封装,支持动态数据加载、智能缓存策略、滚动性能优化等特性。开发者可以像使用传统前端组件一样轻松实现大数据量的列表展示,无需关心底层的复杂优化逻辑。

  3. 图片处理模块

    构建专门服务于样式渲染、背景绘制、Image 组件的图片处理系统,实现更优秀的图片加载性能和内存管理。该模块集成了多级缓存机制,支持内存缓存、磁盘缓存和网络缓存的智能调度,大幅减少重复加载时间。

    同时提供了图片压缩、格式转换、尺寸适配等功能,能够根据设备性能和网络状况自动选择最优的图片处理策略,有效降低内存占用和网络带宽消耗。

  4. 文字与绘图支持

    通过 PixelMap 技术为文字组件提供丰富的字体属性和渲染能力,同时为 Canvas 组件及相关 API 提供底层支持,覆盖分享海报生成等复杂业务绘制场景。文字渲染支持多种字体格式、文字效果(阴影、描边、渐变等)和排版布局,满足不同设计需求。

    Canvas 绘图能力则支持路径绘制、图形变换、滤镜效果等高级功能,为数据可视化、游戏开发、创意设计等场景提供强大的图形处理能力。

  5. 视频播放能力

    基于 AVPlayer 重构 Video 组件和相关 API 实现,在 C-API 层直接接入,减少调用链路,为业务提供更灵活的视频适配方案。新的视频播放架构支持多种视频格式和编码标准,提供了精确的播放控制、实时进度反馈、音视频同步等核心功能。

总结展望

Taro 在 HarmonyOS 平台的深度适配,旨在为全场景应用开发开辟新的技术路径。通过构建完善的鸿蒙端能力体系,我们致力于为更广泛的业务场景提供技术支撑,推动跨平台开发在鸿蒙生态中的创新应用。

在实际应用中,Taro 成功支撑了京东鸿蒙 APP 的商业化落地。该应用的首页、搜索推荐以及核心购物流程等关键业务模块均基于 Taro 技术栈开发,在确保快速迭代交付的同时,实现了业界领先的性能表现和系统稳定性。应用上线后迅速在华为应用市场购物类别中登顶,充分验证了技术方案的商业价值。

生态建设与合作拓展

基于成功实践的示范效应,更多京东生态应用正在加速鸿蒙化进程,包括一号会员店、七鲜等重要业务线的鸿蒙版本已上架鸿蒙应用市场或者进入开发阶段。同时,我们的技术方案也获得了外部合作伙伴的认可,58同城、朴朴超市等知名企业均选择采用 Taro 相关的鸿蒙开发解决方案,共同构建更加繁荣的鸿蒙应用生态。

未来展望

我们将持续深化开源战略,在内部版本充分验证后,逐步向社区开放多线程等更多核心技术特性。同时不断扩展跨端标准覆盖范围,让更多组件和 API 实现跨平台一致性,为开发者提供更优质的开发体验和更完善的调试工具链,也为动态化能力构建更坚实的技术基础。

在性能优化方面,我们将持续推进更多核心模块向 C++ 层迁移,包括 React 的 C++ 版本实现和高频 API 运行时模块优化,同时积极借鉴节点树扁平化等社区验证的优秀实践。

虽然 Taro on HarmonyOS 的 C-API 版本插件开源时间不长,但已经吸引了众多开发者的积极参与。我们期待更多技术同仁能够加入这个充满活力的开源生态,共同推动 Taro on HarmonyOS 方案的不断完善,在开源共建的道路上续写跨端开发的新篇章。

相关推荐
JustTest1 小时前
Mac mini初始安装软件记录
程序员
SimonKing2 小时前
轻量级富文本编辑器Quill,保姆级教程,5分钟快速上手
java·后端·程序员
文心快码BaiduComate17 小时前
Comate搭载Kimi K2.6,长程13h!
前端·后端·程序员
图图玩ai20 小时前
SSH 命令管理工具怎么选?从命令收藏到批量执行一次讲清
linux·nginx·docker·ai·程序员·ssh·可视化·gmssh·批量命令执行
SamDeepThinking1 天前
程序员懂业务,到底要懂到什么程度
后端·程序员·团队管理
盖世英雄酱581361 天前
java技术博主停更3个月了???
程序员
DyLatte1 天前
我做了个AI项目后才发现:会做事的人,正在输给会讲故事的人
前端·后端·程序员
SimonKing1 天前
别让你的代码裸奔!Spring Boot混淆全攻略(附配置)
java·后端·程序员
前端双越老师1 天前
为什么我现在不安装 Hermes Agent
程序员·agent
怕浪猫2 天前
程序员越想转型AI,越不要只盯着技术
程序员