How Cube Achieved High‑Performance Cross‑Platform Rendering with Asynchronous Bitmap Rendering

Background

In 2016‑2017, before React Native matured and Flutter existed, Alibaba needed a fast, cross‑platform solution that fit a front‑end‑centric development environment, leading to the internal creation of a dynamic rendering framework called Cube.

Problems with Native View Rendering

Traditional native view rendering on Android (create‑measure‑layout‑draw) runs on the main thread; in long lists this causes high CPU usage, frame‑rate drops, and UI jank.

Asynchronous Rendering Concept

Cube moves the heavy drawing steps to a background thread, producing a bitmap cache that the main thread simply composites, dramatically improving scroll smoothness.

Cross‑Platform Architecture

Cube separates platform‑specific code into a platform layer exposing standard C++ atomic interfaces, initially implemented for Android (via JNI) and iOS (mixed C++/Objective‑C). Adding new platforms only requires implementing these interfaces.

The core library, built on the platform layer, provides basic services (file I/O, UI controls, image download, messaging) and the rendering engine that manages data models and component libraries.

Asynchronous Rendering Technology Selection

Cube evaluated several Android options:

SurfaceView / GLSurfaceView : render on a separate thread but cannot be used inside standard list items and lack proper view hierarchy integration.

TextureView : supports independent rendering and view hierarchy, but suffers from memory, recycling, and compatibility issues in long lists.

Bitmap + ordinary View : draws content off‑screen onto a bitmap in a background thread and then composites it in the main thread; despite memory concerns, it proved the most universally applicable solution for Cube.

Bitmap caching is used to reuse bitmap canvases for list items, reducing memory pressure.

BitmapCache stores bitmap canvases during item recycling and reuses them when possible, selecting canvases of matching or larger size to limit redraw area.

iOS Rendering Choice

iOS follows a similar approach but assigns the bitmap result to the view’s layer instead of drawing in drawRect, achieving better performance.

Evolution of Cube Rendering

Cube’s rendering pipeline has undergone three major phases:

1.0 – Feasibility : Single‑layer rendering for simple list items; all UI elements drawn on a root layer.

2.0 – Productization : Support for multiple layers, allowing independent bitmap rendering for different UI components.

3.0 – Optimization : Off‑load render‑object construction and change‑impact calculations to background threads; introduce PaintTree to separate pure drawing data from logic.

Data Models

LayoutTree : Yoga‑based layout description built from DOM‑like commands.

RenderTree : Tree of render nodes derived from LayoutTree, excluding invisible nodes.

LayerTree : Hierarchy of layers, each mapped to a platform view.

PaintTree : Pure drawing objects attached to layers, avoiding concurrency issues.

Rendering Flow

1. Bridge thread builds LayoutTree. 2. Main thread creates RenderTree and enqueues render tasks. 3. On VSync, tasks are dispatched; each layer is drawn on a background thread producing a bitmap. 4. Main thread composites the bitmap onto the view.

Current Drawbacks

Cannot handle multiple independent layers in the earliest version.

Entity views are not reused, leading to many instances in long lists.

Main‑thread workload can still cause jank in complex scenes.

Render‑thread overload may increase white‑flash occurrences.

Future Plans

Cube aims to further reduce white‑flash and improve cold‑start performance through rendering snapshots, pre‑rendering strategies, thread‑model refinements, component caching, Yoga layout engine optimizations, and a Skia‑based cross‑platform drawing implementation.

The framework now powers over 500 card templates, serving billions of page views across diverse scenarios such as in‑app cards, mini‑programs, and IoT devices.