Android Guild Week 2: More Modules
Article Summary
Strava's Android team hit a wall trying to modularize their codebase the traditional way. So they flipped their entire architecture upside down.
During their second Guild Week, Strava's Android engineers were extracting features from a monolithic module into separate modules to improve build times and code separation. After days of untangling dependencies, they realized their downstream extraction approach was too slow.
Key Takeaways
- 74% of code still lived in the handset module after initial modularization
- Switched from pulling features downstream to pushing them upstream
- New approach enables Gradle caching and faster incremental builds
- Moving working code first, then decoupling iteratively
By inverting their module dependency graph, Strava can now modularize features in days instead of weeks while unlocking build performance gains.
About This Article
Strava's Android team lost days sorting through tangled dependencies when they tried to move ChallengesActivity and related classes out of their monolithic handset module into smaller feature modules. This became a major bottleneck for their modularization work.
Todd Santaniello's team flipped their approach. Instead of pulling code downstream, they pushed feature modules upstream of the handset module. This let them move working code first and decouple gradually without having to solve all the dependency problems upfront.
The new structure means Gradle only compiles the feature modules that changed during development, skipping the 60% of code in handset. Build times dropped noticeably because of better caching and incremental compilation.