Accelerating Taro Native Static Layout Rendering on HarmonyOS

Technical Background

Taro Native is JD's cross‑platform mobile framework (HarmonyOS, iOS, Android). A page containing a merchant card with more than 100 elements caused severe scrolling jank on low‑end HarmonyOS devices.

Rendering Pipeline

During scroll, WaterFlow preloads a FlowItem, obtains a reusable component via Repeat.GetFrameChildByIndex, updates its data, and dispatches a parsing task to the element thread.

The element thread parses the TML, builds a Virtual DOM, CSS info and a Yoga layout tree, then posts a measurement‑layout task to the render thread.

The render thread measures the Yoga tree, generates node‑creation and property‑setting commands, and sends the command set to the main thread.

The main thread processes the commands, calls CAPI to create nodes, set properties, update layout, and mounts the root node to ArkUI's ContentNode.

On each VSync the main thread performs a full system measurement and layout before handing the tree to render_service for compositing.

Bottleneck Identification

Profiling shows main‑thread overload, especially in phases 1, 4 and 5.

Phase 1 (FlowItem preload) : total 24 ms (A 15 ms, B 3 ms, C 6 ms). A – Repeat fetches a reusable component and updates state; B – image component creates and loads bitmap; C – all nodes inside the card are measured and laid out.

Phase 4 : command consumption dominated by Image and Text node creation and property setting.

Phase 5 : large numbers of Stack / Image / Text nodes cause massive recursive layout overhead.

Two core problems were identified:

Redundant measurement: FlowItem is measured during preload and again on the main thread after Yoga layout.

Repeated use of Repeat across stages adds cumulative cost.

Solution 1 – Static Node‑Tree Layout & Intercept System Measurement

Reuse the Yoga measurement results computed on the render thread as the final layout, skipping the main‑thread OnVSync measurement.

Introduce a CustomNode with overridden OnMeasure / OnLayout to block the system’s recursive measurement of the CAPI node tree.

Replace per‑node NODE_WIDTH, NODE_HEIGHT, NODE_POSITION calls with a single NODE_LAYOUT_RECT that sets top, left, width and height.

Implementation Steps

Replace all layout property settings with NODE_LAYOUT_RECT for every node.

Upgrade the root node from a StackNode to a CustomNode and register a custom measurement function that prevents recursive measurement.

Result: preload phase A time shortened; average frame rate on low‑end HarmonyOS devices rose from 43 fps to 57 fps (≈ 32.5 % improvement).

Solution 2 – Reuse Font Measurement Layout Cache

Text measurement uses JD’s self‑built ArkGraphics 2D engine and occurs in two stages. After Solution 1 the main thread still performs text measurement.

Move the entire text measurement to the render thread.

Cache the measurement result in an ArkUI_StyledString object.

Main thread consumes the cached dimensions directly, eliminating duplicate measurement.

Implementation Steps

Render thread measures and caches the StyledString.

Main thread applies the cached size and position.

Benefits: main‑thread time reduced by ≈ 4 ms; thread load becomes more balanced; each text is measured only once, avoiding cross‑thread discrepancies.

General Methodology

Pre‑measure : perform layout calculation on the render thread.

Result‑through : inject layout result via NODE_LAYOUT_RECT in a single step.

Intercept & deduplicate : use CustomNode to block redundant system measurement.

Resource reuse : cache heavy resources such as text measurement across threads.

This pattern can be applied to other RN‑style frameworks to improve rendering performance on low‑end devices.