Comparing Jetpack Compose Performance with XML
Article Summary
OkCredit ran a fascinating A/B test: Jetpack Compose vs XML layouts in production. The results surprised them—and reveal what most teams miss about Compose performance.
The OkCredit Android team measured frozen frames, slow frames, and page load duration across two identical screens built with different UI frameworks. They tested with real users in production, then dug into Android Runtime (ART) compilation to understand the performance differences.
Key Takeaways
- Initial Compose screen had 2.5x slower page load than XML (median duration)
- Frozen frames were similar: 0.044% for Compose vs 0.034% for XML
- Preloading Compose components reduced frozen frames by 70% and page load by 35%
- ART uses JIT for Compose initially but AOT compilation improves subsequent loads
- XML components are always precompiled, giving immediate performance advantage
Jetpack Compose performance matches or beats XML once components are precompiled, but first-load experience requires strategic preloading.
About This Article
Pratham Arora's team wanted to know if Jetpack Compose's early performance issues were built-in or caused by how ART's just-in-time compiler worked. They needed to dig into the bytecode compilation behavior to find out.
OkCredit switched a second screen to Compose before testing the first one. This let ART pre-compile the Compose components ahead-of-time as users naturally navigated between screens. They also analyzed function logs to confirm the effect.
Once Compose components were preloaded, frozen frames dropped by 70% and median page load time improved by 35%. This showed that ART's ahead-of-time compilation actually removes Compose's initial performance problem.