
背景
Taro跨端生态已支持 H5、小程序、鸿蒙平台跨端能力,希望在iOS、Android 端实现高性能容器,实现一码五端的技术愿景。
为什么要自研:业界现有跨端方案无法满足诉求
目前行业内主流技术方案无法同时满足高性能、高稳定性、兼容 Taro生态、原生互操作性高、接入成本低的诉求:
高性能:性能接近原生以满足核心场域高性能诉求(首屏性能、FPS、内存消耗)。高稳定性:可使用在订单、购物车、搜索等核心场域,对崩溃率、OOM率等质量指标要求严格。Taro生态兼容:兼容 Taro 生态支持代码多端复用(小程序/鸿蒙)。高跨端一致性面向开发(适配成本低)、面向用户(视觉/交互一致)。原生互操作性:支持嵌入现有原生组件、被嵌入到现有原生页面中、和原生保持渲染时机一致、视觉表现(文本/边框等)一致、解决原生手势/滚动冲突。低接入成本:可复用原生生态能力(现有基建API等)、包体积增量小。
跨端方案对比
| 维度 | H5/小程序 | React Native | Flutter | KMP (Kotlin Multiplatform) |
|---|---|---|---|---|
| 性能 | 低/中(H5首屏性能差、内存消耗更高/JSBridge序列化成本高) |
中(性能比原生差) |
高(性能仅次于原生、内存消耗更高) |
高(性能仅次于原生、iOS内存消耗更高) |
| 跨端支持 | iOS、Android、鸿蒙 | iOS、Android(鸿蒙无标准方案) |
iOS、Android(鸿蒙无标准方案) |
iOS、Android(鸿蒙无标准方案) |
| Taro生态兼容 | 高 | 中(可部分兼容生态) |
无法兼容生态 |
无法兼容生态 |
| 原生互操作性 | 低(嵌入现有原生组件做同层渲染、嵌入到原生页面、无法解决和原生渲染时机/视觉不一致、手势/滚动冲突等问题) |
高 | 中(嵌入现有原生组件做纹理渲染、嵌入到原生页面、无法解决和原生渲染时机/视觉不一致、手势/滚动冲突等问题) |
中(嵌入现有原生组件做纹理渲染、嵌入到原生页面、iOS无法解决和原生渲染时机/视觉不一致、手势/滚动冲突等问题) |
| 跨端一致性 | 高(WebView渲染) | 中(原生组件存在不一致的问题) |
高(Skia自绘制) | 中(iOS Skia自绘制、Android原生组件) |
| 接入成本 | 低(WebView系统内置) | 中 | 高(包体积大Dart、Skia) |
高(包体积大Skia、iOS Kotlin Runtime) |
| 稳定性 | 高 | 中(社区维护issues比较多) |
低(社区维护issues很多) |
中(官方维护、iOS渲染暂未稳定) |
| DSL/编程语言 | HTML/CSS + JS | React + JS | FlutterWidget + Dart | ComposeUI + Kotlin |
| 渲染方式 | WebView | 原生View | Skia | Android原生View、iOS Skia |
在上述技术要求和约束下通过iOS渲染层、TaroUI解决 Taro跨端生态的技术挑战:
- iOS渲染层:
高性能、原生互操作性好的渲染层实现。 - TaroUI(跨端 UI):
高跨端一致性、 Taro生态兼容、支持多端扩展/可复用的跨端 UI基座能力。
iOS - 高性能渲染层
Taro框架通过引入
JS引擎、React框架、复杂CSS解析器等能力帮助业务提高开发效率。但引入这些特性理论上在逻辑执行上相比原生会带来更多的性能损耗。Taro需要实现一套相比原生更高性能的渲染方案,同时需要支持和原生互操作友好的渲染方案。
渲染容器架构设计:引擎、视图容器解耦
Taro采用双线程渲染管线和视图容器/渲染逻辑解耦的架构,可极大提升首屏渲染性能同时提供更丰富的预热能力。同时在未来可以更好地适用于不同业务场景。

