How Kuikly's TurboDisplay Achieves Instant Cross-Platform Page Loads

Overview

Kuikly is Tencent's open-source cross-platform framework built on Kotlin Multiplatform (KMP), covering Android, iOS, HarmonyOS, H5, WeChat Mini Programs, and macOS. Leveraging Kotlin/Native compilation and native rendering pipelines, Kuikly already delivers native-level performance. To further optimize first-screen experience, the team developed TurboDisplay, a self-designed acceleration solution that achieves "instant open" on second visits through node caching, main-thread client-side direct rendering, and dual-thread parallel rendering. TurboDisplay has been deployed in QQ Games, Input Method, Tencent Maps, and other production services, yielding 60-80%+ latency reductions.

Why First-Screen Acceleration Is Needed

Page load latency is a universal mobile client challenge. From user tap to first-screen display, the serial chain includes container initialization, runtime/rendering engine preparation, business code execution, data request/parsing, layout measurement, node construction, and final rendering. Any stage's delay adds to perceived wait time. This is not unique to cross-platform frameworks; even pure native development faces business complexity, network jitter, and device performance variance. Kuikly's native-level execution performance via Kotlin/Native has approached the ceiling of "code runs faster" optimizations. To fundamentally accelerate first-screen display, the rendering pipeline's scheduling must be restructured.

Limitations of Traditional Approaches

Industry has accumulated various first-screen optimizations (preloading, skeleton screens, SSR, etc.), but none achieve true "open and instantly interactive" experience. The core issue: caching only images or data is insufficient. The cached object must be the framework's rendering product itself — cached built render nodes — so that on next open the intermediate stages are skipped and an interactive page appears instantly.

Solution Selection

Ideal First-Screen Cache Solution

An ideal solution must satisfy three criteria simultaneously: business non-intrusive, timely rendering, and correctness . Non-intrusiveness enables large-scale rollout; timeliness ensures users see the latest page; correctness guarantees production trust.

Node Direct Output: Not Enough

The most intuitive approach is node direct output: persist render node structure, attributes, styles, and rebuild the view on next open, skipping business execution, layout measurement, and node construction. Kuikly's low-level render nodes and instructions naturally fit this pipeline. However, node direct output only covers cross-platform business execution and node construction phases. The preceding engine initialization operations remain unavoidable, still delaying first-screen display. Thus, node direct output alone falls short of "open and instantly visible/interactive."

Final Approach: Extract Cache Recovery from Main Pipeline

Node direct output merely shortens the chain but does not restructure it. Cache recovery remains nested within the business logic execution chain. To truly accelerate, cache recovery must be extracted into an independent fast path. This requires solving three key problems: how to make cache recovery happen earlier, how to keep cache content updated, and how to seamlessly transition from cached first-screen to real page.

TurboDisplay Design

TurboDisplay's core design comprises three mechanisms: dual-thread parallelism, node collection, and incremental updates. The first two address "how to show earlier" and "what to show"; the latter handles "how to switch back to real page without interrupting interaction." Additional mechanisms include cache consistency, fallback writes, forced refresh, node tree structure capture, and extensions for special scenarios.

5.1.1 Dual-Thread Parallelism

To make "cache recovery an independent fast path," Kuikly moves the complete first-screen construction execution process to the client side for an extra early run:

After the client-side container and root view are built, directly read local cache, convert to node tree, emit rendering instructions, and render first-screen quickly on the client side.

The original execution chain remains unchanged. After thread scheduling, the cross-platform side continues normal background execution of real page business logic, layout measurement, and node construction, producing batch rendering instructions and generating a real page node tree on the client side, awaiting diff comparison with the cached node tree to update actual first-screen content.

5.1.2 Node Collection

TurboDisplay stores the full content of nodes from the client-side node tree, including each node's attributes, events, layout frame, shadow info, method calls on nodes, and node tree structural changes. During collection, TurboDisplay systematically compares the cached first-screen and real page node trees for structural and content differences, updates the cached node tree with diffs, and automatically writes the cached node tree to disk periodically with rate limiting. Business can customize whether to capture structural differences between node trees; if disabled, the cache always reflects the real first-screen's latest nodes and content.

