Platformization and Code Reuse Practices in Meituan Waimai Android Client

Since its launch in 2013, Meituan Waimai has grown to handle over 18 million orders per day, expanding from a single standalone app to multiple entry points and covering more than ten business categories. This rapid growth created increasing pressure on the client architecture.

Platformization background – Initially, the Waimai app and the Waimai channel were developed separately, leading to duplicated codebases with divergent libraries, UI components, and naming conventions. Even after team consolidation, maintaining two codebases became unsustainable.

Repeated explorations – The team tried several solutions:

Search library split: extracted the search module into a separate library and attempted to share it across both sides, but differences in base activities, fragments, UI styles, data models, and release cycles caused the library to diverge into two branches.

Page componentization: broke pages into fine‑grained components containing UI, data, and logic, but large differences between the two sides limited large‑scale reuse.

MVP layered reuse: applied Clean MVP architecture (Presenter, Data Repository, Use Case, View, Model) and used adapters to hide side‑specific differences.

Middle‑layer approach: attempted to wrap network libraries (Volley vs. Retrofit) in a unified layer, but the effort outweighed the benefits, so Retrofit was adopted directly.

Platformization practice – The final architecture separates the client into three layers: platform layer (core services, configuration, common infrastructure), business layer (Waimai core and vertical businesses), and host layer (app shells, dex loading, initialization). Each layer is isolated into its own Gradle project to preserve clear boundaries.

To maintain these boundaries, the team introduced engineered isolation :

Project‑level isolation for each layer.

“p‑engine” modules for page‑level granularity, each with its own source sets.

Gradle productFlavors (wm, mt) to handle side‑specific code within the same module.

Example Gradle configuration for source sets:

sourceSets {
    main {
        def dirs = ['p_widget','p_theme','p_shop','p_shopcart','p_submit_order','p_multperson','p_again_order','p_location','p_log','p_ugc','p_im','p_share']
        dirs.each { dir ->
            java.srcDir("src/${dir}/java")
            res.srcDir("src/${dir}/res")
        }
    }
    wm { /* similar for wm flavor */ }
    mt { /* similar for mt flavor */ }
}

Additional tooling includes a Gradle plugin for one‑click source‑code switching between AAR and project dependencies, and an automated one‑click packaging pipeline that builds platform AARs, updates version references, builds business AARs, and finally packages the channel AAR.

Summary – Over two years of iterative architecture work showed that forced top‑down splits cause boundary confusion, while clean layer separation, modular engineering, and gradual unification of low‑level dependencies enable sustainable code reuse across multiple product lines.

Outlook – Future work focuses on improving toolchains for continuous integration, adopting plugin‑based integration for dynamic delivery, and standardizing page‑level development frameworks to further enhance maintainability and testability.