Android Migration: From XML to Jetpack Compose - Part 2
Article Summary
Gary Dameme from Yubo shares hard-won lessons from migrating a production Android app to Jetpack Compose. Spoiler: rewriting XML is the easy part.
In Part 2 of their migration series, the Yubo team dives into the performance challenges that emerged after building their first Compose screens. This isn't theory—it's battle-tested optimization strategies from an app serving 80 million users.
Key Takeaways
- Unnecessary recompositions killed performance until they enforced @Immutable and @Stable annotations
- Custom debug modifiers visually highlight components recomposing too frequently in dev builds
- Extracting frequently updating UI into separate composables isolated recompositions dramatically
- Built a simplified image preloader for lazy lists that's easier than RecyclerView patterns
- Baseline profiles added maintenance overhead with no measurable performance gain for their use case
Compose's declarative model requires new performance strategies: stability annotations, extracted composables, and custom debugging tools made the difference between sluggish and smooth.
About This Article
Compose relies heavily on JIT compilation, which slowed down the UI noticeably after app installation. The framework generates a lot of dynamic code during compilation, more than XML-based views do.
Yubo tried baseline profiles to precompile critical code paths during installation. They decided against it in the end because the maintenance overhead was too high.
Baseline profiles could have improved startup times and runtime performance, but Yubo found the maintenance burden wasn't worth it. Their specific use case didn't see measurable gains.
