Modular Architecture and Inter‑Module Communication in Android Development

With the growth of business and the increase of engineers, many projects adopt modular, component‑based, and plug‑in architectures to facilitate collaborative development and reduce coupling between business domains.

Advantages of Modularization

Clear structure: business logic is isolated and code implementation is separated.

Facilitates collaboration: each developer works on his/her own module with minimal coupling.

Easy maintenance: each module manages its own code, layout and resources; the main project can add or remove modules conveniently. The core characteristics are high cohesion and low coupling.

Common Modularization Approaches

All business modules are placed in a single project.

Each business module is an independent project.

Typical module division includes third‑party SDKs (network, map, push, etc.), platform‑wide common utilities (network wrapper, image loader, permission handling, UI components), and business‑specific modules (login, transaction, membership, hardware, etc.).

Inter‑Module Communication

Even after splitting functionality into modules, communication between them can become a source of tight coupling if not handled properly. Common communication patterns are:

Direct dependency

Event or broadcast communication

Routing communication

Interface‑based communication

Direct Dependency

This method is simple to implement but creates strong coupling, making maintenance difficult as the project grows. It is generally not recommended.

Event or Broadcast Communication

EventBus : a flexible event‑bus framework that uses annotations, but tracing events can be hard.

Broadcast : Android’s broadcast mechanism allows one module to send a broadcast and another to receive it. It is flexible but consumes more resources.

Both EventBus and Broadcast provide loose coupling but suffer from poor readability and traceability.

Routing Communication

Modules do not depend on each other directly; instead, a routing framework maps external URLs to internal pages and handles parameter passing. A popular open‑source solution is Alibaba’s ARouter , which also supports interceptors for login, analytics, and cross‑module API calls.

Interface‑Based Communication

Instead of calling concrete implementations, modules define service interfaces (or abstract classes) that describe the contract. Providers implement these interfaces, and consumers obtain the implementation via a service factory. This achieves high flexibility, low coupling, and avoids serialization overhead.

Practical Engineering Design

In a real project, multiple flavors (e.g., Pad and Phone) may share a common code base. A Mediator module can centralize all service interfaces to avoid proliferating modules. Example structure:

Each business module defines its own service interface (e.g., ICommonService , IService(pad) , IService(phone) ) and implements them in the corresponding flavor module. The MediatorServiceFacator registers and retrieves services using a simple register(Class<?> cls, Class<?> implClass) method.

Service registration can be done via code or annotations. Example registration diagram:

Consumers obtain a service instance lazily through the mediator. If a service is not registered, a null object is returned. The first retrieval creates the instance via reflection and caches it for subsequent calls.

Summary

Routing communication solves coupling but cannot pass object instances directly, requiring serialization and affecting performance. Interface‑based communication avoids these drawbacks, offers higher readability, and supports richer interactions (e.g., controlling a card reader via a service). In practice, the best approach depends on the project’s needs; a combination of routing for simple navigation and interfaces for complex interactions often yields the most maintainable architecture.