How Taobao Widgets Render Canvas Across Platforms: Inside the Weex2.0 Architecture

Widget Overview

Taobao widgets are open‑card solutions that act as module‑level containers for private‑domain scenarios such as product cards, rights cards, and interactive cards. They expose a standardized DSL, JavaScript framework, atomic APIs, and extensions like Canvas, allowing ISVs to deploy widgets to stores, detail pages, and subscriptions with minimal cost.

Key Characteristics

DSL Standardization : Widgets fully comply with the mini‑program DSL and related atomic APIs, enabling developers to start without additional learning.

Cross‑Platform Rendering : The widget core, based on Weex 2.0, uses a Flutter‑like self‑draw approach to produce identical results on Android, iOS, and other OSes.

Cross‑Scenario Flow : Widgets can be embedded into various containers (Native, WebView, mini‑programs), achieving "write once, run everywhere".

Technical Architecture

The widget stack consists of two layers: the Shell and the Core .

Shell includes the DSL, JavaScript framework, atomic APIs, and extensions such as Canvas.

Core is the Weex 2.0 kernel, which comprises:

JS engine: QuickJS on Android, JavaScriptCore on iOS, with JSI bindings.

Framework: CSSOM, DOM, a C++ MVVM layer, and Web APIs (console, setTimeout, etc.).

Unicorn rendering engine: layout, painting, composition, rasterization, and a PlatformView capability that lets native components like Camera, Video, and Canvas embed their own surfaces.

Multi‑Perspective Rendering Flow

From the developer side, the Canvas API ( canvas.getContext('2d') or canvas.getContext('webgl')) is bound to native C++ implementations (Skia for 2D, OpenGL ES for WebGL). The widget kernel builds a LayerTree where Canvas appears as a PlatformViewLayer. Unicorn rasterizes this tree, and Android’s SurfaceFlinger composites the final image.

Canvas Perspective

Rendering Surface Setup : Upon receiving a PlatformView creation request, the JS thread binds the Canvas API, the Platform thread creates a TextureView/SurfaceView, and the raster thread initializes EGL and binds the surface. For WebGL, the surface is usually created directly on the JS thread.

Rendering Pipeline Overview : After the Ready event, developers obtain a Canvas handle via getContext. 2D commands are recorded on the JS thread and executed on the raster thread; WebGL commands run directly on the JS thread. VSYNC drives the frame, triggering requestAnimationFrame, which starts the actual rendering and eventually swaps buffers to display.

Weex Engine Perspective

Canvas is treated as a PlatformView component; the engine does not need to know its internal details. The widget JS runs in the script engine, calls the universal CallNative binding, which translates DOM changes into Weex rendering commands. Unicorn reconstructs a static node tree, generates a RenderObject tree, builds a LayerTree, and finally sends it to the rasterizer for composition.

PlatformView Embedding Methods

Weex 2.0 on Android supports several PlatformView strategies. Two representative ones are:

VirtualDisplay : Creates a SurfaceTexture, wraps it in a Presentation, and renders the PlatformView (e.g., Canvas TextureView) onto a virtual display. The texture is then converted to an OES texture for Unicorn composition. This method cannot handle touch events, accessibility, or text input focus.

Hybrid Composing : Renders the PlatformView onto one or more ImageReader surfaces. Unicorn wraps each ImageReader in a custom UnicornImageView. The view converts the latest image to a bitmap and draws it with Android’s Canvas. This approach solves most compatibility issues but adds main‑thread load and bitmap copy overhead.

Android Platform Perspective

The Android view hierarchy consists of DecorView → UnicornView (Weex root) → multiple UnicornImageView and a FCanvasTextureView. Rendering is driven by VSYNC, which triggers ViewRootImpl#performTraversals → measure → layout → draw. FCanvasTextureView receives frames via SurfaceTexture callbacks, while UnicornImageView pulls images from ImageReader, converts them to bitmaps, and draws them on the Android canvas. The final display list is processed by HWUI and composited by SurfaceFlinger.

Conclusion and Outlook

Canvas, as a core widget capability, leverages the Weex kernel’s PlatformView mechanism to achieve modular, plug‑in rendering across scenarios, enabling rapid business iteration. However, PlatformView introduces performance overhead. Future work will integrate Canvas more tightly with the Weex rendering pipeline, share surfaces directly, and provide a slimmer rendering chain for interactive widgets.