5.1.3 Incremental Updates

Beyond fast direct output, the critical challenge is smoothly presenting the real page logic on top of the already displayed cached first-screen. To avoid flicker and jumps caused by data differences between real business logic and cached first-screen, incremental update is the most stable approach. The cross-platform side schedules the main thread; the client side batch-executes rendering instructions to build the real first-screen node tree, then performs diff comparison of attributes, layout frames, method call parameters between real and cached node trees, fully replays interaction events recorded during cached first-screen display, and directly creates previously non-existent nodes. This achieves smooth transition from cached first-screen to real first-screen without screen jitter.

5.2 Extension Support: State Restoration and Event Ordering

Real pages don't always stay at initial position. After cached first-screen displays, users may have interacted, or list pages may need to restore to previous scroll position. This causes misalignment between client-side displayed content and cross-platform side's default first-screen built in background. Applying diff then causes the first-screen to jump back to default content, pushing content off-screen and creating blank areas.

Why Diff Incremental Update Becomes a Problem

TurboDisplay's "client-side direct output + cross-platform background build" parallel design means cached first-screen appears earlier than real business first-screen. This "earlier" is the root cause. After client-side direct output, whether restoring to historical position or responding to user interaction, the client side already shows non-default state. But the cross-platform side's real page is still at default position, unaware of these changes. When the real page executes diff on the client side, it compares "client-side restored/interacted state" with "real page default state," and the differences are fully updated, overwriting the client-side presented content back to default, manifesting as position jumps or lost interaction results.

Solution: Cross-Platform Side Schedules Diff

Two attempts (delay-based and local signal-based) failed because the client side cannot predict when the cross-platform side's real page construction completes. The root cause points to the solution: let the cross-platform side, which has full timing information, schedule the recovery. Specifically, delay diff execution from "execute immediately when real page arrives at client side" to "execute after recovery content takes effect." The cross-platform side precisely senses its own progress during real node tree construction, and before generating rendering instructions, executes recovery logic: apply scroll offset to real page nodes, replay cached interaction events so cross-platform side responds first, so the real first-screen delivered to client side is already in restored state. At this point, diff compares two consistent bases, non-default content is no longer a diff item, and won't be overwritten.

After solving diff timing, TurboDisplay achieves stable and correct display for both default business logic first-screen content and dynamic content after interactions.

Performance Results and Validation

6.1 Lab Comparison

Tests on iPhone 13 Pro Max and iPhone 7 Plus for second-open scenarios show TurboDisplay rendering first frame almost instantly. GIF comparisons (first frame delayed 100ms for visibility) demonstrate dramatic improvement on both high-end and older devices.

6.2 Production Data Verification

TurboDisplay is live in QQ Games, Input Method, Tencent Maps, and many other business scenarios, achieving 65-80% latency optimization. The following chart shows actual production comparisons (note: pre-optimization pages had code and data locally cached, startup process had no network latency, all local logic latency).

Integration Guide

TurboDisplay was designed for lightweight business integration. Businesses only need to implement the TurboDisplayKey switch interface to enable first-screen acceleration for Kuikly pages. Typical integration code:

// Native client page container KuiklyRenderViewController.m
// Implement TurboDisplay switch interface
- (NSString *)turboDisplayKey {
    return pageName;
}

Other business control items and details are documented at the official site: https://kuikly.tds.qq.com/DevGuide/turboDisplay.html

Future Plans

Current TurboDisplay focuses on second-open scenario optimization. For first-open scenarios, the team is designing and developing a solution with core ideas:

Static analysis and extraction of first-screen logic at compile time.

Fast first-screen display at runtime via a micro-instruction engine.

Smooth handoff to the original product execution pipeline.

About Kuikly

Kuikly is now open source. Interested products can access the repository and documentation:

Official docs: https://kuikly.tds.qq.com/Introduction/arch.html

GitHub repo: https://github.com/Tencent-TDS/KuiklyUI

Kuikly is a key member of Tencent Terminal Service Alliance (tds.qq.com). More info:

Tencent Terminal Service official site: https://tds.qq.com/

TDS Framework official site: https://framework.tds.qq.com/