Hi Syncfusion,
The PDF viewer control for Xamarin Forms has a serious memory leak issue on UWP. (On iOS it does seem to work fine for the time being)
Please find the attached two screenshots I've made from profiling one of my apps with Visual Studio 2017.
I am using version 15.3451.0.26 of the PDF viewer.
In my app I have a list of PDF files to open, the largest one being 7 megabytes, the smallest 25 kilobytes, each having on average one picture in them.
Clicking a button on the app will open the file on a separate page, which is defined as follows:
<ContentPage xmlns="http://xamarin.com/schemas/2014/forms"
xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml"
xmlns:mvvm="clr-namespace:Prism.Mvvm;assembly=Prism.Forms"
xmlns:xForms="clr-namespace:Syncfusion.SfPdfViewer.XForms;assembly=Syncfusion.SfPdfViewer.XForms"
x:Class="Gbk.Client.UI.Xamarin.Views.SpecSheetPage"
mvvm:ViewModelLocator.AutowireViewModel="True" BackgroundColor="{StaticResource NavColor}">
<AbsoluteLayout BackgroundColor="White">
<AbsoluteLayout.Margin>
<OnPlatform x:TypeArguments="Thickness">
<On Platform="iOS">0,20,0,0</On> <On Platform="Windows,Android">0</On>
</OnPlatform>
</AbsoluteLayout.Margin>
<xForms:SfPdfViewer InputFileStream="{Binding Source}" AbsoluteLayout.LayoutBounds="0,50,1,1" AbsoluteLayout.LayoutFlags="HeightProportional,WidthProportional" />
</AbsoluteLayout>
</ContentPage>
As you can see, there is nothing strange on the page, it's just a simple ContentPage with one AbsoluteLayout having the PdfViewer inside it.
I have attached the profiler to the app session, then started the app, and on about the 30 second mark I opened the first PDF, then I hit the hardware back button to take me back to the list page, around 1 minute opened a second one, then hit back and then around 1:30 a third one. As you can see the memory consumption of the app grew steadily.
I am able to crash my app consistently just by opening and closing files in a row in the aforementioned fashion - I can easily get to several gigabytes of RAM usage.
As you can see on the other screenshot, the application is keeping alive several instances of MemoryStreams, and several SyncFusion PDF objects even after navigating away from the page.
The stream is closed and disposed of when going back in the view's code behind manually, but it does not seem to affect the performance.
Can you please take a look into this matter? We can not publish this app with a broken PDF viewer component such as this.
Attachment:
Documents_c7b9413a.zip