:alphabet-yellow-question: Does anyone know if the...

# compose

[darkmoon_uk]

alphabet yellow question Does anyone know if there's a public 'Compose Roadmap'?

I ask because my team are currently facing a strategic problem with Compose - in a similar manner to

this story▾

(great talk!) we unfortunately 'bounced off' Compose due to performance issues and are having to roll back to XML Views. 😢

We, too, really tried: We avoided recomposition, toyed with RecyclerView/Compose frankenstein components, tried using baseline profiles, loading the runtime earlier etc. I just think that fundamentally the fixed hardware platform we currently deploy to lacks the slight extra power required to absorb the current overhead of the runtime.

Are there any performance improvements/optimisations that are possible and planned for?
Keen to know if it'll be worth revisiting in a release or two.

[ephemient]

https://developer.android.com/jetpack/androidx/compose-roadmap

[ephemient]

the current performance focus is mentioned at https://android-developers.googleblog.com/2023/03/whats-new-in-jetpack-compose-march-23-release.html

Performance improvements in Modifiers

This refactoring should bring performance improvements to these APIs, and you don't have to change your code to receive these benefits. Work on this continues, and we expect even more gains in future releases as we migrate Modifiers outside of the ui module.

[darkmoon_uk]

Perfect - and performance at the top - thanks @ephemient 🙌

Hopefully there is still scope for some significant performance gains.

[Joel Denke]

One major mistake I have seen in all these kind of reviews, its not focusing on how it would be if 100% compose and latest frameworks, rather inject Compose partly into existing codebase. Like mixing LazyColumn and RecyclerView is mostly very hard doing the "right way".

This meaning juggling around a lot of old frameworks making app temporary larger and causing performance loss by map back and forth.
There is for sure some optimizations Google done recently in Modifiers to make it avoid recompositions. But even if had infinite recompositions in 100% compose app, it still performed well when I tested it in performance consumed uis with animations and such.

Imo true comparison has to be done with existing codebase and rewriting same codebase with only compose, to be sure comparing. Otherwise just comparing "bad" combined frameworks imo. Thats the biggest mistake in my opinion can do, not evaluating frameworks, just evaluating if can use what you already have in new technology. Which mixing problems not Compose issue.

Also a lot of Android apps has not setup Application properly and initialize a lot of stuff, and not using Baseline profiles in the most optimal way.

And yes I am aware Compose will be improved further with more optimized code.
As of example I am encoruage everyone to use the fastForEach loops instead of regular ones in Compose to allocate lest garbage in JVM not really needed when looping items inside Compose UI 🙂 That itself do major impact in performance when doing that in many cases.

[darkmoon_uk]

I completely agree @Joel Denke, that negative performance aspect of running 'two frameworks at once' wasn't lost on me either. Unfortunately with a legacy project, deliverables and people we just weren't afforded the space to get a 'pure' Compose UI PoC on top of the Apps logic going this time around.

[darkmoon_uk]

That will be the next approach, probably some months later now.

[darkmoon_uk]

We have some internal Apps that are pure Compose with acceptable performance on the same hardware. It's what lead us to attempting to introduce Compose in the main product, but there we found our limits.

[Joel Denke]

As of example combining RxJava and Coroutines causing a lot of overhead in both app size and delegating threads non optimized.
Or combine multiple layers of nested ComposeView and AndroidView in both directions in many layers.
Inflation between regular View and Compose node rendering in Canvas cant then really be optimized in same way.
I think thats the main framework issues I have seen.

I do see the reason want to pre-evaluate framework before commit to refactoring or so. But the partly/sub-refactoring will cause issues by itself which probably gone once completing refactoring.
But looking at the largest companies in the world, Compose has been a success story as far as I have seen. Sure there is some bottlenecks as well, Compose is not bullet proof.

But I would say in my opinion, ONLY by look at average compose + Kotlin reduce code by 2/3 compared to XML + styling + resources etc and Live Preview incremental building UI faster, that itself is very cost effective and much more valuable compared to eventual performance loss, if not very critical parts being to slow.

In all places I migrated to COmpose, it has increased developer happiness, cheaper code less code, better performance and less bugs once get true Compose app.

[Joel Denke]

I think this can also be applied to any library/framework evaluation aspects. Seen similar try comparing Flutter, React Native, Compose multiplatform etc.
Its almost impossible to compare in the end per each codebase you want to apply it on.
It more depends what developers you have, time and future scaling and limitations.
It will never be possible to do true comparison, and performance comparison is imo the least important aspect if not being military airforce or cars realtime feeds, but then problably not using Compose or any of these anyway 😄

[darkmoon_uk]

Yes, the advantages are evident, and performance should not be signficantly different in a pure implementation. It seems making the technical transition to Compose in an existing product remains an 'interesting' problem however 🙂 _'It will be fast in the end, just trust me_' doesn't always work, need a tactical path that manages expectations and is acceptable to business etc.

[Joel Denke]

The faster migration, the less bugs will occur in meantime imo 😄 Not fast is in rushing or stressfully refactoring, thats never good.
Fast as in commiting to phased migration in smart way 🙂
I think a good approach if not using Kotlin and Coroutines is to move the part of codebase being that first, then easier to integrate into Compose.
Also if doing a lot of platform dependant code in UI layer, its always a good idea decouple that from UI layer regardless of framework..

[darkmoon_uk]

One problem you already mentioned: We still have some Rx and Coroutines coexisting.

[darkmoon_uk]

Although the migration to Coroutines is quite well advanced in most places.

[darkmoon_uk]

We should complete this before trying again.

[Joel Denke]

@darkmoon_uk I could probably give a long list of money saving business cases by using Compose, but hard to convince time invested short term vs longterm. There is always an initial cost, but the cost of let all being the "old" way to long time, the cost will increase over time.
One nice argument is saying it takes 2/3 times shorter to implement new features in COmpose.
That can be strategy to build new features in Compose and the time saved doing so, can refactoring the other stuff 😜

[Joel Denke]

Also they have a nice roadmap here:
https://developer.android.com/jetpack/androidx/compose-roadmap

[Joel Denke]

The major themes in focus for the next release are:

Performance
More support for advanced use cases
Expanded Material 3 component set
Improve tools, including Preview and Live Edit
Platform support: Compose Wear, large screens, homescreen widgets, TV Compose

🙂

[romainguy]

Performance is indeed our top priority and we’re looking at many potential improvements, but it’s always helpful when we get reports from “real world” apps. If you don’t mind and if it’s possible for you, please consider filing a detailed report in our issue tracker to make sure we address problems you ran into.

[romainguy]

Hopefully we will be able to solve your issues in the next versions of Compose