您好!
欢迎来到京东云开发者社区
登录
首页
博文
课程
大赛
工具
用户中心
开源
首页
博文
课程
大赛
工具
开源
更多
用户中心
开发者社区
>
博文
>
【Taro 5.0 技术与实践】 - 高性能 iOS 渲染层与 TaroUI 跨端框架介绍
分享
打开微信扫码分享
点击前往QQ分享
点击前往微博分享
点击复制链接
【Taro 5.0 技术与实践】 - 高性能 iOS 渲染层与 TaroUI 跨端框架介绍
29****
2026-04-03
IP归属:北京
1浏览
 # 背景 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线程`双线程并行执行提高首屏加载性能,业务无需针对双线程编写不同代码即可获得优益的性能。 * `高可预热设计`:运行时和视图容器解耦的设计,在支持最大化预热优化首屏耗时的同时避免真实上屏渲染降低内存消耗。为下一阶段对外提供更多预热能力打下基础,例如`引擎预创建`( JS引擎、包下载/解码/缓存读取)、`业务逻辑预执行`(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 能力沉淀跨端技术生态规范。 > Taro团队持续招聘iOS/Android/鸿蒙/前端/C++开发,欢迎投递简历。
上一篇:三十分钟入门基础Go——Java小子版
下一篇:【权益中心】-优惠券模块配置化能力架构设计与实践
29****
文章数
8
阅读量
8626
作者其他文章
01
基于 prefetch 的 H5 离线包方案
前言对于电商APP来讲,使用H5技术开发的页面占比很高。由于H5加载速度非常依赖网络环境,所以为了提高用户体验,针对H5加载速度的优化非常重要。离线包是最常用的优化技术,通过提前下载H5渲染需要的HTML/JS/CSS资源,加载时直接使用本地缓存资源避免额外的网络请求提高加载速度。本文主要是介绍团队在离线包技术方案上的探索,以及基于prefetch的离线包实现方案如何减少维护成本和开发成本。现有方
01
现代 CPU 技术发展
介绍这篇文章主要是介绍CPU技术的发展,包括最近几十年CPU性能提升和半导体工艺发展,当前技术发展方向。希望可以帮助软件开发者理解CPU指令集和组成运行原理、CPU性能提升的现状和瓶颈、CPU技术发展方向会如何影响软件开发/设计的框架和编程思想。提示:因为是面向软件开发者,所以会忽略掉一些电路设计、制造工艺等底层的硬件知识。同时也不会特别深入的介绍每个知识点,只是提供一个概览。CPU 指令集和运行
01
京喜APP - 图片库优化
介绍京喜APP早期开发主要是快速原生化迭代替代原有H5,提高用户体验,在这期间也积累了不少性能问题。之后我们开始进行一些性能优化相关的工作,本文主要是介绍京喜图片库相关优化策略以及关于图片相关的一些关联知识。图片性能问题作为电商APP,图片在各个业务场景被大量使用。我们需要做到尽可能降低网络消耗/内存消耗/硬盘消耗,同时不降低图片质量,提高图片加载速度,给用户带来更好的使用体验。基于这些性能目标,
01
移动端APP组件化架构实践
theme: smartblue前言对于中大型移动端APP开发来讲,组件化是一种常用的项目架构方式。个人最近几年在工作项目中也一直使用组件化的方式来开发,在这过程中也积累了一些经验和思考。主要是来自在日常开发中使用组件化开发遇到的问题以及和其他开发同学的交流探讨。本文通过以下问题来介绍组件化这种开发架构的思想和常见的一些问题:为什么需要组件化组件化过程中会遇到的挑战和选择如何维护一个高质量的组件化
29****
文章数
8
阅读量
8626
作者其他文章
01
基于 prefetch 的 H5 离线包方案
01
现代 CPU 技术发展
01
京喜APP - 图片库优化
01
移动端APP组件化架构实践
添加企业微信
获取1V1专业服务
扫码关注
京东云开发者公众号