Dynamic UI Solution for JD Mobile Apps: DSL‑Based Cross‑Platform Architecture and Implementation

In recent years the rapid growth of mobile internet has driven JD Shanghai's mobile team to seek a dynamic solution that reduces native development effort, package size growth, and release cycles during major e‑commerce events.

The team defined three core requirements for a new framework: cross‑platform support (iOS, Android, H5), dynamic publishing without client version updates, and low cost by allowing non‑technical staff to configure pages through a visual interface.

After evaluating ReactNative and Flutter and finding them unsuitable for fully dynamic publishing, the team designed a custom language protocol based on JSON, called a DSL, to describe view structures, enabling visual configuration, data binding, and runtime rendering.

Key components of the DSL:

Widget: abstract node type.

Layout: positioning method (absolute, linear, flex, etc.).

Style: visual attributes such as coordinates, colors, fonts.

Event: user interactions like click, double‑click, long‑press.

Addressing: data binding path separating data from presentation.

The parsing process follows a three‑step flow: identify container widget type, fetch frame data via addressing, locate the corresponding template, then recursively scan the template to bind data and generate a virtual object tree.

The overall architecture is divided into four layers:

Business layer – mediates external interactions, handles analytics, navigation, network requests, and image loading.

Logic layer – manages component registration, template handling, lifecycle, reuse, versioning, and unified network/image processing.

Abstraction layer – distributes DSL and data to template and data managers, performs virtual abstraction, and builds the virtual tree.

Display layer – compresses virtual nodes, creates real UI components, and updates the view hierarchy.

Template management involves in‑memory lookup, fallback to a local template library, and remote fetching with version comparison, followed by garbage‑collection rules to limit memory usage.

Event handling abstracts event structures, validates them, creates virtual events, binds them to virtual widgets, and dispatches them to registered business components, optionally triggering UI updates via the SDK.

To decouple DSL templates from business data, a mapping configuration translates raw backend data (e.g., product image, name, price) into the fields required by the template. Example JSON snippets are shown below:

{
    "pictureUrl": "http://img.360buyimg.com/455be9563d43b606.jpg",
    "skuName": "精选纯棉好货女装短袖T恤女韩版宽松新款夏季女装半袖上衣",
    "price": "29.90"
}

{
    "image1": "http://img.360buyimg.com/455be9563d43b606.jpg",
    "text1": "精选纯棉好货女装短袖T恤女韩版宽松新款夏季女装半袖上衣",
    "text2": "29.90"
}

Performance optimizations focus on high reuse (view pooling with LRU/LFU eviction), traffic reduction through DSL‑data decoupling, and node‑level pruning to eliminate invisible views, thereby decreasing rendering time.

For downgrade and disaster recovery, the team adopted a progressive enhancement strategy: initially delivering a SPA‑based viewkit‑react package, then extending the same DSL parsing to H5 so that a failing native SDK can be quickly replaced by the web implementation.

The solution has been deployed on JD's main site and international sites (Indonesia, Thailand), supporting both mixed native‑DSL floors and full‑page DSL integration.

In conclusion, the dynamic DSL‑driven architecture enables rapid, cross‑platform UI updates with reduced development effort, controlled package size, and robust fallback mechanisms, positioning JD’s mobile platform for future innovation.