You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on May 1, 2024. It is now read-only.
On UWP, the listviewrenderer does not dispose all the UI elements.
This is Part II of our UWP ListView memoryleak issue hunt as nobody seems to care about this platform. See here for Part I #10473
Steps to Reproduce
creating a listview with a datatemplateselector which returns ~5 different templates
Ensure, that the templates return 5 different custom viewcell types. (because then it is easier to see the leak)
add an itemssource with about 100 items, so that the listview cannot render them all at once. This will trigger recycling on UWP which is important!
Open the listview, then scroll down to the end
close the page and force GC
Expected Behavior
All viewcells should be disposed of and their "ondisappearing" should be fired.
Actual Behavior
Only the visible viewcells are disposed.
Basic Information
Version with issue: 4.8 (and I bet even MAUI)
Last known good version: none....
Platform Target Frameworks:
UWP: all
Affected Devices: UWP
Reason for the memory leak
The ListViewRenderer on UWP finds all descendant views of the UWP list and cleans them up:
However: As the UWP listview recycles views, not all the views are in the visible tree as they are cached on the sidelines. Therefore these are never disposed of!
Solution
ATTENTION: I do not claim that this is the perfect solition. If any of the Xamarin.Forms core developers has a better idea please come forward!
In UWP.CellControl.SetCell(object newContext), the newly created cells get their .Parent set to the listview.
However, they are never added to the list of ListView._logicalChildren
So we added a method AddLogicalChild() to do this. (Also, we added a method RemoveLogicalChild for cleaning up afterwards.
Then, in the ListViewRenderer.Dispose method, we explicitly iterate over all the ListViewLogicalChildren and
call SendDisappearing which is especially important for using frameworks like ReactiveUI as its bindings must be disposed
Call the VisualElementExtensions.Cleanup() method, so that all UWP platform renderers for the viewcell and all its dependents are disposed of
finally remove the cell from the logicalchildren of the listview
Description
On UWP, the listviewrenderer does not dispose all the UI elements.
This is Part II of our UWP ListView memoryleak issue hunt as nobody seems to care about this platform.
See here for Part I #10473
Steps to Reproduce
Expected Behavior
All viewcells should be disposed of and their "ondisappearing" should be fired.
Actual Behavior
Only the visible viewcells are disposed.
Basic Information
Reason for the memory leak
The ListViewRenderer on UWP finds all descendant views of the UWP list and cleans them up:
However: As the UWP listview recycles views, not all the views are in the visible tree as they are cached on the sidelines. Therefore these are never disposed of!
Solution
ATTENTION: I do not claim that this is the perfect solition. If any of the Xamarin.Forms core developers has a better idea please come forward!
In UWP.CellControl.SetCell(object newContext), the newly created cells get their
.Parent
set to the listview.However, they are never added to the list of
ListView._logicalChildren
So we added a method
AddLogicalChild()
to do this. (Also, we added a methodRemoveLogicalChild
for cleaning up afterwards.Then, in the
ListViewRenderer.Dispose
method, we explicitly iterate over all theListViewLogicalChildren
andSendDisappearing
which is especially important for using frameworks like ReactiveUI as its bindings must be disposedVisualElementExtensions.Cleanup()
method, so that all UWP platform renderers for the viewcell and all its dependents are disposed ofThis effectively fixes the issue.
You can also have a look at my PR in our Xamarin.Forms fork.
@bruzkovsky fyi!
The text was updated successfully, but these errors were encountered: