Modular Refactoring and Decoupling Strategies for Large‑Scale Android Applications

Author bio: Zhang Tao, senior Android engineer at Ele.me, blogger of the “Open Source Lab”, and Kotlin advocate, shares his experience from 2013 to the present, including team leadership, architecture design, and open‑source contributions.

The article focuses on project modularization, which resembles refactoring but emphasizes four aspects: removal, organization, degradation, and decoupling.

Modular Refactoring – Removal: By deleting unnecessary files, the .java count dropped from 1,677 to 1,543, and drawable resources fell from 693 to 538, reducing the APK size.

Organization: Code is grouped by meaningful package standards, but rapid iteration and team turnover often lead to chaotic structures that need systematic re‑grouping.

Degradation: A monolithic Navigator class with over 200 startActivity() methods was split into three parts: UserNavigator , ShopNavigator , and a generic Router for inter‑module navigation.

Decoupling: After refactoring, modules without business‑state interfaces can be added or removed without any code changes. Examples show manual Debug state management versus delegating control to Gradle tasks.

The core of this approach is the IronBank library, which uses an annotation processor (APT) to generate classes at compile time, enabling cross‑module object creation similar to SOA. Service providers annotate static creator methods with @Creator , and consumers obtain instances via IronBank.get() without knowing the concrete implementation.

For stateful services, the article introduces BizLifecycle , an interface analogous to Android’s Application that manages business lifecycle events. Modules register a lifecycle via a single annotation, avoiding the pitfalls of broadcast or EventBus patterns.

Architecturally, the project is divided into three layers: business modules at the top, optional functional components in the middle, and shared common dependencies at the bottom.

Platform support: Switching module dependencies to AAR artifacts provides clear version management and simplifies cross‑team collaboration. The platform visualizes module versions, changelogs, and supports seamless testing by swapping AARs.

Two Gradle project structures are discussed: submodule (default Android multi‑module) and multi‑project (independent Git repositories). Each has trade‑offs regarding isolation, build time, and repository management.

Build scripts read local.properties to include source modules dynamically, and naming conventions (e.g., OrderProject ) help avoid conflicts between source and AAR references.

In conclusion, modular architecture follows a “divide and conquer” principle, requiring clear dependency separation, supportive tools like IronBank and BizLifecycle, and automation scripts to maintain a scalable, low‑coupling Android codebase.