Does anyone else notice that Compose takes some ti...
# compose
s
Does anyone else notice that Compose takes some time to "warm up" when used in Android Views? In our project we're relying on Android interop to integrate Compose into existing fragments, and first screen open produces a lot of skipped frames/lag, but consequent launches are a lot more smooth I'll try to isolate it and create a repro, but just wondering if it's an us problem, or a Compose internals problem
d
I/Choreographer: Skipped 53 frames! The application may be doing too much work on its main thread. This is at the start of an app with a very flat view, there is even a database call before any view is shown which gets the data to show
a
Yes, we're addressing this on multiple fronts as we speak. The root issue is that after initial installation, on modern versions of ART the app runs in interpreted mode briefly before the JIT compiler kicks in. After a few days of collecting profiling data, the device will create a fully ahead of time compiled version of the app code that it will use from there on. What you're seeing is that brief period of time where compose is running in interpreted mode.
This affects all library and app code included in your apk
a couple years ago we launched cloud profiles, which speed up this process: https://android-developers.googleblog.com/2019/04/improving-app-performance-with-art.html
and if you aren't already running r8 on your release builds, it performs a lot of whole-program optimizations that help apps run faster during these interpreted periods. Definitely test against r8-optimized release builds too.
On the compose side we're looking at a few things: we're doing internal optimizations in compose-runtime and compose-ui to make the code friendlier to the interpreter, we're investigating additional code generation optimizations in the compose compiler plugin, and additional optimizations that r8 can perform on the kinds of code that Compose uses and incentivizes writing
we're also working with improving or making further use of the systems for delivering profiles ahead of time, to get the fully compiled benefits more quickly and more often.
l
@Adam Powell Is there public issues we can follow for these 2 latter WIP things?
a
I don't believe so, unfortunately. They're in some investigative stages.
๐Ÿ˜ž 1
If you'd like to help us gather data from your code and use cases, https://perfetto.dev/docs/quickstart/android-tracing shows how to record performance traces that can be very helpful for us. Traces with and without r8 are helpful, both is even better. We can write our own test cases but those are illustrative of the kind of code we write, not necessarily the kind of code you write ๐Ÿ™‚
p
I have this issue with androidView and map. First time is slow parrot , but next one is fast
a
TIL about slow parrot ๐Ÿ˜‚
๐Ÿ™‚ 1
l
@Adam Powell I dumped a bunch of emojis you might be familiar with blob wink
๐Ÿฆœ 1
a
I'll poke the relevant folks to see what we can track on the public issue tracker as the actual work items take shape. Right now it's a lot of shared google docs that various folks on the team are commenting on and gathering data around
๐Ÿ™ 2
@Piotr Prus I totally believe it. MapView uses some very interesting code loading strategies that I'm sure put it on similar paths here, with or without compose.
l
Even broad ones would be cool to have, similar to the tickets linked from kotl.in/roadmap
๐Ÿ‘ 1
a
yep, that's a good example. We've been discussing good ways to get more of these roadmap tidbits out in the open and keep it low-friction enough that they don't fall out of date
even just something as simple as markdown docs in the repository
l
Issues are great because you can subscribe to them, unlike repository files.
a
yes, but they're particularly poor for early investigations or for living documents.
l
Unless you use YouTrack, where you can edit issues, including original post, and watching people receive emails for all the changes blob wink
๐ŸŽ‰ 1
val issue: Issue
->
val latestIssue: Flow<Issue>
blob smile
r
So this affects even Compose-only apps? There's a slight lag I've always noticed at app startup but haven't had time to look into.
a
There are a lot of factors that play into app startup performance, not just this. But this is one area we're tracking closely that affects all code included in an apk, not just compose.