Mastering Weex: Build High‑Performance Cross‑Platform Mobile Apps with Vue

What is Weex?

Weex is a simple and easy-to-use cross‑platform development solution that provides a web‑like development experience to build high‑performance, scalable native applications. It works with Vue as the upper framework and follows W3C standards, implementing a unified JavaScript engine and DOM API to achieve consistent native apps across three platforms.

Weex Page Structure

The page consists of interface display, logic processing, device capability usage, and lifecycle management.

DOM Model

Weex pages manage the interface using an HTML‑like DOM. The page is decomposed into a DOM tree where each node represents an independent native view unit. These units are combined in a tree structure to form a complete page.

Components

Weex supports content components such as text , image , video , container components like div , list , scroller , and special components such as slider , input , textarea , switch . The UI is built by arranging these components in a DOM tree.

Layout System

Weex provides three major layout models: the CSS box model, flexbox, and absolute/relative/fixed/sticky positioning.

Functions

Weex offers a rich set of system APIs, including storage, network, navigation, dialog, and toast. Developers can import native modules and invoke these client‑side APIs from a Weex page.

Lifecycle

Each Weex page has its own lifecycle, from creation to destruction, managed through SDK‑defined routing.

Practice in Mobile Office Development

(1) Design Philosophy

Weex advocates a highly parallel, dynamic, and standardized mobile application composed of pages, routing, and device capabilities.

Pages: Independent, URL‑identified units.

Routing: Connects pages via navigation bars, tabs, etc.

Device capabilities: Exposed as APIs or services for pages.

Before building a full app, determine the number of pages, their URLs, routing logic, and required APIs, then develop each page with Weex.

(2) Building a Benchmark Project

Based on the GitHub Playground project, a benchmark project was created, organizing constants, utility methods, and a shared component library.

Constants such as URLs, version flags, and routing tables, as well as utility methods for HTTP, time conversion, and encryption, are defined. A shared style and component library are also packaged.

(3) Integrating the Weex Engine

Glide replaces the default Picasso library to support GIFs and customize cache size. A custom HTTP adapter reuses native HTTP implementation and bridges native and Weex login credentials.

Custom native components are registered via WXSDKEngine.registerComponent(), requiring iOS and Android implementations, version compatibility checks, and careful maintenance across engine upgrades.

Open interfaces are registered with WXSDKEngine.registerModule() to reuse H5 APIs in Weex, with permission handling for privacy‑sensitive calls.

(4) Static Resource Caching

Static resources (JS, CSS, images) lack default caching, causing slow page loads. Client‑side Glide settings and server‑side ETag or Last‑Modified strategies are applied.

First request returns the file with ETag; subsequent requests include If‑None‑Match and receive a 304 if unchanged, enabling cache reuse.

(5) Open API and Permission Control

Weex loads both Weex and H5 pages; H5 pages use a JavaScript Interface with the same set of APIs. Sensitive APIs require user authorization similar to WeChat.

(6) Bridging Login Credentials

Login credentials stored in cookies are shared across Native, Weex, and H5 to achieve Single Sign‑On. A CookieManager is wrapped for read/write compatibility, initialized at process start, cleared on logout, and enforced in WebView and Weex WebView callbacks.

(7) Upgrade Strategy

Both components and modules are added gradually. Compatibility logic checks the minimum client version; if the client is too old, users are prompted to upgrade.

(8) Error Monitoring

Native errors are captured via IWXRenderListener.onException. Weex pages report errors through open interfaces, which are then sent to the cloud for real‑time monitoring.

(9) Screen Adaptation

Weex uses a virtual screen width of 750 px; actual sizes are scaled proportionally to the device width (e.g., a 60 × 100 px button becomes 86 × 144 px on a 1080 px screen).

(10) Engine Upgrade Pitfalls

Frequent engine upgrades can break existing functionality. Issues include missing time‑zone offsets, iOS page‑flip offset, loss of v‑model support, inconsistent broadcast events, and differing touch handling on overlay components. Careful testing and version guards are essential.

Conclusion

Weex is a new development framework that encourages experimentation while emphasizing software process control to ensure stable delivery. Continuous practice and summarization are necessary to stay ahead in the rapidly evolving technology landscape.