I’m still having issues with LazyColumn and Exopla...

# compose

[Fanilog]

I’m still having issues with LazyColumn and Exoplayer with Compose 1.0. The scrolling is very slow.

I’ve tried to use only one exoplayer instance vs one for each item but he didn’t change the experience.

I’ve 3 questions:
• Is it a known issue with compose and exoplayer ?
• Is there any best practices for this use case?
• Should I revert using recylerview ?

[allan.conda]

🤔 maybe you’re recreating your Exoplayer View everytime?

[Namig Tahmazli]

Same here. The basic list with just Text as an item. The scroll starts lagging initially but while you scroll it becomes smoother. 🤷🏻‍♂️

[Colton Idle]

@Fanilog file a bug if you can make a minimal reproducible project. They've said that they are taking perf issues filed with repros very seriously so I hope that they can fix your issue soon!

[Fanilog]

So I’ve tried two approaches:

The first one was to create an exoplayer for each item in the list but it’s adding a lot of instances. I don’t know if it’s affecting the scroll.

The second approach was to create only one exoplayer and updating the url video while scrolling but he didn’t improve the scroll

in both case I’m creating the exoplayer in a remember method

val player = remember { exoplayerProvider.exoPlayerBuilder(withLoadControl = false).build() }

[Fanilog]

@Colton Idle Good idea I’m going to do this. He might help other people

[Fanilog]

@Namig Tahmazli Are you using multiple instances or 1 instance of exoplayer ?

[Namig Tahmazli]

In my case it is just a simple lazy column with text as a list item. No other views. What I am saying is LazyColumn lagging on initial scroll compared to RecyclerView. It becomes more laggy with a list item with some images and rows in it.

[Fanilog]

Yeah I’ve noticed the same as soon as I’m adding images in my items

[allan.conda]

Have you benchmarked in a release build? debug is way slower

[Namig Tahmazli]

Hmm interesting. Have not thought of it.

[Fanilog]

Release mode is way better (day and night) but still, on older devices (Samsung s9, android 10) the scroll feels like some frame are dropped.

However on my personal device (OnePlus 8T), it’s fine

[allan.conda]

You should always benchmark the performance from release build. Debug is not representative of real performance, though it can show obvious performance issues like expensive operations in main thread.

[Fanilog]

ok noted

[allan.conda]

I see… S9 is considered old and it’s slow with that? That’s flagship 😬, I would be worried if it’s lagging like you said

[allan.conda]

Just fyi I also have ExoPlayers in an infinite list, but I use Accompanist pager instead of LazyColumn, but both are lazily loaded. It seems fast enough for me though.

[Fanilog]

ok didn’t try with Accompanist pager but it might be something on my side

[allan.conda]

Are you properly releasing your player?

[allan.conda]

val player = remember {
    SimpleExoPlayer.Builder(context).build()
}
DisposableEffect(player) {
    onDispose {
        player.release()
    }
}

I do this

[allan.conda]

And make sure the AndroidView is initialized inside factory lambda, the `update`lambda may be called again in every recomposition

[Fanilog]

Hum not sure I understand the code but it might be this.

The player is remembered to avoid recreation during recomposition and I understand that the onDispose is triggered if player change. But in which condition the val player could change?

[Andrey Kulikov]

Hello! Feel free to add your code sample into this bug so we can explore if there are any optimizations possible: https://issuetracker.google.com/issues/190920985

[allan.conda]

@Fanilog the player is unique per item, so it’s disposed when the lazy instance is replaced with a different item. You can confirm if onDispose block is called when you scroll, or check your memory consumption, I might be wrong.