How Taro 5.0 Delivers a High‑Performance iOS Rendering Layer and a Unified Cross‑Platform UI Framework

Background

The Taro cross‑platform ecosystem already supports H5, Mini‑Program, and HarmonyOS. The technical vision is to build a high‑performance container that runs a single codebase on five platforms (“one code, five ends”).

Why a custom solution is required

HighPerformance

: performance close to native to satisfy first‑screen speed, FPS, and memory constraints. HighStability: strict limits on crash and OOM rates for critical domains such as orders, shopping cart, and search. TaroEcosystemCompatibility: reuse Taro code and support Mini‑Program/HarmonyOS components with consistent visual and interaction behavior. NativeInterop: embed native components, be embedded in native pages, keep rendering timing consistent, and resolve native gesture/scroll conflicts. LowIntegrationCost: reuse existing native infrastructure (base APIs) with minimal binary size increase.

iOS – High‑Performance Rendering Layer

Rendering container architecture (engine‑view decoupling)

Taro adopts a dual‑thread rendering pipeline and separates the view container from the runtime. The JS thread handles business logic, DOM operations, animation, render‑tree construction, and layout calculation, while the UI main thread performs native view operations, layout setting, property/style updates, and text rendering. This design enables first‑screen parallel rendering, maximises multi‑core CPU utilisation, and provides rich pre‑heat capabilities (engine pre‑creation, logic pre‑execution, native view pre‑rendering, text measurement, resource pre‑fetching). A single engine can drive multiple independent view containers (single‑engine‑multiple‑view‑containers). DualThreadPipeline: runs business logic on a JS thread and native view updates on the UI main thread. FirstScreenParallelRendering: UI main thread and JS thread execute in parallel for first‑screen loading without requiring separate code.

High pre‑heat design: decoupling runtime and view container allows maximum pre‑heat optimisation while avoiding memory‑heavy on‑screen rendering. SingleEngineMultipleViewContainers: one rendering engine supports multiple view containers for future runtime scenarios.

Mixed native view + layer rendering

Native View NativeViewRendering: implements system native View, ScrollView, and Input components. NativeInteropGood: Taro views can be embedded into existing native pages and vice‑versa (e.g., JDMap, JDVideo), solving touch/gesture conflicts. SmoothScrollExperience: system native ScrollView provides native‑level smooth scrolling and handles nested scrolling gracefully. ReuseSystemEcosystem: low‑cost adaptation to new system features such as accessibility and VisionOS.

Layer HighPerformanceLayerRendering: renders Image, Text, and some View components as lightweight layers (no touch handling, no layout system, no accessibility), reducing memory consumption and view hierarchy depth. LightweightDesign: avoids heavy drawing libraries like Skia, keeping binary size, memory usage, and maintenance cost low.

Future plans include adding 2D/3D Canvas capabilities for complex graphics.

Rendering pipeline optimisations

AutomaticLayerRenderingOptimisation

: runtime automatically decides whether a view should be rendered as a layer; layers and Views can coexist with visual consistency. In an order‑list example, first‑screen view‑mount time is reduced. AutomaticViewFlatteningOptimisation: real‑time flattening of layout‑only Views (no animation, no touch) reduces native view nodes by 50% for an order list, improving rendering performance. FineGrainedViewCommands: after DOM diff, the render tree generates atomic commands – Create, Insert, Update, Delete – to minimise redundant rendering. NativeComponentReusePool: caches native components for large updates or long‑list scrolling, avoiding repeated creation/deletion and supporting both layer and View components. Enables partial view pre‑creation for faster first‑screen rendering. LayoutOptimisation: optimises layout cache strategy, reduces repeated layout calculations, raises list‑scroll FPS and dramatically lowers CPU cost of animations. ImageRenderingOptimisation: improves image and GIF rendering time, reducing main‑thread cost and improving scroll smoothness; image rendering time reduced by over 30%. MemoryOptimisation: multi‑round memory optimisation (node‑tree memory, hotspot memory) cuts overall rendering memory consumption by more than 20% compared with early versions.

High‑performance rich‑text engine

Built on iOS CoreText, the custom rich‑text engine uses multi‑level caching (text object cache, measurement cache, line cache, font cache) and cache‑hash optimisation to achieve high cache reuse. Text measurement and drawing time are significantly lower than the system native component. HighCacheReuseRate: multi‑layer cache design improves reuse, avoiding repeated calculations and reducing memory pressure. RichTextCapabilities: supports single‑line/multi‑line text, nested Text/Image/View, and event handling for embedded elements. CSSPropertyAlignment: implements colour, font, font‑size, line‑height, text‑align, text‑overflow, vertical‑align and other CSS properties, matching native visual fidelity. AsyncDrawing: delays text drawing to the next frame, improving first‑screen performance without user‑perceivable delay.

TaroUI – Cross‑Platform UI Base

Architecture

TaroUI is an imperative cross‑platform UI framework with a C++ core. It provides a three‑layer component system: native atomic components, C++ basic components, and high‑order C++ components. This reduces native component maintenance cost, improves cross‑platform visual and behavioural consistency, and yields performance gains (e.g., lower JNI transfer cost on Android).

Component layers

Native atomic components : system View, Text, Image, ScrollView, Input with extreme performance optimisation to ensure visual and behavioural parity.

C++ basic components : direct mappings of the same atomic components plus high‑frequency complex components such as Swiper, List, Waterflow, RecycleList, Page. They provide high‑performance implementations and guarantee cross‑platform consistency.

Touch / event system

TouchSystem

: supports onTap, onLongTap, onMoveStart, onTouchMove, onTouchEnd, onTouchCancel and event bubbling, fully aligned with Taro specifications. EventSystem: enables component event binding and two‑way communication between view and logic layers.

Rendering pipeline scheduling

TaroUI defines a standardised, time‑consistent rendering‑pipeline schedule that drives the underlying rendering layer and provides task‑queue capabilities such as micro‑tasks, macro‑tasks and timers.

High‑performance virtual list components

List/Waterflow

: single‑column list and multi‑column waterfall components. They use a sliding‑window mechanism to update only visible items, keeping native rendering work minimal and delivering optimal scroll performance. RecycleList: single‑row recyclable long list. Provides near‑infinite scrolling with stable memory usage and performance close to List (though it does not expose scroll offset).

Extensibility

MorePlatformExtension

: core C++ layer can be extended to support additional platforms at low cost. IndependentRuntime: provides a basic imperative API that can be invoked independently of the upper‑level runtime.

Business adoption

Taro iOS/Android cross‑platform solutions are deployed in multiple core JD.com businesses, including order list/detail pages, search (including AI search), JD International, and category pages.

Future roadmap

Technical vision

High cross‑platform consistency & minimal core : keep the core lightweight, retaining only high‑frequency, fundamental UI and API capabilities to minimise platform differences.

Full platform support : iOS, Android, HarmonyOS, Windows and beyond.

Multiple rendering modes : native rendering mode and self‑draw mode for environments without a system UI framework.

Multi‑scenario support : page‑level rendering and floor‑reuse (single‑engine multiple view containers).

2026 plan

Performance optimisation : optimise reusable list components, provide near‑native high‑performance animations, continuously refine the rendering pipeline and scheduling, expand pre‑heat capabilities and further reduce memory usage.

Capability expansion : add complex gestures, main‑thread UI, 2D graphics drawing and explore additional use cases.

Cross‑platform ecosystem growth : continue to enrich TaroUI capabilities and solidify cross‑platform technical standards.