Dynamic Message Card Architecture for Mobile Apps Using Weex

Overview

The message service is a shared component in Youzan Mobile, serving as a multi‑customer service tool in B‑end apps (e.g., Micro‑Mall, Retail, Beauty) and as a communication bridge in C‑end products. It connects merchants and buyers through various message cards.

Pain Points

More than 30 types of message cards (text, rich text, voice, image, video, notifications, order details, product recommendations, etc.) are currently implemented natively. As the number of cards grows, development and maintenance become labor‑intensive, and updates require a client release, reducing flexibility.

Current Situation

Both iOS and Android use a second‑party library approach (CocoaPods for iOS, Gradle for Android) to expose the message service to all Youzan apps. Adding a new card type typically takes 1–1.5 weeks, and the release cycle is long.

Dynamic technology allows adding or modifying cards without a client release, which is crucial for fast‑iteration scenarios. Its main benefits are increased efficiency, shortened iteration cycles, resolution of long‑tail version issues, and reduced package size.

Native Message Card Architecture (iOS Example)

The iOS implementation follows an MVVM pattern with a TableView container. Key modules include:

Configurator – binds view controllers with data sources and manages messages.

Message API Manager – handles sending/receiving, retransmission, and CRUD operations.

TableAdapter – implements TableView delegate/data‑source methods and view refreshes.

ContentFactory – creates content views based on message type.

ContentConfig – provides size, payload, and view for each card.

Layout Model – caches size and payload for performance.

Cell – loads the appropriate content view.

ContentView – renders UI and binds data.

The overall architecture diagram is shown in the original article.

Solution: Introducing Dynamic Capability with Weex

Why Weex?

Weex is already a core technology in Youzan Mobile (ZanWeex platform). It supports hot‑reload, real‑time data delivery, and has been used extensively across business modules.

The core idea is to embed a Weex container inside a native view (using a WXSDKInstance ) and render dynamic cards without modifying the existing native MVVM structure.

Dynamic Capability Design

Create a lightweight Weex container using a plain UIView (not a full ViewController).

Wrap the container in a native TableViewCell and reuse it via the TableView’s recycling mechanism.

JS Dynamic Library

The team’s JS dynamic library provides:

URL resolution for Weex cards based on message type.

Width/height calculation for Weex cards by parsing the message payload.

Dispatching of messages that require Weex rendering.

Identification of Weex‑based cells at runtime.

Integration Steps

Expose a method in the JS library to obtain the Weex URL for a given message type.

Expose a method to compute the cell size from the message content and type.

Expose a method to list message types that support Weex cards, so native registers the corresponding cells.

Performance Considerations

We leverage native TableView/RecyclerView reuse. For iOS, the Weex URL is used as the cell identifier. To avoid repeated rendering, the container records the last loaded URL; if the same URL is requested again, the existing WXSDKInstance is refreshed instead of recreated, reducing render overhead and preventing brief blank spaces during fast scrolling.

Overall Process

When the message channel connects, the Weex module fetches the registered page and initializes the JS dynamic library.

The backend pushes message data, which is parsed into a layout model and cached.

The ContentFactory forwards the message type to the JS side to decide if a Weex card is needed.

The ContentConfig sends the message payload and type to the JS library to obtain the Weex card size.

The TableAdapter loads the appropriate Weex cell, using the URL as the reuse identifier.

During cell rendering, the native side passes the message type to the JS library, receives the Weex URL, and renders or refreshes the Weex view accordingly.

Optimization & Future Work

Although the solution is stable and improves development efficiency, further improvements are planned:

Optimize component creation, layout calculation, and data binding caching for better performance.

Standardize event handling for navigation to product details, order details, native pages, and WebViews.

Extract the dynamic framework into an SDK for reuse in other business scenarios (e.g., activity pages).

Conclusion

The presented approach combines the existing native MVVM architecture with the Weex stack and a JS dynamic library to achieve fully dynamic message cards without requiring app releases. It serves as a lightweight, extensible solution for dynamic UI in mobile applications.

References

https://weex.apache.org/zh/

基于weex的有赞无线开发框架