Hi all Our team is on the verge of approving Compose usage f

Question

Hi all Our team is on the verge of approving Compose usage for the whole team Since ours is a large app with many layers of legacy View based code we will most likely stay a Compose View hybrid for a long time But some of the team is hesitant to do so They are mostly concerned about the two stack problem described in <https android developers googleblog com 2022 03 play time with jetpack compose html|this> article gt running both Compose and View rendering within a single user session was very memory intensive especially on lower end devices This cropped up both during rollouts of the code on the same page but also when two different pages for example the Play Store home page and the search results page were each on a different stack Hoping the compose team amp others can help answer these Have other folks experienced these performance issues If so what did you do to monitor alleviate Does this mean that if the app is 50 50 View Compose this two stack problem will be exacerbated Will there come a point where we will have to rush to get our app to 100 Compose because of such issues We currently have very rudimentary perf measurements in place so open to recommendations there pray skin tone 3

Colton Idle · Answer

Anecdotal I ve shipped two fully compose apps to production Life is great Developer life is fun again

Tash · Answer

Thanks < Colton Idle> You mentioned they were fully compose was there ever a point where the apps were halfway between View Compose Most of my team s perf concerns are for that configuration specificially

Colton Idle · Answer

We slowly started migrating one app from view based to compose Basically screen by screen But the development went so fast we rewrote the entire thing rather quickly I don t have any hard data to back this up but that s because we never had any real perf issues so we didn t look into anything specifically I m sure someone from the compose team might be able to add more I guess I m lucky I was on small teams and my manager was convinced that this will leave xml in the dust Hiring was easier Design was easier Development was easier There were so many positive ripple effects

Tash · Answer

That does sound really smooth I d imagine that the more Compose you wrote the faster it went i e speed and coverage increased together Thanks < Colton Idle> I ll keep this anecdote in mind

Alexandre Elias [G] · Answer

The problem Play Store ran into is specifically very memory intensive especially on lower end devices A useful marker for low end devices are especially devices with 1GB RAM One data point that might help you make the decision is to gather metrics on what of your user population has that amount of RAM

Alexandre Elias [G] · Answer

If it s a problem one way to mitigate it would be to measure how often your users see different screens and try to stage your transition so that at the 50 50 stage of the transition the majority of users see only Compose stack or only Views stack What I mean by that is that 50 of screens in your app is not 50 of user sessions there is usually a power law in how often users visit different screens So if your app remains a Compose Views hybrid in the sense that a screen visited in 0 01 of sessions like Licences Information is not converted to Compose you can put that off indefinitely and there s no rush to get to 100

Tash · Answer

This was super helpful thank you So by that rationale if perf is an issue it would make sense the most critical path screens to either be majority Compose based or majority View based I think we have been doing it the other way around so far converting things like Licenses Information over to Compose first exactly because it receives very little traffic before we tackle the bigger chunks

Alexandre Elias [G] · Answer

Right for performance metrics screens like that don t matter one way or the other so that s fine too

Alexandre Elias [G] · Answer

What Play ran into as I understand it was long transition times from one common screen to the next when they were on different stacks The first major screen they converted was their search results screen But users never open the app on the search results screen they start on the homepage which was still View based So search results took longer to appear on low end devices as Compose bytecode was getting loaded for the first time

Alexandre Elias [G] · Answer

To mitigate this in the short term they pre warmed the Compose code on the homepage even though it might not end up being used I m not sure exactly what the prewarming looked like I d have to ask them In the medium term they decided to the launch the homepage on Compose before converting further later in user journey screens and worked with us to optimize Compose initial use cost by introducing baseline profiles in particular

Tash · Answer

Going to include all this info in our migration strategy thank you I wonder if one way to pre warm is to use Compose in some small part of the splash screen or something else that the user sees right when they start the app can be something small doesn t have to be a whole screen If that s viable it might be a way to go