We’ve been having issues with scrolling performanc...
# compose
v
We’ve been having issues with scrolling performance, mainly with nested lazycolumns - one of the suggested fixes is the following - does it work? Any other tricks? “Make sure in release variant minifyEnabled is set to true and the ProGuard file is proguard-android.txt instead of proguard-android-optimize.txt”
n
Maybe try taking a look at this? https://developer.android.com/jetpack/compose/lifecycle#skipping tldr you can mark inputs with
@Stable
, when appropriate, which should help cut down on the number of recompositions
s
What's inside the lists?
v
This is a movie streaming app so multiple trays and each tray has images.
s
What size of the images?
Ideally it should not be bigger then ImageView size
v
It varies - can be landscape or portrait thumbnails of different aspect ratios
Images are not bigger than imageview size
s
are you sure? For instance, Coil does not resize loaded image by default
v
Yes we pass aspect ratio in the image request to get the correct size from the cdn
s
How does aspect ratio compare to image view size?
v
Am sure we load exact image
Items in each lazyrow even when there are 20 images load reasonable ok
w
I did an analysis of build and render performance a few weeks ago. What I found was: Debug sped our render time by around 30%, and R8 sped up render time by another 30%- so final render time with debuggability off and R8 on was around 1/3 of render time at development time.
A few other tips and benchmarks in the article, feel free to check it out! Render performance is definitely slower than XML, but there are a few things you can do to narrow the gap. One big piece is the JIT compilation of Jetpack Compose bytecode, which can be improved using the new Jetpack ProfileInstaller, but it’s a pretty advanced utility with very little documentation.
v
Thanks @Will Shelor Yes had reviewed ur article earlier and implemented the suggestion...There is still a decent lag... Except profileinstaller and startup library cant think of anything else we can try out
Hmmm to push things tried on a 2013 HTC One .. most other apps run okish…. as u can see the lags when scroll down to next trays it keeps stopping.
s
@VM Hmm, then profile your code to find the bottleneck, or share some code snippets, maybe someone will take a look and suggest something. You can also try to force AOT compilation on your device. How to do it: 1) build an APK in release mode with R8 minification enabled 2) install it on the device, but don't run it yet 3) run the adb command in the terminal:
adb shell cmd package compile -r bg-dexopt your_application_id
4) wait until it say "success" 5) run the application
What version of Android do you have on your device? If it is 5 or 6, then it is already fully compiled by AOT compiler. Hybrid AOT + JIT was introduced in Android 7, which compiles under profile control.
but it seems to me that the problem is still somewhere on the side of the application code (too large pictures, that shimmer animation), unnecessary recompositions, etc.
v
Yes this is android 5..Ok yes we will keep looking for issues ...
👍 1
Hi @Will Shelor We were trying to implement ProfileInstaller and as u mentioned not much documentation on how to go about using it... Have u come across any experience, reference implementations or articles that would help us improve the performance of the app.. Have done most of the other things recommended here - R8, Debuggability off, Androidx Startup... So only thing left if AOT with profileinstaller. @Nipun Rajput
w
this is most of the documentation that I know of; additionally, if you want to see if it would help, use perfetto and run a trace after install; if you see the JIT compilation thread doing a lot of work, ProfileInstaller can help you. However, it sounds like you’re seeing worse performance than I’d expect, so it might be worth it to double check your logic and make sure you’re not doing anything that would result in unexpectedly bad performance.