Mastering Android Componentization: A Practical Guide to Modular Mobile Apps

1. What Is Componentization

Componentization means assembling multiple independent sub‑modules into a whole to reduce coupling; each sub‑module can be freely combined and run independently.

1.2 Reasons for Componentization

A single‑module architecture leads to heavy code coupling, slow compilation, difficulty scaling teams, and limited code reuse for new apps.

High coupling makes a small change affect many business modules, raising maintenance cost.

Team expansion requires isolated development to avoid conflicts.

Large codebases slow compilation and reduce developer efficiency.

Future independent apps need reusable components for rapid development.

1.3 Goals of Componentization

The redesign aims to increase reuse, lower coupling, enable independent development, speed up compilation, allow flexible assembly of new applications, and maintain a unified technical solution.

Improve component reuse and save development/maintenance cost.

Reduce business module coupling for easier migration.

Allow each business module to be developed, compiled, and tested independently.

Enable separate compilation to accelerate builds.

Support rapid generation of other apps by flexibly combining components.

Ensure consistency across multiple apps sharing the same components.

2. Componentization Practice

2.1 Architecture Diagram

The architecture consists of three layers:

Host layer : an empty shell app containing global configuration and the main Activity, without business code.

Business layer : isolated business components that depend on each other only through a router bus.

Platform layer : common SDKs and utility code used by all business components.

Modules depend only on lower layers, avoiding cross‑layer and same‑layer dependencies.

2.2 Creating Components

Use Gradle multi‑module projects. Add each module in settings.gradle and provide a dedicated build.gradle for it.

Extract common_component for shared utilities, network libraries, and database code.

Extract the simplest business component, moving exclusive files to the module and shared files to common_component.

Repeat the extraction for other components, continuously refining common_component.

Add a routing framework to handle UI navigation and inter‑component communication.

Refine common_component by moving specific utilities back to their respective business modules.

2.3 AndroidManifest Merging

Each module declares its own AndroidManifest. During the build, all manifests are merged so that components and permissions appear only once in the final app.

2.4 Global Variable Configuration

Define a base Application class in common_component to provide a shared context. Expose BuildConfig values through the common module so that business components can access global configuration.

2.5 Resource Conflict Resolution

Use resourcePrefix to avoid naming collisions for XML resources; manually prefix image resources because resourcePrefix does not affect them.

2.6 Unified Configuration Files

Manage dependencies across modules with Kotlin + buildSrc, which offers IDE auto‑completion and centralized version control, improving consistency and reducing manual errors.

2.7 Routing Framework (ARouter)

ARouter provides compile‑time generated routing tables for UI navigation and supports interface sinking, allowing components to expose services without tight coupling.

2.8 Message Bus (EventBus)

EventBus enables many‑to‑many communication without components needing to know each other, simplifying cross‑page interactions; however, it requires strict guidelines to prevent uncontrolled traffic and maintenance difficulties.

2.9 Independent Component Execution

Configure a boolean isRunAlone in gradle.properties to switch a module between application (stand‑alone) and library (integrated) modes. Use a src/debug folder for code and resources that should only be present when the module runs alone, ensuring no impact on the final release.

Conclusion

Componentization clarifies business boundaries, speeds up onboarding, improves maintainability, isolates issues to individual modules, and ultimately boosts development efficiency for large Android projects.