Inside Ant Group’s Cube Card: High‑Performance Cross‑Platform UI Engine Explained

Dynamic Card Background

Since the Windows era, app icons have been the main entry point for users, but they are not intuitive and require at least one click to reach the desired information. iOS, some Android systems, and HarmonyOS introduced card‑style content that surfaces information and services directly. Within apps, cards are widely used as content displays and service entry points, as shown in examples from Alipay and China Merchants Bank.

Cube Card Overview

Cube Card is an internally developed, cross‑platform dynamic card solution at Ant Group. It provides a region‑level dynamic technology for application pages, serving content operations and improving both development and operational efficiency. Each Cube Card is embedded in a native page region and rendered via a card template.

Cross‑Platform Consistency

Single code base

Aligned visual effects

Dynamic

UI structure & style dynamism

Business logic dynamism

High Performance

Extreme performance

Extreme memory efficiency

Cube Card aims for a native‑like experience. Two performance dimensions are defined:

1. Extreme Performance : Based on the Cube Mini‑Program capability, complex CSS features (pseudo‑classes, pseudo‑elements, inline/block) are removed, and JavaScript capabilities are limited (QuickJS is used as the script engine). QuickJS is further optimized with offline atom compilation and asynchronous GC. A WAMR co‑processor enables mixed JavaScript and AssemblyScript development for hot functions.

2. Extreme Memory : In infinite‑scroll scenarios, Cube Card’s memory growth approaches that of native cards. Fine‑grained capability grading reduces runtime memory consumption. A simple card example and real‑world wallet card code are shown below.

Cube Card Production & Workflow

R&D Phase

Developers use a dedicated toolchain that supports compilation, logging, and real‑time preview. Vue serves as the DSL for card templates, allowing JavaScript and CSS editing.

Card Management

After local development, cards are uploaded via the Card Management backend, enabling version control and dynamic updates on client devices.

Runtime Phase

A CardSDK container abstracts common capabilities and handles communication with backend services, providing JSAPI and third‑party component integration so that cards focus on product logic.

Core System Architecture

The architecture consists of JSEngine, CardEngine, RenderEngine, and Platform, mostly implemented in C++.

JSEngine

Executes card JavaScript logic and monitors data changes. QuickJS is chosen for its small size and performance, complemented by a lightweight reactive framework (JSFM).

CardEngine

Handles data parsing, binding, logical rendering, DOM instruction generation, JSAPI management, JSBinding, and native event communication. The DOM tree is built directly in C++ during card instance initialization for speed.

RenderEngine

Back‑end rendering core responsible for layout calculation, style parsing, layer computation, self‑drawing components, same‑layer rendering, rasterization, and handling gestures and animations.

Platform

Provides atomic view wrappers, Canvas API, third‑party component protocols, and animation APIs.

Thread Model and Data Model

Thread Model

Two main thread groups: business thread (initial data loading, beforeCreate phase) and engine threads (Bridge, Render, Paint, UI main thread).

Bridge Thread

Runs JavaScript, handles DOM queries; lightweight and single‑threaded.

Render Thread

Computes rendering data, builds render tree, performs layer calculations; also single‑threaded.

Paint Thread

Executes node rasterization; may run on the UI thread or a thread pool depending on sync/async rendering mode.

UI Main Thread

Handles gestures, UI compositing, and third‑party component updates.

Additional low‑priority background threads handle telemetry and monitoring.

Data Model

Three primary trees correspond to the thread model:

NodeTree : Original DOM‑like node tree used for style parsing and layout.

RenderTree : A transformed tree used during the rendering phase, enabling flexible adjustments such as z‑index and static layering.

LayerTree : Organizes nodes into independent layers for concurrent rendering.

PaintTree : Temporary copy of RenderTree for each render pass, optimized to skip fully occluded nodes.

High‑Performance List Rendering

For list scenarios, Cube Card uses asynchronous rendering and multi‑threaded concurrency to avoid jank and white‑screen effects, delivering smooth scrolling even on low‑end devices.

Native Technology Optimizations

Although the DSL resembles front‑end languages, CSS capabilities are deliberately constrained to ensure performance on native platforms. Collaboration with the front‑end team produced a CSS capability specification, yet challenges remain for features like z‑index and overflow.

Layer Container

Each Layer node becomes an independent rendering container (e.g., CALayer on iOS), separating content and logic layers to improve shadow rendering, clipping, and canvas optimization.

Gesture Refactoring

System gesture limitations on Android and iOS are addressed by intercepting gestures at the Layer container level, ensuring third‑party components receive proper events.

Rasterization

Cube Card supports both command‑based and bitmap rasterization, switching based on scenario to balance frame rate and memory usage. Bitmap rendering uses offline buffers, while texture‑view attempts faced compatibility issues on older Android devices. Future work includes replacing platform Canvas with Skia.

Same‑Layer Rendering

Third‑party components are rendered as separate layers, enabling efficient updates and reuse across cards. Complex components like maps, videos, and animations are handled case‑by‑case to mitigate performance and memory overhead.

Business Status and Future Plans

Cube Card currently powers over 20 business scenarios in Ant Group’s wallet, securities, card pack, travel, etc., with daily PV exceeding 100 billion. Future focus remains on expanding within the wallet ecosystem, improving developer tooling, reducing package size, and further lowering memory consumption.

A key future direction is commercialization: offering Cube Card as an extension to Ant Group’s MPaaS platform for small‑to‑mid‑size internet and financial companies.

Another direction targets IoT devices (RTOS). By adapting Cube Card and Mini‑Program concepts, a hybrid UI stack can provide lightweight, dynamic interfaces suitable for resource‑constrained devices, offering routing capabilities beyond simple cards.