IssueTracker

r.android.com/3205674 will be the last change adding linux stubs to androidx.compose.material3.adaptive

For adaptive, follow along on https://issuetracker.google.com/issues/357731734

I have a fix for this pending that takes the "copy the snapshot id at the beginning of composition" option from above.

Nice, is this 1.2 material or beta is already branched and it's 1.3?

This should make it into 1.2 automatically. If not, i will start a cherry-pick to get it into 1.2.

So just tested with Snapshot 8544662 that contains that fix.

And the root issue is still present. The application attached earlier still crash after a few seconds. (And my main app during simple scrolls).

Can you please reopen?

Thanks,

For the record on release builds there's a huge win I can scroll a lot longer than without this so this was also related I guess.

The previous fix was necessary but not sufficient to fix this issue.

The issue demonstrated by the above is when derivedStateOf object changes what objects it reads the composition still remembers the old objects in addition to the new objects. A composition maintains a map of the objects that a dependency object reads so that, when one of those objects changes, it knows which dependency object to invalidate. If this list changes the the only the current dependencies should be retained and any previous value no longer observed should be forgotten.

I am investigating ways to ensure the inverted map is valid without causing undo additional overhead.

Small bump on this one, the app is now in prod and I start to get OOM crash reports.

Is this something that could be targeted for 1.2 or should I try to figure out a way to reduce even more the data used in those derivedstate for the moment?

Ok so the reproduction posted here is now fixed, but the main app still OOM when scrolling in large lazy list can this be reopened and moved back to lazylist?

Starting to wonder if now it's not back to be tied to https://issuetracker.google.com/issues/212982463 that is still not fixed even without anything to remember.

The heapdump looks pretty much the same see attached. Will need some hints to build the new repro.

Cases in comment#19 and comment#29 repro on 1.1.0

The best new repro I found so far is:

            var reload by remember { mutableStateOf(0) }
            LaunchedEffect(Unit) {
                while (true) {
                    reload++
                    delay(200)
                }
            }
            val items = remember {
                derivedStateOf {
                    reload
                    ShortArray(10000000) { -5 }
                }
            }
            LazyColumn {
                items(500) { item ->
                    Text("item index=$item ${items.value[0]}")
                }
            }

But now it will not crash straightaway because of the previous fix and now you have to scroll until it crashes. Note: I used ShortArray so it is easier to find it in the heap as short[]

Thanks for the repro it made me think about testing a change on my code and reverting the previous derived state indexer to avoid passing the full items list to items() and it does reduce the memory constraint (it still crash but requires more scroll).

