Modularization - flatten your graph and get the real benefits
summary
Modularization strategy enforces module rules via a Gradle plugin that fails the build on illegal dependencies, extracts tiny API modules to break serial longest paths, and uses Android Studio dependency analysis to find hubs. Measured effects include 33–70% local build reduction, ~50% CI time drop and ~100–400 ms overhead per module on M1; enabling nontransitive R classes shrinks duplicate resource R.java (observed up to 50 MB) and reduces IO and startup issues.
AI-written summary · about
chapters (17)
- 0:00Introduction to modularization
- 1:08Why modularize your app
- 3:34Understanding the module graph
- 5:18Impact of module graph on builds
- 8:26Module rules and enforcement
- 10:13Flattening the module graph
- 13:00Enforcing module rules with Gradle
- 14:24Key metrics to track progress
- 17:29Longest path and build time
- 18:54Analyzing module dependencies
- 20:19Common modularization traps
- 23:46Cost of too many modules
- 25:31R class and resource issues
- 27:15One place for multiple features
- 29:19Business impact of modularization
- 33:09Measuring collaboration benefits
- 35:16Next steps and key takeaways
related talks
30mSolid Modularization - Untangling the dependency graph
35mThe Costs of Modularization
17mStructuring modules in an Android app project
33mImprove the build times of your project
37mHow to make Kotlin compile 2x faster
41mBreaking the build
44mBest practices for a modularized app
27mFaster builds on Android: from 2 minutes to 2 seconds