双线程渲染管线:采用双线程渲染管线设计最大化利用现代设备多核 CPU能力提高渲染性能。JS线程(业务逻辑执行、 DOM节点操作、动画处理、渲染树构建、布局计算等)。UI主线程(原生视图操作、布局设置、属性/样式设置、文本渲染等)。首屏并行化渲染:首屏加载支持UI主线程和JS线程双线程并行执行提高首屏加载性能,业务无需针对双线程编写不同代码即可获得优益的性能。高可预热设计:渲染逻辑和视图容器解耦的设计,在支持最大化预热优化首屏耗时的同时避免真实上屏渲染降低内存消耗。为下一阶段对外提供更多预热能力打下基础,例如引擎预创建、逻辑预加载、预渲染(原生视图创建、文本测量)、资源预拉取(图片、接口数据、缓存数据)等能力。单引擎多视图容器:一个渲染引擎可同时支持多个视图容器独立渲染,未来可适配不同业务场景。
iOS 渲染层实现

原生View + 图层混合渲染模式
Taro iOS 采用混合渲染模式(原生 View+图层)。原生 View和图层复用iOS系统
CoreAnimation、Render Server框架提供的底层渲染能力实现图层树管理、图层合并、脏区重绘、图层缓存、GPU调度等高性能复杂渲染能力,同时对边框、圆角、背景等能力可以利用系统GPU硬件加速提高渲染性能。由于原生页面和 Taro都是复用操作系统底层渲染能力可以保证渲染时机一致性。在原生 View的基础上,通过实现部分视图图层化渲染提供更好的渲染性能。
原生 View
原生View渲染:使用系统原生View实现View、ScrollView、Input组件渲染能力。原生互操作性好:Taro视图可以被嵌入到现有原生页面中、Taro视图也能支持嵌入现有原生视图(例如基础组件 JDMap、JDVideo 等),同时可解决和原生的触摸/手势冲突问题。流畅滚动体验:使用系统原生 ScrollView可以带来和原生一致的极致滚动体验,同时更好的处理多层嵌套滚动问题。复用系统生态:可以低成本适配无障碍、VisionOS系统等能力和新系统。
图层
高性能图层渲染:使用图层Image、Text、部分View组件渲染能力。图层相比原生 View更轻量(不支持触摸、布局系统、无障碍等)可以提高渲染性能(降低内存消耗、减少视图层级)。轻量化设计:在提供高性能渲染的同时可以避免引入类似 Skia这样的绘制库带来的包体积、内存消耗、开发/维护成本。
未来通过 Canvas组件提供
2D、3D图形绘制能力用于高性能复杂图形绘制场景。
渲染管线优化
自动图层渲染优化:系统自动根据视图类型判定是否使用图层渲染,图层和View可以并存,同时View 和图层视觉表现一致。以订单列表为例首屏可减少视图挂载(视图创建、添加到原生组件树)耗时,未来我们也将优化为更大范围的图层化渲染提升性能。自动视图拍平优化:系统实时对可拍平 View(仅布局视图、无动画、无触摸事件等)进行视图拍平减少视图层级优化渲染性能。以订单列表为例首屏可减少 50%原生View渲染节点。细粒度视图原子指令:渲染树经过DOM DIFF后生成细粒度的视图原子指令Create(视图创建)、Insert(视图添加)、Update(视图更新)、Delete(视图移除)降低重复渲染消耗。原生组件复用池:添加原生组件缓存复用池,可在页面内容大范围更新或长列表滚动时进行原生组件复用避免重复创建/删除(支持图层和 View)。同时可做部分视图预创建提高首屏渲染性能。布局优化:优化布局缓存策略减少重复布局计算,提升列表滚动 FPS,动画执行 CPU消耗大幅降低。图片渲染优化:优化图片渲染和 GIF图片渲染耗时,减少主线程耗时优化列表滚动流畅度,图片渲染主线程耗时降低 30%+。内存优化:结合实际业务场景,经过多轮的内存优化(降低节点树内存消耗、热点内存消耗优化)渲染内存消耗相对早期版本降低 20%+。
高性能富文本引擎
iOS 基于
CoreText自研高性能图文混排富文本引擎,通过优化文本缓存算法提高缓存复用率和优化文本测量/渲染性能。最终文本测量/绘制耗时较系统原生组件大幅降低。
高缓存复用率:通过多层缓存设计(文本对象缓存、文本测量缓存、文本行缓存、字体缓存)和缓存hash优化提升缓存复用率。文本测量、文本渲染可复用部分缓存避免重复计算同时降低内存缓存消耗。丰富富文本能力:支持单行/多行文本、嵌套Text/Image/View的富文本渲染能力。同时支持内嵌 Text/Image/View 的触摸/事件响应。对齐CSS规范:支持color、font、font-size、line-height、text-align、text-overflow、vertical-align等文本样式属性对齐 CSS规范。同时和现有原生视图保持文本视觉还原度一致。异步绘制:使用异步延迟文本绘制策略在首帧后进行文本渲染提高首屏渲染性能,因为渲染性能足够快用户无感知。
渲染能力完备性:兼容 Taro生态的渲染能力
组件支持:支持View、Image、Text、ScrollView、Input基础原子组件,同时提供复杂的 Sticky、嵌套滚动等能力对齐 Taro规范。支持注入自定义原生组件。CSS 属性支持:支持背景、边框、圆角、阴影、transform、文本等样式属性,对齐 CSS 规范。布局计算:支持flex、margin、padding、absoluted等布局计算能力,对齐 CSS规范。富文本支持:支持单行/多行、多级嵌套文本/图片/视图的富文本渲染能力。无障碍支持:提供基础无障碍能力支持。
TaroUI - 跨端UI基座
背景
跨端框架形态多样性
虽然跨端技术一直在发展但是一个跨端框架无法解决所有跨端场景。主要是因为面向场景不同、开发者生态、性能诉求不同等原因导致。
不同场景:页面(数量少、功能全)、楼层卡片(数量多、可复用、轻量化)。不同开发者生态:使用Web前端生态(React、CSS、JS)、KMP生态(ComposeUI+Kotlin)、自研 DSL方案等。
跨端框架一致性诉求
虽然跨端框架形态存在多样性,但是对渲染能力和 API调度能力的要求是一致的(抹平跨端一致性、高性能、标准化实现)。但传统依赖原生实现的方式存在多端重复开发成本高、多端行为不一致等问题。
一致的基础能力诉求:组件、 API调度、事件系统、动画系统、渲染管线调度、线程模型等能力。依赖原生实现的问题:重复开发成本高、多端行为不一致、新平台适配成本高等问题。
为了实现一致性的跨端UI能力,开发了TaroUI(跨端UI)实现了一套标准化、跨端、高性能、可扩展的 UI和 API基座能力。将更多的公共逻辑下沉到 C++进行高性能实现,代码复用降低维护成本,最终提升跨端一致性。
TaroUI:打造跨端组件架构,大幅提升跨端组件表现一致性
TaroUI 是一个以 C++为核心开发高性能、高跨端一致性的命令式跨端 UI 框架。将更多可复用的公共能力下沉到 C++层进行实现,在实现高性能的同时可以减少开发维护成本,提高跨端一致性。上层框架可调用 TaroUI 对外 API 进行渲染能力调度,无需感知渲染层平台差异。
跨端 UI 生态建设
提供标准化的组件和 API能力对齐 Taro规范。
组件支持:TaroUI 支持Page、View、Text、Image、ScrollView、Swiper、List、Waterflow、Input、Switch、RecycleList等 11个高性能核心基础组件。组件属性、事件、视觉、行为遵循 Taro 规范进行多端对齐。功能 API:提供事件、触摸、定时器、IntersectionObserver等能力对齐 Taro规范。
架构设计和技术实现

