Scrolling performance degradation of CollectionView on Android in .NET 8. What can WE do about it? What can MAUI TEAM do about it?

[Hooterr]

The problem: CollectionView seems to be really struggling on Android, especially when you scroll through the items quickly.
Look at the example below. The item template is pretty simple and a very typical setup.

<DataTemplate x:DataType="x:Int32">
    <SwipeView>
        <SwipeView.RightItems>
            <SwipeItems>
                <SwipeItem Text="Action3" BackgroundColor="Pink"/>
            </SwipeItems>
        </SwipeView.RightItems>
        <SwipeView.LeftItems>
            <SwipeItems>
                <SwipeItem BackgroundColor="Yellow" Text="Action1"/>
                <SwipeItem BackgroundColor="PaleVioletRed" Text="Action2"/>
            </SwipeItems>
        </SwipeView.LeftItems>
        <Grid ColumnDefinitions="*,*,*"
                BackgroundColor="White"
                ColumnSpacing="10"
                RowDefinitions="40"
                Padding="0,5">
            <Label VerticalTextAlignment="Center" Grid.Column="0" BackgroundColor="Red" Text="{Binding}"/>
            <Path Grid.Column="0" TranslationX="50" Data="M 0,10 L 10,10 L 5,0Z" Fill="White" VerticalOptions="Center"/>
            <Button Grid.Column="1" BackgroundColor="green" Text="{Binding}" Padding="0"/>
            <Entry Grid.Column="2" BackgroundColor="blue" TextColor="white" Text="{Binding}"/>
        </Grid>
    </SwipeView>
</DataTemplate>

It's just a grid with 3 columns, with a Label, a Button, a Path, and an Entry. All of these are enclosed in a SwipeView. But even with this simple layout, we hit a performance bottleneck pretty quickly. Which is really bad because the real world apps that I had worked on require way more complex layouts than that.

Here is what scrolling through such a collection view looks like on a Xiaomi Note 8T (android 10). It's not a new phone by any means, but it's modern-enough to not have hiccoughs with such simple tasks. I use it daily and it's been working well enough for years that I haven't even considered replacing it yet.

Screenrecorder-2023-10-14-15-05-14-655.mp4

Try the fling gesture to scroll through the items and you pretty much get a slideshow. Even trying to go through the list without lifting your finger gives you some small stutters.

What I'm trying to figure out is what is at fault here and how can we as developers work around it or what can the .NET MAUI team do about it and the timeline of it.

I recorded a trace of what was happening during scrolling. I'm not an expert in analyzing this kind of stuff but it obviously doesn't look good.

