Memory/GREF Leak on XForms.Android When Using Alternate Y-Axis

Question

Dear Syncfusion team,I’ve found a memory, or rather GREF leak, in the Xamarin.Forms Android implementation of the SfChart library.In my project, I am populating a Xamarin.Forms ListView with ViewCells that contain charts, keeping the list at a fixed size, but always adding/removing elements, so new charts are constantly created, while old ones should be GC’d/cleaned up. However, the platform eventually runs out of GREFs, printing "xxx outstanding GREFs. Performing a full GC!" but not cleaning up any, so that the app becomes stuck on doing full GCs.This occurs when the YAxis property of a series in the chart is explicitly specified, i.e. the series does not use the chart’s normal SecondaryAxis.I think the type of series does not matter, but for the record I have asserted the leak with both ColumnSeries and StepAreaSeries.I think the chart need not even be visible (meaning that IsVisible can be false) nor the series contain any data points for the leak to occur.If you have trouble reproducing this, please let me know and I’ll supply a full repro.As it is, I think I’ve laid out the issue pretty well so I’ll just put a snippet in here to make sure we’ll be talking about the same kind of thing: As you can see, I am defining the YAxis inline, causing the series to use something other than the chart’s SecondaryAxis. Probably it is something related to this seperate axis itself that doesn’t get completely cleaned up when/before the chart is GC’d.Cheers and thanks for your efforts already!

Michael Prabhu M · Answer

Hi Benjamin, 
Thanks for using Syncfusion products.  
The memory leak issue can be fixed by setting caching strategy in the list view. By default, the caching strategy is set as RetainElement. Hence, it was not clearing the memory from the leap. To overcome from this issue,  you can set the caching strategy as RecyleElement or RecyleElementAndDataTemplate. Please refer the following code snippet for more details. 
  
Code snippet: 
  
C#: 
  




  
var listView = new ListView(ListViewCachingStrategy.RecycleElement); 
  
XAML: 
  




  
  
<ListView CachingStrategy="RecycleElementAndDataTemplate"> 
  
  
  
Reference link : https://docs.microsoft.com/en-us/xamarin/xamarin-forms/user-interface/listview/performance#caching-strategy 
Sample : http://www.syncfusion.com/downloads/support/forum/138780/ze/ChartListView-997224851 
Please let us know, if you need further assistance on this. 
Thanks, 
Michael

Benjamin · Answer

Hi Michael,fine, this really does solve the issue in a way. (I imagined having tested it before, but apparently I hadn’t properly.)However, it is not strange that my problem only arises when using a second Y-Axis? It still seems to me as if something about this additional Y-Axis should be cleaned up, but isn’t.I’ve also produced a workaround where I set this Y-Axis in the cell.Appearing handler and unset (set to null) it in the cell.Disappearing handler. Even that gets rid of the GREF problem.So even if using a CachingStrategy gets rid of the issue in one grand sweep, I still think there is something wrong with the alternate Y-Axis.As it is, using a CachingStrategy other than the default also causes some other issues with my ListView; but I guess I can file them with the Xamarin.Forms team or write some workaround in this case, too.Cheers

Michael Prabhu M · Answer

Hi Benjamin, 
 
Thanks for the update, and yes, we agree the memory should not increase in the reported scenario, we are able to reproduce this issue and logged an issue report on this internally, the fix for this issue will be available in our Volume 3 release, which is expected to be rolled out at the end of September 2018. You can use the previous updated solution and we appreciate your patience until then.  
 
Thanks, 
Michael