How Weex Powered Alibaba’s Double 11: Architecture, Performance & Scaling

Introduction

Among the many highlights of native development, smooth experience and system calls are most frequently mentioned. Smooth experience appears in page scrolling and animation, backed by better memory management and near‑native performance—areas where Web traditionally struggles (initial download, memory overflow on long pages, scroll and animation performance, JS execution efficiency). Native offers rich system‑call capabilities, while Web suffers from slow W3C standards, limited device access, and API compatibility issues such as poor Geolocation support in Android WebView.

Web development also shines, especially in publishing capability and large‑scale collaboration. Native app store review cycles are long (especially iOS). Web can achieve 99%+ update success within a minute given proper caching. The WebKit kernel provides a relatively consistent runtime, and HTML/JS/CSS control structure, behavior, and style, enabling massive business reuse and collaborative development.

Alibaba’s clients faced package‑size limits and poor H5 page experience during major promotions. Combining native and Web strengths while solving these business problems led to the birth of Weex.

1. Goal

The objectives for the Double 11 deployment were:

Business support – meet Double 11 demand.

Stability assurance – resolve Weex issues before the event.

Instant‑open performance – achieve 97% main‑venue instant‑open rate and 93% overall.

2. Business Support

Weex needed to support the complex venue structure: main venue, all venues, must‑grab, list, and My Double 11, plus sub‑venues and audience‑specific venues.

3. Venue Framework

The interaction flow includes:

Non‑push tab switching: Main → All → Must‑grab → List → My Double 11.

Push navigation: Main → Sub‑venue → Main.

iOS limits open pages to a configurable depth (default 5) to control memory; Android showed no memory growth even with >30 nested pages.

Key components that supported the venue:

List component – provides smooth scrolling, high‑performance memory reuse, and rendering.

Animation component – powers vertical bullet screens and slot visibility effects.

Video‑on‑demand / live‑stream and panorama components – meet personalized business needs.

4. Organization Structure

Multiple teams and platforms participated:

Tmall business – publishes venue pages via Zebra (activity page building and publishing platform).

Taobao business – publishes via Zebra and AWP; DSL uses Rx (to be open‑sourced).

Pre‑loading – downloads JS bundles ahead of time, intercepting network I/O with local file I/O for fast loading.

Hand‑taobao (mobile) clients – Weex coexists with native and H5.

Weex SDK and business modules – core container, components, modules (live, panorama, etc.).

The architecture is divided into:

Business layer – Weex business in Hand‑taobao and Hand‑cat.

Middleware layer – publishing (Zebra, AWP), pre‑loading, client integration, component libraries, game engine, chart library.

Tool layer – DevTools (WebKit‑based), Playground, CLI, packaging tools.

DSL – initially Vue 1.x subset, moving to Vue 2.x; Rx DSL based on React syntax (open‑source Dec 12).

Engine – independent Android, iOS, and H5 render engines.

5. Stability Assurance

Weex’s primary challenge was stability – preventing degradation during the event.

6. iOS JSCore Memory Management

During the August Olympic promotion, repeated entry/exit of the venue caused crashes (iOS 1.59% of crashes, Android 1.94%). Investigation revealed that a single global Weex runtime kept page instances alive, leading to memory leaks. Root causes included:

Business code that unintentionally polluted the global scope (mitigated by lint tools).

JSFM framework issues – not clearing commonModules and dependency targets on destroyInstance; Set polyfill memory spikes on iOS 7.

iOS‑specific problems – VC push‑level control, memory‑warning‑based instance destruction switches, Promise/Polyfill coexistence issues on iOS 9.x.

After forming a task force and extensive pre‑event stress testing, the issue was eliminated.

7. Global Pollution Governance

To avoid global variable leaks, Weex enforces:

Strict mode (`use strict`).

Freezing core objects with `Object.freeze()`.

8. Cross‑Platform Dependency Review

Adapters bridge client‑specific implementations. Inconsistent library versions (network, image, API, H5 container, analytics, config) can cause runtime issues. A dependency‑synchronization mechanism was established to safeguard Double 11 stability.

9. Venue Stress Test

Scenarios included multiple venue pages, panorama, UT expose, and live pages, with push navigation links. The test procedure filled memory caches, measured baseline memory (M0), then recorded memory after scrolling (M1) and after page pushes. Both iOS and Android passed without crashes; Android low‑end devices showed degraded experience under deep stack, prompting VC‑level controls.

10. Stability Data

Crash ratios on 2016‑11‑11:

iOS: 1.46% (TOP 7).

Android Java: 0.85% (TOP 13).

Android Native: 1.72% (TOP 8).

Overall stability was considered good given the traffic volume.

11. Instant‑Open Practice

Instant‑open rate is the proportion of pages whose load time plus first‑screen render time is under 1 s. Pre‑loading dramatically improves load time, making it the biggest contributor to instant‑open success.

12. Pre‑loading

Pre‑loading downloads static resources (HTML/JS/CSS/IMG…) to the client before page access, intercepts network I/O, and serves local files, yielding massive performance gains.

During Double 11, 30 pre‑load packages (>20 MB) were used. iOS pre‑load share: 62.5%; Android: 59.4%.

13. First‑Screen Rendering Optimization

Goals: shorten first‑screen render time via DOM parsing, UI rendering, and segmented lazy loading.

13.1 DOM Parsing – Weex supports `node` (per‑node rendering) and `tree` (whole‑tree rendering) modes. `node` offers immediate display but may cause multiple layouts; `tree` reduces layout passes but can block the main thread for large trees. Typical practice: use `tree` for first‑screen, `node` for the rest.

13.2 UI Rendering – List component maps to iOS UITableView and Android RecyclerView, providing:

Rendering only visible area.

Memory reuse of off‑screen cells.

Cell‑level isolation enabling `tree` parsing per cell.

Native interaction quality.

Goal of 60 FPS requires each render step ( Build Tree, Compute Style, CSS Layout, Create View, Update Frame, Set View Props) to finish within 16 ms.

13.3 Segmented Lazy Loading – Venue pages use List layout; each cell is a module. Initially load six modules, then load more on scroll or when an “elevator” appears.

14. Instant‑Open Data

Main venue peak instant‑open rate (00:00): 96.9% (278.8 ms) overall, 99.4% iOS, 93.4% Android. Average: 94.4% (367.6 ms) overall, 99.0% iOS, 91.8% Android.

All venues peak (00:49): 92.4% (490.7 ms) overall, 97.4% iOS, 87.5% Android. Average: 83.9% (651.9 ms) overall, 94.5% iOS, 78.6% Android.

15. New Starting Point

The Weex Technical Committee was formed in October, held its first meeting on 10‑26, and approved four topics (input focus/blur, 750 px solution, Weex‑Analyze roadmap, standardization draft). The committee will enforce standardization for all official Weex modules, components, and tools.

Future work includes reducing the “pain” of migrating from H5/Native to Weex, addressing typical Double 11 issues, expanding the Weex BigBang project (30+ modules such as schema launch, network type detection, geolocation, audio, cookie, image preview, contacts), and improving cross‑client dependency synchronization.