If I'm not mistaken there's nothing that I do outrageously wrong in my layout nor are the binding slowing everything down (there's a total of 3 bindings in the example without any converters or anything).

In this example, the OnBindViewHolder calls take a relatively small amount of time but it scales very aggressively with the amount of bindings and complexity of the layout. With a layout with 3 rows, 3 columns, 8-10 labels, 1 image, and 4 paths it took 250ms. This means if you scroll by 4 items at once you'll get a 1s lag.

I obviously understand that with using MAUI comes a performance hit but as developers we can't be expected hit such an issue soooo early. I mean, if you use something hard enough you'll eventually break it but this is nowhere near a heavy or unusual use case.

Here is the project and scope file: https://github.com/Hooterr/AndroidCollectionViewPerformance

Potential solution: GO NATIVE

After digging for hours through recorded scopes and trying to optimize the layout of item templates I found out that the only solution was to write the layout natively. I translated the real-world-complex from XAML to android XML. I setup the RecyclerView to use my layout and bind my collection of items through the adapter. I even used all the value converters that I used in XAML to set texts and colors inside OnBindViewHolder as well as the same IFontManager as MAUI to load fonts. Then made a barebones handler to render my native recycler view inside my XAML page. The effect was absolutely astonishing. There was nothing I could do to make that list lag or stutter in any way. Even in Debug mode, when the MAUI CollectionView was almost unusable, the native one was just flying.

It seems that .NET<->Java interop is not to blame here. You wouldn't be able to tell if this sample list was written directly in Java or Xamarin.Android. What it looks like to me is that the underlaying architecture of MAUI just does so much work underneath that it's just unfeasible to make anything more complex than a list of simple labels.

At this point, what I would recommend to everyone is, if you're having performance issues with CollectionView, just write your layouts natively. It's a shame because you have to do it twice but there seems to be no other choice.

[akhanalcs]

Can you convert it into an issue than discussion? This is something MAUI team should work on.

[Hooterr]

I will do that later. This is mainly to ask the community if they also feel the same way and if they have found any way to work around this issue if that's even possible from the developers' side. So far the only real solution for me was to write this part natively.

[mjsb212]

Many many people are looking to solve this problem!! If you google 'MAUI CollectionView performance issues' you will see all of the frustration from the community. I've been trying to solve the CV issues for several months. There are many issues open and backlogged regarding the terrible Scrolling and Performance with Android CollectionView... If you have a repo with a native implementation workaround that you could share as a template to test, and build off of, many devs would be very happy!!

[jonmdev]

If you really want to solve it, write your own design completely. Perhaps this is not for everyone, but what do you need for a "collection view"?

1. Virtualized data (eg. a List of your custom type of DataEntry)
2. A class/object that can update based on any given DataEntry of this type.
3. A way for each DataEntry to measure its own expected height.
4. A group of the visualization objects from point 2 to recycle as you scroll.
5. A method for scrolling/click dragging.
6. A function that after x amount of scrolling, calculates which expected virtualized data points will be expected within view and updates the pool of available visible elements to display what you need to see accordingly.

EDIT: On further assessment, my custom "collection view" is showing the same problems. Doing this won't fix it. This is likely a deeper Maui problem as noted here

[Hooterr]

That's an interesting idea. A fully managed CollectionView.
How would you go about implementing scrolling? Simply changing TranslationY of elements? I wonder how performant that would be. Native platforms for sure utilize some GPU capabilities for scrolling but an interesting idea nonetheless.

[jonmdev]

Yes, in MAUI you would simply translate the objects in the X or Y as needed while children of an Absolute Layout. You can use another Absolute Layout as a "scroll window" that you use to check boundaries against. I have done this many times and it is not an impossible task.

The first one took me a lot of hours but that's because I hadn't thought it out and didn't know what I was going to do.

It gives you total control over the behavior and you don't have to worry about anything "breaking" after that later. It is also quicker to port to a new system if you need to later.

[AlleSchonWeg]

There are some other CV.
Sharpnado: https://github.com/roubachof/Sharpnado.CollectionView
DevExpress: https://docs.devexpress.com/MAUI/403324/collection-view/index

I use the Sharpnado CV. But still with Xamarin Forms. Perhaps scrolling works better with one of this.

[sjordanGSS]

I have also run into this problem with CollectionView, my solution was also to avoid writing complex datatemplates and to use more native android controls usually based around ConstraintLayout. I didn't get the chance to profile my layouts but performance was massively improved with this change.

[davidortinau]

Please test the nightly builds. https://github.com/dotnet/maui/wiki/Nightly-Builds

The upcoming service release 4 has some performance fixes, including targeting Android CollectionView.

[jonmdev]

@davidortinau please see this issue report: #21580

The creator claims to be using the nightly build as of the past 24 hours. He has provided evidence this was not a problem in Xamarin but is certainly still a problem in Maui.

I have reproduced the same stuttering problems as described there even with my own simple simulations of "CollectionView" type functions using nothing more than AbsoluteLayout, Border, Image, and Label. I linked to one such simple demo project there.

Given I can't get smooth behavior even with simple custom "CollectionView" type simulations, I suspect this is a deeper problem with how Maui is excessively invalidating or forcing native view redraws, causing this lag on any updates.

[maonaoda]

Thanks for your efforts, I can clearly feel the performance improvement of Android`s CollectionView.

[AdamEssenmacher]

Have you tried setting the nursery size to something reasonable? The default in Xamarin was something like 512KB, which is wayyyy too small. Not sure if it's been changed in MAUI. 64-128M seems to be a better spot currently.

https://stackoverflow.com/questions/72799143/how-do-i-specify-nursery-size-for-android-in-net-maui-app
https://learn.microsoft.com/en-us/xamarin/android/internals/garbage-collection

I'd recommend starting it at 1m and, if it makes a difference, increasing it by a factor of 2 (it has to be a factor of 2...) until the ROI isn't worth it for your app.

[sereoja]

use native controls, see this Android solution, works for me:
https://github.com/Kanat9494/TestMAUI.git