Platformized Code Reuse in Meituan Waimai Android: Challenges and Solutions

Meituan Waimai’s platformized reuse refers to multi‑terminal code sharing across the Waimai App and the Waimai channel of the Meituan App. The two products have almost identical business logic but historically diverged codebases, causing duplicated effort when a feature is released on one side.

The article first outlines the background of this reuse problem and lists the main difficulties: differing base services, component implementations, and UI/pages.

Early Exploration

The team tried a “delegate + inheritance” approach on a shared “KingKong” page, introducing KingKongDelegate for lifecycle dispatch and KingKongInjector for platform‑specific APIs. While this unified network and data models, it failed to hide Activity differences and produced a bulky injector interface.

Platform Reuse Design

Four key concerns were identified: unified management of differences, reuse of base services, reuse of common components, and reuse of pages. The final architecture is layered as follows:

Base Service Layer – shared network, image, monitoring libraries; abstracted services (login, location) hide platform differences.

Base Component Layer – shared models, analytics, pull‑to‑refresh, permissions, utilities.

Business Layer – feature modules such as list pages, merchant detail, order flow.

Host Layer – application initialization, dex loading, etc.

This separation ensures upper layers do not perceive lower‑layer differences.

Differential Management

Two strategies were evaluated:

Branch‑based management – separate Git branches (wm for Waimai App, mt for channel) for each feature. This leads to many branches and coarse‑grained control.

Flavor‑based management combined with a “pins” project – each platform defines a Gradle productFlavor (wm, mt). Common code lives in a shared source set, while platform‑specific code resides in flavor‑specific directories.

The Gradle configuration looks like:

productFlavors {
    wm {}
    mt {}
}

The pins project further splits the codebase into tiny, independently compiled units (e.g., a single Java file), allowing fine‑grained reuse and easier dependency control.

Base Service Reuse

Base services such as networking (switching from Volley to Retrofit) and image loading (Fresco to Picasso) were unified across platforms. Unifiable services are abstracted; non‑unifiable ones expose a common interface so upper layers remain unaware of differences.

Component Reuse

Common functionalities (pull‑to‑refresh, pagination, logging, exception handling) are extracted into reusable components. Components are categorized into generic, business‑specific, and UI‑public modules, each managed via the pins‑flavor mechanism.

Page Reuse

Pages are modularized into high‑cohesion, low‑coupling blocks (Block). Each block follows MVP and can have flavor‑specific implementations, allowing the same page skeleton to be assembled on both platforms despite UI differences.

Summary and Outlook

The platformized reuse effort achieved an overall code reuse rate of 88.35% and a productivity gain of over 70%. Future work includes extending reuse to Meituan’s other platforms (e.g., Dianping) and applying the same principles to monitoring, testing, and DevOps tools.