So going back from

    val indexer by remember {
        derivedStateOf {
            List(lazyPagingItems.itemCount) { it }
        }
    }

        items(indexer) { index ->
            val item = lazyPagingItems[index]

to the normal

items(lazyPagingItems) { item ->

Does reduce the issue when before the 2 derivedstate fixes it was helping a lot.

Sorry to post here as not really related but I'm trying to update the snapshot version to a more recent version to see if your https://github.com/androidx/androidx/commit/a1ba9c954b9cc2e36bf897e4c649f52442a07a0b fix the rare https://issuetracker.google.com/issues/233929916 crash I get.

But I'm getting java.lang.NoClassDefFoundError: Failed resolution of: Landroidx/compose/foundation/lazy/LazyItemScope$DefaultImpls; errors from any libraries compiled with compose 1.2 beta 2 probably because of https://github.com/androidx/androidx/commit/f4eca2c46040cab36ebf7f34e68bdd973110e4a5 and JvmDefault.

Is there any trick to have this working or do I need to wait for the libs to update and won't be able to test possible fixes for this issue here? (I tested adding -Xjvm-default=all on my side side but no effect)

Does reduce the issue when before the 2 derivedstate fixes it was helping a lot. Yes, I would recommend you to rewrite your code without derivedstate in the meantime

see if your https://github.com/androidx/androidx/commit/a1ba9c954b9cc2e36bf897e4c649f52442a07a0b fix the rare https://issuetracker.google.com/issues/233929916 crash I get. No, I do not expect this change to fix anything for you

About your new crash I will let the responsible folks know, thanks

Yes, I would recommend you to rewrite your code without derivedstate in the meantime

Is there any performance difference between LazyVerticalGrid with 1 column and LazyColumn ?

I still use a derivedstate to manually window and implement the grid via a LazyColumn as the app allows switching between both and I need to listen to the state for other things related to first visible items.

Since LazyGrid and LazyColumn state are not equivalent and there's no common interface for the common functions it's a pain to deal with both and I'd like to stay with only one.

By derived data I meant the data to feed the LazyColumn to emulate the LazyGrid.

    val items = remember(lazyPagingItems.itemCount, stepSize) {
        derivedStateOf {
            List(lazyPagingItems.itemCount) { it }.windowed(stepSize, stepSize, true)
        }
    }

But yes I suppose the preventive derivedStateOf is not mandatory in this case.

The problem about the state being different classes, is for the fastscroll for example, or the quick return or any other visible items observing to react. The state is hoisted and used elsewhere, but this does not work if the inner component can change between both, this is the main pain point of the 2 different states, either have 2 different implementations of the observers or build another state and wrap what's needed.

Anyway this is not the place and since the LazyGrid api is no more experimental and I believe you about perf, I'll migrate all to LazyGrid to simplify my future life.

Thanks again.

https://android-review.googlesource.com/c/platform/frameworks/support/+/2118767 should resolve the DefaultImpls issue. Sorry about that!

Forget to post but yes this fix the compilation.

But since I digressed a lot, just wanted to be sure the original issue is still being investigated? I see it's already 1.3 now.

So unfortunately it's not 100% fixed, can this be reopened again?

The repro app still crash after scrolling but requires more than before. (Same for prod app)

Furthermore last snapshot completely breaks LazyX overscroll (a LazyColumn will now overscroll on left / right too when 100% unwanted see attached video).

Thanks for the report. I filed a separate bug for this issue with overscroll - b/236952034. And reopened the bug to see if there is something else we can do about the leaks

Thanks I lack time before the holidays but I hope you can go to the bottom of it. (Other bug is private I can't follow it)

Since the leak is not tied to the actual composable even leaving the screen completely won't return the memory so in the end if the user stays enough in the app it will reach OOM, and even if not seems on Pixels the memory killer don't like it at all and kill the app even with a foreground service active for low memory when going background. (And well that's a bummer to have a music player killed during playback it kinda defeat it's purpose).

Sorry, made b/236952034 public.

I tried to run the demo app again after all the recent changes and unfortunately can't reproduce what you are seeing. It is not crashing for me after scroll and I don't see anything leaking. And regardless of the leaks, I really do not recommend you writing code like this

    val items = remember(lazyPagingItems.size, stepSize, reload) {
        derivedStateOf {
            List(lazyPagingItems.size) { it }.windowed(stepSize, stepSize, true)
        }
    }

Allocating such lists only to produce list of indexes is very inefficient. You can just instead write some function which will be mapping indexes from the main data set to the new windowed one and it will require no allocations. But realistically as we already discussed you better just use LazyVerticalGrid, it is an api exactly for this use case. If after applying those recommendations you will think you still have some memory leaks feel free to file a separate bug. Thanks

The issue also occurs on normal lazylist without using those derived state.

The demo requires a lot more scroll but will trigger the issue at some point.

The GC will say 75% free then 45% free then 75% free then at some point will go down to 15% then 45% then ... Until the OOM.

This is just no more automatic and quick as previously. Scroll more up down to at least the middle to trigger it.

Again I'm not when in list mode I directly use the lazy items and it behave the same.

And even when I do I create a list of 22000 Int this is not exactly what you can call a huge list.

Anyway I'll try to build another repro when back in 2 weeks. Will link here for proper attribution.

Just tested again with one of the last snapshot from last hours and there's changes.

It's now quite hard to reproduce with the repro from here but still randomly can trigger.

But the very nice change is that removing the lazycolumn from composition does free the memory now. So on the main app the impact should be minimal instead of ineluctable. Just need the overscroll fix.

Was the video enough or need something before I leave ?

Did a quick heap dump since the memory is freed on composable removal from the screen and the data is different see attached screenshots.

Maybe this will lead some light until I can build a repro in at least 2 weeks.

One last for Adam java.lang.NoClassDefFoundError: Failed resolution of: Landroidx/compose/foundation/lazy/grid/LazyGridItemScope$DefaultImpls; Seems that one passed the 2 JvmDefaultWithCompatibility fixes.

And now sea and sun.

So for the record my leaks are now fully fixed with snapshot 8859449 (Maybe thanks to this https://github.com/androidx/androidx/commit/e82b3518094e5451dd4697f31a412c10075b28c5)

But I'm now facing another strange Compose bug that I have an hard time debugging :(

https://issuetracker.google.com/issues/239897828 would be nice if someone have an idea and could help triaging.

This issue should be reopened as it still valid in compose 1.3.0-beta01.

How to reproduce:

1 - Scroll the LazyList a bit 2 - Press the big red rectangle to remove the LazyList from the composition 3 - Press the big red rectangle again 4 - Go to 1

The memory usage will grow up endlessly.

I can't repro with my previous code and have not found a proper repro (not tested #60)

But I've pushed a beta of my app with 1.3.0 beta 1 and I've now got a return of OOM crashes, so there's definitively something back here :(

I reopen the bug. I reproduced the memory leak demonstrated by the above linked MainActivity.kt supplied by maiafranco99@gmail.com. It appears that scopes added to SnapshotStateObserver created for AndroidComposeView are not be removed when the LazyColumn is removed from composition.

This appears to be a different issue that was originally reported but will use this bug to track this as it is still a memory leak involving a LazyColumn or LazyRow and might be the issues the followers of this bug are running into instead of the original problem.

Note that a number of fixes regarding this went into 1.2 and 1.3. However, if you just update the version of androidx.compose.ui to 1.3.0-beta01 (which is what you get if you update compose_ui_version in the default Studio template to 1.3.0-beta01) you will not many of these fixes as they are part of the 1.3 runtime. Ensure you update to an explicit reference to androidx.compose.runtime:1.3.0-beta01 as 1.3.0-beta01 only requires you update to 1.2.0+ of the runtime and will not automatically update to the latest runtime.

For the record the mails are hidden to normal users you should not disclose them in case it's unwanted and to avoid spam.

I'm full B1 and no issue with alpha3 all previous issues where correctly fixed.

I proposed to Andrey to bisec between those versions is this still necessary?

Ralston is making a large change for focus that will fix this problem. He's agreed to take this on.

I had the same type of issues, where using a LazyRow and scrolling a lot would see performance degradation to the point where the app was unusable. I can say that the fixes from this bug have definitely fixed my issue, so thank you very much! However, now I'm seeing that my derivedStateOf calculations are getting called all the time.

I have a derivedStateOf which calculates layout information based off changes to the scroll state. For example:

class LayoutProvider(
    val layoutState: State<MyLayout>
)

@Composable
fun rememberLayoutProvider(): LayoutProvider {
    val layoutState = remember {
        derivedStateOf {
            // run some big calculations to calculate a layout
            calculateLayout()
        }
    }
    return remember { LayoutProvider(layoutState) }
}

And then many different composables use my derived state to create their own derivedStateOf to get their layout information. For example:

@Composable
fun SomeTile() {
    val myLayout = remember {
        derivedStateOf {
            layoutProvider.getMyLayout()
        }
    }

    do something with myLayout
}

In compose 1.2.0, this worked really well, and when the scroll state would change, the layout provider's calculation would run once, and only composables whose specific layout changed (myLayout) would get recomposed.

Now in compose 1.3.0-beta01, the calculation in the LayoutProvider gets called a large number of times, and the composoables who have their own derivedState get recomposed even when their specific layout hasn't changed.

I noticed the change to the derivedStateOf, with the addition of a policy, but I tried writing my own and still couldn't get the results I wanted. Can you please explain how I can go about getting these calculations to get called as I'd expect and only have the composables that have their derived state changed recompose?

Thank you

To give some more information, when when calling derivedStateOf(structuralEqualityPolicy()) in both those places in the code above, it still behaves incorrectly. Basically, the composable SomeTile always gets recomposed any time the scroll state changes, and only at the call site where myLayout gets used does the derivedState calculation run (i.e. layoutProvider.getMyLayout(). Seeing the whole point of derivedState is so that we can avoid recomposing composables on state changes that can happen frequently, this now feels broken to me. Please let me know if I'm missing something.

Thank you

I was able to make it even more simple:

@Composable
fun SomeComposable(
    scrollState: LazyListState
) {
    val red by remember {
        derivedStateOf(structuralEqualityPolicy()) {
            // cause an observation on the scroll state
            scrollState.firstVisibleItemScrollOffset != 0
        }
    }

    Log.e("Test", "composing SomeComposable")
    if (red) {
        Log.e("Test", "composing a red box")
        Box(modifier = Modifier.background(Color.Red).fillMaxSize())
    }
    else {
        Log.e("Test", "composing a blue box")
        Box(modifier = Modifier.background(Color.Blue).fillMaxSize())
    }
}

With this code, red should always be true except when the scroll offset is at 0, and thus the composable should only ever recompose when the scroll offset comes to zero or leaves zero. However, it recomposes on every single scroll change.

Your last example sounds normal IMO. The scrollstate change, the SomeComposable is recomposed the state is calculated, if is called and your log is ran.

To see any benefit here you need to extract the second part to another composable that is skippable.

@Composable
fun SomeComposable(
    scrollState: LazyListState
) {
    val red by remember {
        derivedStateOf(structuralEqualityPolicy()) {
            // cause an observation on the scroll state
            scrollState.firstVisibleItemScrollOffset != 0
        }
    }

    Log.e("Test", "composing SomeComposable")
    SomeComposable2(red)
}

@Composable
fun SomeComposable2(
    red: Boolean
) {
    if (red) {
        Log.e("Test", "composing a red box")
        Box(modifier = Modifier.background(Color.Red).fillMaxSize())
    }
    else {
        Log.e("Test", "composing a blue box")
        Box(modifier = Modifier.background(Color.Blue).fillMaxSize())
    }
}

This will display the first composing log each time the scrollstate change, but the box composing will only happen when the derived state change as the SomeComposable2 is skippable.

Thanks for the response, but unfortunately, that still isn't correct IMO. I understand the concept of using a composable that is skippable, but what that would accomplish is that when red changes, SomeComposable would not recompose, while SomeComposable2 would. That is not what I'm trying to accomplish. The issue here is that red is not supposed to change unless the scrollable state crosses the zero boundary. So in your example, SomeComposable2 still recomposes every single time the scroll state changes, but it shouldn't.

The issue is that the red state only gets evaluated/calculated when it is accessed, which is in the recomposition, but at this point, it's too late, as the composable is already recomposing. So DerivedState is no longer useful. In Compose 1.2.0, the red calculation would run at the time that the scroll state changes outside the composition scope, and then would appropriately cause the composable to recompose only if the red state actually changed.

No in my example SomeComposable2 does not recompose because it's skippable and red state does not change.

SomeComposable will always recompose because the scrollstate change. It's up to you that your composable is made of skippable sub component so that they are not recomposed.

In the case of #68 the if is not a composable function so is not skippable. So if SomeComposable is recomposed the if will always be ran and so your log will run. If you had something different before then it was something else and not how compose is supposed to work.

In all case in my example the red state is read as it's a parameter to SomeComposable2 so it's up to date thanks to the derivedstate and so will properly change.

I use this pattern a lot in prod and it works like that since 1.0 and it still works the same in 1.3 alpha3 (and beta 1 but I'm not in prod with it due to the return of the mem leak).

In all cases your issue seems unrelated to this one so you might want to open another one if you want more traction from Google.

Here is sample code that describes exactly the issue:

class MainActivity : ComponentActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContent {
            // A surface container using the 'background' color from the theme
            Surface(
                modifier = Modifier.fillMaxSize(),
                color = MaterialTheme.colors.background
            ) {
                OuterComposable()
            }
        }
    }
}

@Suppress("EqualsOrHashCode")
class ZeroMap(
    val zeroMap: Map<Int, Boolean>
) {
    override fun equals(other: Any?): Boolean {
        if (this === other) {
            Log.e("StateTest", "ZeroMap is the same reference")
            return true
        }
        if (javaClass != other?.javaClass) {
            Log.e("StateTest", "ZeroMap is not the same because of javaClass")
            return false
        }

        other as ZeroMap

        if (zeroMap.size != other.zeroMap.size) {
            Log.e("StateTest", "ZeroMap is not the same because trackLayouts.size (${zeroMap.size}) != other.trackLayouts.size (${other.zeroMap.size})")
            return false
        }

        val otherEntries = other.zeroMap.entries
        zeroMap.entries.forEachIndexed { index, entry ->
            val otherEntry = otherEntries.elementAt(index)
            if (entry.value != otherEntry.value) {
                Log.e("StateTest", "ZeroMap is not the same because entry.value (${entry.value}) != otherEntry.value (${otherEntry.value}) for index $index")
                return false
            }
        }

        Log.e("StateTest", "ZeroMap is the same value")
        return true
    }
}

class ZeroStateProvider(
    val scrollState: LazyListState,
    private val zeroState: State<ZeroMap>
) {
    fun isAtZero(index: Int) = zeroState.value.zeroMap[index]
}

@Composable
fun rememberZeroStateProvider(): ZeroStateProvider {
    val scrollState = rememberLazyListState()
    val zeroState = remember {
        derivedStateOf(structuralEqualityPolicy()) {
            Log.e("StateTest", "calculating zero state for scroll offset: ${scrollState.firstVisibleItemScrollOffset}")
            val zeroMap = mutableMapOf<Int, Boolean>()
            scrollState.layoutInfo.visibleItemsInfo.forEach {
                zeroMap[it.index] = it.offset == 0
            }
            ZeroMap(zeroMap)
        }
    }
    return remember {
        ZeroStateProvider(scrollState, zeroState)
    }
}

@Composable
fun OuterComposable(
    modifier: Modifier = Modifier,
) {
    Log.e("StateTest", "Composing OuterComposable")
    val zeroStateProvider = rememberZeroStateProvider()
    LazyRow(
        state = zeroStateProvider.scrollState,
        horizontalArrangement = Arrangement.spacedBy(60.dp),
        verticalAlignment = Alignment.Top,
        modifier = modifier
            .fillMaxWidth()
    ) {
        items(
            count = 100,
        ) { index ->
            InnerComposable(index, zeroStateProvider)
        }
    }
}

@Composable
private fun InnerComposable(
    index: Int,
    zeroStateProvider: ZeroStateProvider,
    modifier: Modifier = Modifier
) {
    Log.e("StateTest", "Composing InnerComposable (index=$index)")
    val color by remember {
        derivedStateOf(structuralEqualityPolicy()) {
            Log.e("StateTest", "InnerComposable: calculating color")
            when (zeroStateProvider.isAtZero(index)) {
                true -> Color.Red
                false,
                null -> Color.Blue
            }
        }
    }

    Box(
        modifier = modifier
            .background(color)
            .size(200.dp)
    )
}

The output in Compose 1.2.0 gives:

E/StateTest: InnerComposable: calculating color
E/StateTest: calculating zero state for scroll offset: 1
E/StateTest: Composing InnerComposable (index=0)
E/StateTest: InnerComposable: calculating color
E/StateTest: InnerComposable: calculating color
E/StateTest: InnerComposable: calculating color
E/StateTest: Composing InnerComposable (index=4)
E/StateTest: InnerComposable: calculating color
E/StateTest: InnerComposable: calculating color
E/StateTest: calculating zero state for scroll offset: 3
E/StateTest: InnerComposable: calculating color
E/StateTest: InnerComposable: calculating color
E/StateTest: InnerComposable: calculating color
E/StateTest: InnerComposable: calculating color
E/StateTest: InnerComposable: calculating color
E/StateTest: calculating zero state for scroll offset: 5
E/StateTest: InnerComposable: calculating color
E/StateTest: InnerComposable: calculating color
E/StateTest: InnerComposable: calculating color
E/StateTest: InnerComposable: calculating color
E/StateTest: InnerComposable: calculating color
E/StateTest: calculating zero state for scroll offset: 6
E/StateTest: InnerComposable: calculating color
E/StateTest: InnerComposable: calculating color
E/StateTest: InnerComposable: calculating color
E/StateTest: InnerComposable: calculating color

and in Compose 1.3.0-beta01 gives:

E/StateTest: calculating zero state for scroll offset: 2
E/StateTest: ZeroMap is not the same because entry.value (false) != otherEntry.value (true) for index 0
E/StateTest: InnerComposable: calculating color
E/StateTest: calculating zero state for scroll offset: 2
E/StateTest: ZeroMap is not the same because entry.value (false) != otherEntry.value (true) for index 0
E/StateTest: Composing InnerComposable (index=0)
E/StateTest: calculating zero state for scroll offset: 2
E/StateTest: ZeroMap is not the same because entry.value (false) != otherEntry.value (true) for index 0
E/StateTest: InnerComposable: calculating color
E/StateTest: calculating zero state for scroll offset: 2
E/StateTest: ZeroMap is not the same because entry.value (false) != otherEntry.value (true) for index 0
E/StateTest: calculating zero state for scroll offset: 2
E/StateTest: ZeroMap is not the same because entry.value (false) != otherEntry.value (true) for index 0
E/StateTest: InnerComposable: calculating color
E/StateTest: InnerComposable: calculating color
E/StateTest: InnerComposable: calculating color
E/StateTest: InnerComposable: calculating color
E/StateTest: InnerComposable: calculating color
E/StateTest: calculating zero state for scroll offset: 4
E/StateTest: ZeroMap is the same value
E/StateTest: calculating zero state for scroll offset: 5
E/StateTest: ZeroMap is the same value

As you can see from this output, in Compose 1.2.0, calculating zero state for scroll offset only appears once every time the scroll state changes, and then the inner compositions recalculate accordingly. But in Compose 1.3.0-beta01, calculating zero state for scroll offset shows up many times every time the scroll state changes. The number of times it runs increases with the number of composables that use its state.

From the documentation of derivedStateOf, it says "The result of calculation will be cached in such a way that calling [State.value] repeatedly will not cause[calculation] to be executed multiple times". This was true prior to Compose 1.3.0-beta01, but no longer is.

Please let me know what you think. Thanks!

As said I'm not a Googler and your issue is unrelated to the original issue. You really should open another issue.

I'd say that your issue might not be related to derivedstate at all but to the compiler generation of your ZeroStateProvider class.

I'd use https://chris.banes.dev/composable-metrics/ to check if the ZeroStateProvider is seen as stable or not and if that change when you change the compose compiler. (And the impact about other composable stability / skippabe)

Yes, I'm ok with creating a new issue (which I did here: https://issuetracker.google.com/issues/244621257), but I'm sure this is a result of the changes made for this bug.

You can easily bisect the version that introduced the issue. All the fixes for this issue are in 1.2.0. AFAIR the only missing to fix all was https://github.com/androidx/androidx/commit/e82b3518094e5451dd4697f31a412c10075b28c5 but it was not opened and followed due to this issue but for https://issuetracker.google.com/issues/239603305 (But similar result)

Try 1.3 alpha 3 that I use in prod with no performance regression. Then alpha 2 then 1 ;)

It was introduced by https://github.com/androidx/androidx/commit/8bac18a341805fa63ce9190ea7a0206f052e17ee, which went into alpha02. That commit doesn't reference any tracker, nor can I find a PR for it, so not sure how to track it other than that.

Small bump on this to follow from #65

Is this planned to be backported to 1.3?

With Material 3 pinned to 1.3 we can't keep 1.3 A3 and update material. And not sure they will start an 1.1 alpha pinned to 1.4 before a final 1.3 release. (Maybe you have some info about that)

So 1.3 RC1 is cut, is it possible to have some insight on this please? On my app with tons of large lazylist this leads to very fast OOM (even faster than previous issues).

Not having a solution for 1.3 may have high impact on updating M3 / Glance and the sooner we know the easier to anticipate.

1.3-rc01 hasn't been cut yet, though the commit to bump the version to rc is in the system to ready for that build cut

So tested snapshot 9082024 that include this and it seems to be fixed.

And I also see nice scrolling performance on large lists, maybe due to other commits.

The last question is. Are there any commits in 9082024 that won't be part of the final 1.3? Or can I expect the same performance gain in the coming 1.3 releases ?

This bug was linked in a change in the following release(s):

• androidx.compose.ui:ui:1.3.0-rc01

The following release(s) address this bug:

• androidx.compose.runtime:runtime:1.3.0