Componentization and Modular Event Message Bus in Meituan Android Apps

This article presents Meituan's experience with Android componentization and the design of a strong‑constraint component message bus called modular‑event . It aims to help developers who are exploring component‑based architectures for Android applications.

Why componentize? Componentization improves code reuse and reduces coupling between modules, making the codebase easier to maintain and decreasing bug rates.

Pre‑componentization state: The two Meituan cash‑register apps (Meituan Retail Cashier and Meituan Light Cashier) had a monolithic structure where the Business module depended on Service and Platform modules, leading to heavy inter‑module coupling.

Open‑source solutions surveyed:

CC – progressive componentization framework.

DDComponentForAndroid – router + interface sinking.

ModularizationArchitecture – explicit RouterResponse handling.

ARouter – routing engine (not a full component solution).

Jumei Router – similar router‑plus‑interface approach.

Meituan internal solutions examined:

ComponentCenter – supports both interface calls and message‑bus communication.

App ServiceLoader – annotation‑based interface loading.

WMRouter – Meituan Waimai's Android routing framework, providing clear architecture and extensibility.

After evaluation, WMRouter was chosen as the base infrastructure. However, WMRouter lacks a message‑bus component, so the team built modular‑event to fill this gap.

Design goals of modular‑event:

Messages are defined by the component that owns them.

Same‑named messages from different components are distinguished.

Constraints prevent ad‑hoc message creation and enforce type safety.

Implementation highlights:

Two‑level HashMap (module name → event name → LiveData) for storage.

Annotations @ModuleEvents and @EventType mark message definition classes.

An annotation processor generates an interface for each message class (e.g., EventsDefineOfDemoEvents).

Dynamic proxy implements the generated interfaces, routing calls to the appropriate LiveData instance.

Usage example (subscription):

ModularEventBus.get()
    .of(EventsDefineOfModuleBEvents.class)
    .EVENT1()
    .observe(this, new Observer<TestEventBean>() {
        @Override
        public void onChanged(@Nullable TestEventBean testEventBean) {
            Toast.makeText(MainActivity.this, "MainActivity received: " + testEventBean.getMsg(), Toast.LENGTH_SHORT).show();
        }
    });

Usage example (publishing):

ModularEventBus.get()
    .of(EventsDefineOfModuleBEvents.class)
    .EVENT1()
    .setValue(new TestEventBean("aa"));

The framework supports various observation modes (lifecycle‑aware observe, sticky observeSticky, and forever variants) and posting methods ( setValue on the main thread, postValue from background threads).

Conclusion and future work: The article summarizes the componentization practice, the modular‑event design, and outlines future directions such as component version management, reuse across projects, CI integration, and scaffolding support.