Measuring Render Performance with Jetpack Compose
Article Summary
Premise's Android team put Jetpack Compose 1.0 through rigorous performance testing before adopting it in production. The results? Surprising insights about render times, cold starts, and optimization strategies.
Will Shelor and the Premise engineering team measured Compose performance across multiple devices and configurations, comparing pure Compose, XML hybrid approaches, and traditional XML layouts. They tested everything from flagship phones to budget devices without Google Play Services.
Key Takeaways
- Compose rendered 33% slower than XML initially, but only 10% with AOT profiles
- R8 and debuggability settings cut render time by over 1 second on slow devices
- First Compose launch took twice as long as subsequent renders due to initialization
- Pre-loading Compose on a splash screen reduced main screen launch time by 400ms
- ComposeView in RecyclerViews was slowest; setContent and base ComposeView performed equally
Despite being 10-33% slower at rendering than XML, Compose's developer productivity benefits and smart caching make it production-ready when properly optimized.
About This Article
Will Shelor's team needed to know if Jetpack Compose's declarative approach would be too slow compared to traditional XML layouts before they could use it in their production app.
Engineers built a test app that rendered a 50-element list in four different ways: pure Compose, XML with ComposeView, RecyclerView with ComposeView, and pure XML. They measured render times from onCreate through the final onDraw calls using Android Profiler and ViewTreeObserver.
They found that EnsureCompositionCreated initialization took about 1 second on first launch but was reused globally after that. By pre-loading Compose on splash screens, they cut subsequent screen launches by roughly 400 milliseconds.