C++ & 原生双层组件系统:高性能、高跨端一致性
采用 C++组件和 Native 组件组合的模式。相比传统方案在 Native 维护大量原生组件可降低原生组件开发维护成本、提升组件行为/视觉跨端一致性,性能提升(例如降低 Android端 JNI传输成本)。相比 JS组件 可以带来更好的性能表现。

Native 原子组件:在原生(iOS、Android)端使用系统 View 封装少量的基础原子组件包括View、Text、Image、ScrollView、Input原子组件。针对原子组件做极致性能优化,保证原子组件视觉效果/行为一致性。C++ 基础组件:C++层提供直接映射到原生的View、Text、Image、ScrollView、Input组件之外,对高性能、高频使用、高复杂度组件进行封装Swiper、List、Waterflow、 RecycleList、Page等高阶组件。提供高性能组件能力、保证组件视觉/行为的多端一致性。
| 订单列表(iOS) | 订单列表(Android) |
|---|---|
触摸/事件系统
触摸系统:支持onTap/onLongTap/onMoveStart/onTouchMove/onTouchEnd/onTouchCancel事件、支持事件冒泡能力的触摸系统对齐 Taro规范。事件:支持组件事件绑定、组件事件视图层和逻辑层双向传递通讯等能力。
渲染管线调度

