Flutter-OH 3.35 & RNOH 0.82: Performance Gains & Architectural Shifts on HarmonyOS

During HDC, both Flutter-OH and React Native for OpenHarmony (RNOH) released major updates that sync with upstream versions while adding HarmonyOS-specific optimizations.

Flutter-OH 3.35: Performance, Load, and Memory Leap

Flutter SIG was formed in January 2026 under the cross-platform framework PMC. The 2026 roadmap (https://gitcode.com/CPF-Flutter/flutter_flutter/blob/br_3.27.4-ohos-1.0.4/docs/roadmap/Flutter-OH-Roadmap.md) targets a 4-month sync cycle from version 3.41 onward, down from 7 months.

1. Preload Rendering Pipeline: First-Frame Latency Down 37.8%

Pain point: Navigating from a native page to a Flutter page often showed a white screen while the engine initialized, GPU cold-started, and the rendering pipeline was built — all after the tap.

Solution: WarmUp Pipeline pre-warms the engine, GPU, and offscreen rendering before the tap. On tap it reuses the pre-warmed result; if that fails it falls back gracefully without betting on a single path.

Results: First-frame latency reduced 37.8% ; engine-mount-to-first-frame reduced 23.1% . Preload phase requests only 2 render buffers instead of the usual 6, saving 40 MB+ memory.

2. LTPO Dynamic Frame Rate: Load Down ~20%, Smoothness and Battery Life No Longer at Odds

Pain point: With system refresh rate set to "smart", Flutter could only follow a fixed heuristic (touch → 120 Hz, 3 s after release → 60 Hz), ignoring whether content actually needed high frame rate — wasting power when static.

Solution: Refresh rate now tracks content velocity in real time. Core policy: "accuracy first, rather miss than false alarm" — scroll, Hero transitions, and page transitions report precise pixel velocity; widget animations that cannot be reliably converted do not report, avoiding misjudgment that causes jank or excess drain.

3. Zero Dirty-Region Skip Rendering: Eliminate Unnecessary GPU Load

Pain point: When consecutive frames are identical, the engine still runs a full-frame render pass, burning CPU/GPU cycles and battery.

Solution: Leveraging Impeller's Vulkan backend dirty-region capability, Flutter-OH implements "zero dirty-region skip rendering" — if the frame has no changes, the entire render pipeline is skipped; the Raster thread becomes nearly idle.

4. DMA Memory Background Release: Background Keep-Alive Greatly Improved

Pain point: After moving to background, Flutter apps kept all 6 DMA graphics buffers resident, consuming large memory; the OS would kill the process under memory pressure, forcing a full reload on return.

Solution: On background transition the app proactively releases DMA buffers, retaining only 1. Background memory footprint drops sharply, extending keep-alive time.

5. BiSheng Compiler PGO: Deeper Runtime Performance Gains

Pain point: Flutter engine performance on HarmonyOS relied on generic compiler optimizations, not tuned to real-world usage patterns.

Solution: BiSheng PGO collects hot-path profiles from actual app runs, then feeds them back to guide compiler optimizations. The resulting binary runs shorter, with fewer instructions, improving on-device fluidity.

RNOH 0.82: Three-End Consistency Accelerated, Native-Like Silkiness

RNOH 0.82.30 stable ships New Architecture only, Hermes V1 support, and React 19.1.1 — multiple competitiveness features landing together.

Upstream Sync: Lockstep with React Native Cadence, Zero Experience Gap

RNOH community tracks upstream RN versions, prioritizing key releases so HarmonyOS developers get the same RN capabilities as iOS/Android simultaneously. Adaptation strategy follows three principles (illustrated in the article). As of 2026 Q1, RNOH has completed three generations: 0.72 LTS → 0.77 LTS → 0.82 Stable ; 0.84 Preview branch is open. HarmonyOS developers can use RN 0.82's full new-architecture capabilities today, in step with the global RN community.

Technical Point 1: Parallelization Solution

Architecture pain point 1 — Serial node creation: Under Fabric, every state update triggers a full render pipeline: JS Reconciler → ShadowTree Create → ShadowTree Commit → Native Mount. ShadowNodes are created one by one, all stages serial.

Architecture pain point 2 — TurboModule blocking JS thread: Synchronous TurboModule calls freeze the JS thread, root cause of dropped frames in critical interactions.

Optimization: The three pipeline stages are split across separate thread pools so Create, Commit, Mount, and TurboModule calls run in parallel without blocking each other. Create runs on FFRT thread pool; ArkUI pre-creation parallelized; TurboModule offloaded to dedicated thread.

Huawei Mall before/after comparison (chart in article) demonstrates the improvement.

Technical Point 2: JSVM & Hermes V1 Dual Engine — JS Engine Performance Leap

JSVM: Eliminates serial JS cache parsing overhead, enabling instant page response. Co-built with Ctrip; on core flight/hotel/train ticket pages, response latency reduced 10% .

Hermes V1 advances in three dimensions:

Compiler optimization: Bytecode generation efficiency up, bundle size down, first-screen load faster.

Concurrent GC: Garbage collection runs in parallel with JS execution, eliminating GC-induced UI jank.

Memory allocation improvements: Object allocation more compact, young-gen GC more efficient, peak memory lower.

Version 0.84 will make Hermes V1 the default engine, so performance gains require no manual opt-in.

Technical Point 3: New Architecture Only — Fabric + TurboModule as Sole Path

RN 0.82 makes the new architecture the default rendering and communication path:

Fabric synchronous rendering: JS and native render layer interact via C++ JSI directly, removing Bridge async latency; UI updates shift from "message queue wait" to "synchronous direct call".

TurboModule lazy loading: Native modules load on demand, no longer fully initialized at startup; cold-start speed significantly improved.

Codegen type safety: Auto-generates TurboModule type definitions, catching interface errors at compile time.

Developer value: Unified architecture eliminates new/old architecture compatibility code splits; a single codebase covers all platform-agnostic scenarios.

Technical Point 4: React 19.1.1 + DOM Node API — Developer Experience Evolution

React 19.1.1: useDeferredValue and startTransition reliability inside Suspense boundaries greatly enhanced; complex interaction state management more stable and consistent.

DOM Node API: Native components expose DOM-like node interfaces via refs; focus(), scrollTo(), etc., work without Platform branching.

Installation guides and empowerment docs: https://gitcode.com/openharmony-tpc/flutter_samples/tree/master/ohos/docs

Community participation: Join Flutter SIG (https://gitcode.com/OpenHarmony-CrossPlatformFramework/community/blob/main/sigs/sig-flutter/charter.md) for version planning and technical co-construction.