https://kotlinlang.org logo
Channels
Powered by
m

manueldidonna

06/12/2020, 2:15 PM
I've a doubt on the diff alghoritm used by compose with 
AdapterList
. The composable receives a read-only 
List
, each item has a proper equals method. If an item must change, the composable is invoked with a new list.
Copy code
var items by state { emptyList<Item>() }

AdapterList(items) { item -> 
    ItemUI(item, onClick = { items = /** new read-only List with only one item changed**/ }) 
}
Should I replace the 
MutableState
with a 
ModelList
?
z

Zach Klippenstein (he/him) [MOD]

06/12/2020, 2:21 PM
What is your doubt? 
AdapterList
should support regular immutable `List`s just fine.
m

manueldidonna

06/12/2020, 2:30 PM
I had bad performance on scrolling. The UI is very simple. I thought it was a problem with the immutable list. So it's not an AdapterList fault. If needed I can share the code in the next hours. Maybe it's useful to understand how I got these horrible performance
z

Zach Klippenstein (he/him) [MOD]

06/12/2020, 2:35 PM
Looking at the source code, 
AdapterList
doesn’t actually do any diffing. When you pass a new 
data
list in, it looks at the indices of the data items that are currently on screen and re-invokes your 
itemCallback
for whatever data happens to be at those indices at that point in time. So in terms of time complexity, every update to the data is recomposed in roughly constant time relative to the number of items that can be on the screen at one time, it doesn’t matter how large your list is. So you’re right it’s probably not an 
AdapterList
issue. But it would be good to attach the profiler and look at what methods are actually taking so long. https://cs.android.com/androidx/platform/frameworks/support/+/androidx-master-dev:ui/ui-foundation/src/main/java/androidx/ui/foundation/AdapterList.kt;l=80?q=adapterlist&amp;ss=androidx%2Fplatform%2Fframeworks%2Fsupport
Scrolling doesn’t mutate the list though, does it? So the type of the list shouldn’t matter. If the individual item composables are expensive, that seems like the most likely candidate for this, although again it’s simple to attach the profiler in Android Studio and see what’s actually going on.
m

manueldidonna

06/12/2020, 2:39 PM
I will update this thread asap with the profiler data. Thanks Zach!
Using the profiler I get that the problem is not related to the data passed to the composable. The majority of the calls is to the measure method of the layouts with a lot of InfPxSize, Constraints, etc.. instances allocated. This was one of my first times with the profiler tool, I'll investigate further in the next days to understand the cause of the problem
z

Zach Klippenstein (he/him) [MOD]

06/13/2020, 1:15 AM
I think there was a pretty big optimization pass over the layout/measurement code that landed recently, but idk if it shipped yet. Might help with some of that stuff.
m

manueldidonna

06/13/2020, 1:18 AM
Do you remember which was the commit? I would see it
In the past 2 weeks I've seen a lot of commits on the optimizations of the layout. But It's strange that I am the only one who complained of such low performances
c

caelum19

08/01/2020, 7:41 PM
Did you ever find what could be causing the lag? Getting some lag with my scrolling too
2 Views
Powered by