Hi all! Our team is on the verge of approving Comp...

# compose

[Tash]

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 this article:

…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 & 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. 🙏🏼

[Colton Idle]

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

[Tash]

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]

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]

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]]

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]]

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]

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]]

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

[Alexandre Elias [G]]

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]]

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]

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