渲染管线调度:TaroUI实现了一套标准化时序一致的渲染管线调度设计驱动底层渲染层进行渲染更新,同时提供了事件队列的相关能力(微任务/宏任务/定时器等)等能力。
高性能虚拟列表组件
为了解决长列表场景的FPS流畅度和内存消耗问题,提供了 List、Waterflow、RecycleList组件用于不用的长列表场景。通过组件实现虚拟列表滑动窗口调度能力确保多端一致性的体验。
List/Waterflow:单列长列表组件和多列瀑布流组件。在列表滚动时通过滑动窗口实时调度更新渲染树进行视图渲染,原生渲染层只需渲染少量列表元素,可以带来最优的滚动性能。

-RecycleList:单行可回收长列表组件。提供更极致的可复用的循环列表实现,相比 List 可以实现无限滚动的长列表内存保持稳定,同时带来仅次于 List的滚动性能体验。(完整的滑动窗口不支持滚动偏移量获取)

可扩展性设计
更多平台扩展:核心层由 C++ 实现,未来可以相对低成本扩展到更多平台支持。独立调度机制:提供基础命令式 API 进行调用,可与上层框架解耦协同工作,渲染引擎能力可扩展到更多场景。
Taro 框架业务落地
目前Taro iOS/Android跨端方案已在多业务落地,支撑订单(列表/详情等多页面)、搜索(中间页/AI搜索)、我京(国际版/二三级页面)、分类等多个核心业务。
| 页面 | 订单列表 | 订单详情 | 搜索中间页 | 分类 | 我京国际版 |
|---|---|---|---|---|---|
| iOS | ![]() |
![]() |
![]() |
![]() |
![]() |
未来规划
技术愿景
我们的愿景是将TaroUI沉淀为具备行业竞争力的通用 UI 基础设施。通过构建一套多端/多场景覆盖、高跨端一致性、极致性能的 UI 框架,实现开发体验与用户体验的高度统一:
高跨端一致性与极简内核:坚持轻量化设计,核心层仅保留高频、基础、标准化的 UI 与基础 API 能力,最大程度抹平多端差异,提供高度一致的渲染表现与交互行为。全平台支持:支持iOS/Android/HarmonyOS/Windows 等平台。多渲染模式支持:支持原生渲染模式、自绘制(例如部分无系统UI框架的场景)两种渲染模式。多场景支持:可用在页面、楼层复用(单引擎多视图)等多场景。
2026 规划
2026 年的主要目标持续支持现有核心业务,同时探索新场景落地(购物车/结算、RN 转 Taro 项目)。
性能优化:通过优化可复用列表、提供比拟原生高性能动画、持续优化渲染管线和调度策略、提供更丰富的预热能力、内存优化等手段提升性能体验。能力边界拓展:提供复杂手势、主线程 UI、 2D 图形绘制等能力满足不同场景诉求,探索其它使用场景。跨端生态建设:持续完善TaroUI 能力沉淀跨端技术生态规范。




