Containerization Architecture for Meituan Waimai Order Page

The order page ("提单页") is a critical component in Meituan Waimai’s ordering flow. As business requirements grew, the page accumulated more than 30 UI modules, leading to heavy logical coupling and a rapid increase in client package size. To address these issues, the team introduced a containerization solution that enables dynamic composition of modules without direct dependencies.

Background

The order page receives traffic from various entry points (home page, order list, flash‑sale channels, etc.). Different business units maintain separate modules (address, merchant info, discounts, invoice, etc.), causing tight coupling between the core order page and these modules.

Problems and Challenges

Low demand for full‑page dynamism, but API changes are costly, so conversion must happen on the client side.

Order page modules have more complex interaction logic than simple home‑page widgets (e.g., invoice module needs to update data after a sub‑page operation).

Modules are grouped by function, and their UI styles differ, requiring an extra outer container to unify appearance.

Key technical challenges include module registration without direct dependencies, API data distribution, inter‑module communication, and page refresh/update handling.

Design Overview

The container framework consists of three core capabilities:

Function node extension and communication.

Configurable (dynamic) module creation.

Data distribution to child modules.

A Root Block serves as the entry point, holding a Root Block Context that acts as a communication bus. Each module is represented as a Block (or LogicBlock if it has no UI). A Block contains a BlockView (UI) and a BlockViewModel (data layer).

Block Registration

Android uses annotation processing (APT) to generate factory classes that map a native ID to a Block class. Example registration code:

@DynamicBinder(nativeId = "block_key_d", viewModel = blockDViewModel.class, modelType = blockDInfo.class)

iOS relies on the Kylin library, which writes {nativeKey, data} pairs into a special section of the binary. The registration macro looks like:

#define PGA_ELEMENT_REGISTER(NATIVE_ID, PGA_ELEMENT, PGA_VIEW_MODEL)  \
    KLN_STRING_EXPORT("AppKey_"#NATIVE_ID"", "{ \"#PGA_VIEW_MODEL\": \"#PGA_ELEMENT\" }");

API Data Structuring

Original flat API responses are transformed into a hierarchical format where each functional group has its own JSON object. Example of the original response:

{
  "data":{
        "xxx_pay_by_friend": true,
        "xxx_by_friend_tip": "发给微信好友，让TA买单",
        "xxx_by_friend_bubble_desc": "找微信好友买单",
        "xxx_friend_order": false
  },
  "code":0,
  "msg":""
}

After restructuring:

{
  "data":{
       "pay_by_friend":{
          "xxx_pay_by_friend": true,
          "xxx_by_friend_tip": "发给微信朋友，让TA买单",
          "xxx_by_friend_bubble_desc": "找微信好友买单",
          "xxx_friend_order": false
       }
  },
  "code":0,
  "msg":""
}

The layout_info array then defines the order and hierarchy of native IDs, e.g.:

{
  "layout_info":[
      {"native_id":"order_pay_by_friend","data_key":"pay_by_friend"},
      {
        "native_id":"block_container_default",
        "children":[
          {"native_id":"order_flower_cake","data_key":"flower_cake"}
        ]
      }
  ]
}

Inter‑Module Communication

Two patterns are used:

Command : Wrap data in a command object and execute it on demand.

//声明事件容器
private SupplierCommand<Object> mSupplierCommand = new SupplierCommand<>();
@Override
public SupplierCommand<Object> getSupplierCommand() {
    return mSupplierCommand;
}
//注册实现
context().getSupplierCommand().registerCommand(new Supplier() {
    @Override
    public Object run() {
        // implementation
    }
});
//获取相应的Object对象
context().getSupplierCommand().execute();

Event : Publish‑subscribe model where observers react to triggered events.

//声明事件容器
private SupplierEvent mSupplierEvent = new SupplierEvent();
@Override
public SupplierEvent supplierResponseEvent() {
    return mSupplierEvent;
}
//实现订阅
context().supplierResponseEvent().subscribe(new Action() {
    @Override
    public void action() {
        // implementation
    }
});
//触发相应的操作
context().supplierResponseEvent().trigger();

Benefits

Development Efficiency : Modules are isolated, allowing parallel work without merge conflicts.

Controller Slimming : Business logic moves from bulky MVC controllers into Blocks; iOS controller lines dropped from 2894 to 289.

Package Size Reduction : Separate codebases for delivery and flash‑sale modules prevent cross‑impact on bundle size.

Cross‑Platform Alignment : Android and iOS now share the same native IDs and data contracts, reducing divergence.

Dynamic Configuration : Module visibility, order, and presence are fully driven by server‑provided data.

Conclusion and Outlook

The containerization of the order page standardizes core page development across Meituan Waimai, paving the way for further dynamic UI techniques (Mach, RN) and extending the approach to other critical pages such as the order‑status page.