search

xamarin / Xamarin.Forms

Xamarin.Forms is no longer supported. Migrate your apps to .NET MAUI.
https://aka.ms/xamarin-upgrade
Other
5.62k stars 1.87k forks source link

[UWP] Listview memory leak #3065

Open RadwanIbrahim opened 6 years ago

RadwanIbrahim commented 6 years ago

Description

using a large data set as ItmesSource of xamarin forms listview produce a memory leak in UWP and when I tried the same behavior in native uwp I didn't able to produce the issue

Steps to Reproduce

  1. add a listview with a complex view cell (nested grids, images, frame and labels)
  2. bind an observableCollection of 3000 item to it
  3. hold the scroll by the mouse and move the mouse up and down quickly
  4. check the memory allocation in windows task manager during list view scrolling or watch the visual studio diagnostic tool memory allocation

Expected Behavior

ListView should work properly in uwp

Actual Behavior

ListView produce a memory leak and performance issues in uwp

Basic Information

Reproduction Link

xamarin forms https://1drv.ms/u/s!AoIY8oQvWbhGgTFicmMFLddURVgJ uwp without xamarin https://1drv.ms/u/s!AoIY8oQvWbhGgTDaokspB4l3RVk1

also we appreciate if you could release a service release with all the listView issues that fixed in 3 and 3.1 for 2.5 as we have apps target 2.5 and we can't update to 3 because we want to support the earlier version of windows

PureWeen commented 6 years ago

If you watch CellControl on UWP while scrolling. OnDataContextChanged occasionally gets called with a NULL data context which causes the creation of a new cell. This happens more frequently if you scroll faster. That's my current working theory of this issue

RadwanIbrahim commented 6 years ago

@PureWeen I think you are right also I can produce this issue with the normal scrolling and I noticed that setting the items source to null doesn't release the memory too

nbevans commented 6 years ago

I am wondering if this is related to this issue:

We have an issue where after scrolling rapidly via the trackpad's two-finger scroll gesture the scrolling becomes defective across ALL ListView's in the app (some ViewCell based, some native ICellRenderer based) and no longer does any ListView content actually scroll. The scroll bar itself moves but it is not moving the content.

The only way to actually scroll the content is to use the scroll bar manually (by click+dragging it the old fashioned way) and forego use of the trackpad two-finger scroll. That or, restart the app to get back trackpad two-finger scrolling (at least until it breaks again).

I've seen this happen on more than one machine. And yes this is UWP only issue.

PureWeen commented 6 years ago

@nbevans that issue will most likely be resolved by this PR https://github.com/xamarin/Xamarin.Forms/pull/3060

nbevans commented 6 years ago

@PureWeen I'm on the latest 3.1.0.697729 and just saw the issue I described above occur again.

RadwanIbrahim commented 6 years ago

@PureWeen any updates on this

nbevans commented 6 years ago

Now on 3.2 pre3 and the issue that I described above has been observed at least once this week.

cknapp127 commented 6 years ago

This issue can also be reproduced with a smaller dataset using the ListView Colors Sample https://developer.xamarin.com/samples/xamarin-forms/BoxView/ListViewColors/ To reproduce download and run the UWP project. Open Task Manager. Note the memory usage. Grab the list scrollbar and scroll to the bottom and back to the top of the list 10 times. The memory usage increases by about 120 MB!!!

Maxallica commented 5 years ago

I am new to Xamarin.Forms and I noticed also this issue. I have a TabbedPage which each Page (Tab) has a ListView with many bindable data. Because of the issue my app consumes lots of memory and my device can be run out of memory.

Are there any updates on this issue?

Please can you fix this.

JunielKatarn commented 5 years ago

This issue still shows up with Xamarin.Forms 3.4

TheMaximum commented 5 years ago

We're experiencing the same issue, both with the bare listview and a datagrid that uses the same listview. The memory keeps going up when updating the ItemsSource of the listview. We're experiencing this issue on UWP, we're unsure if the same issue occurs on Android.

We've already tried to clear/null the ItemsSource before setting it again, but that does not make any difference. This keeps us from releasing our product properly, it would be much appreciated if this could be fixed soon.

Xamarin.Forms version: 3.4.0.1009999 (currently latest)

RadwanIbrahim commented 5 years ago

@PureWeen any update on this or will this be fixed by the new collection view

khoduley commented 5 years ago

Have the same issue. Multiple changing ItemSource leads to memory leaks. Screenshot_5

jefffhaynes commented 4 years ago

This is still an issue several years later and while it is possible nobody cares about UWP, UWP remains a useful way of profiling as the Xamarin Profiler is essentially useless. With widespread binding leaks, it makes it difficult to spot any actual leaks in our code.

EmilAlipiev commented 4 years ago

@jefffhaynes did you try collectionview? it is better on managing memory but there are other uwp issues though :D

gentledepp commented 4 years ago

CollectionView does not hold up to its bold promise at the moment: Even though we were told that it is a quality and performance focused rewrite of ListVIew it has the same amount of bugs - only others... One of our team is trying to get it work on iOS properly since over 1 month. We are very, very, very dissatisfied - to put it politely :-|

jefffhaynes commented 4 years ago

Yes, I wasted quite a bit of time on CollectionView. I'm actually begrudgingly using sfListView now since all the list-type views that ship with Xamarin are horribly broken. But this isn't a list bug, it's a binding bug that appears to manifest in a bindable StackLayout used inside the item template.

nchrisr commented 4 years ago

2 years and this is still not fixed? wow!

nchrisr commented 4 years ago

Are there any known work arounds? or does this mean that you cannot use a ListView on for a Xamarin.UWP application?

NuShrike commented 4 years ago

Still memory leaking horribly in Xamarin 4.8.0.1560 + UWP. Even with ListView caching set to RetainElement.

Broken frameworks released as Production is not acceptable. I'm considering abandoning my UWP Xamarin project for React Native, or just staying in native UWP.

elielson-anjos commented 3 years ago

Still seing this in Xamarin 4.8.0.1687, after a few hours of use there are huge amounts of bindings and event handlers in memory, and I can't do shit to clear them.

matthewrdev commented 3 years ago

Just wanted to weigh in here with some findings from a memory profiling session.

TLDR: Use the SyncFusion ListView on UWP to solve data template memory leaks.

Following from @jefffhaynes suggestion to use SyncFusions SfListView control, I ran two memory profiling sessions, one for the default ListView, one for SfListView and compared them.

From my findings, I've observed that the Xamarin.Forms ListView on UWP leaks the data-template contents for the ItemSource it is bound against.

The images below show the difference in instance counts between two memory snapshots for each profiling session:

Xamarin.Forms ListView image

SyncFusion SfListView image

For this test I opened a page in our app and then did multiple refreshes of the ItemSource. The Xamarin.Forms ListView retains and does not release the control instances each refresh; the total control instance count linearly increases on each refresh of the ItemSource. The SfListView, however, remains stable with a net-zero change in control instances (as expected).