Skip to content
The famous iOS Nuke native image caching library for Xamarin.Forms
C# PowerShell
Branch: master
Clone or download

Latest commit

Fetching latest commit…
Cannot retrieve the latest commit at this time.

Files

Permalink
Type Name Latest commit message Commit time
Failed to load latest commit information.
Benchmark initialize xamarin.forms.nuke repository Mar 9, 2020
Xamarin.Forms.Nuke updated nuspec and generated assembly info Mar 10, 2020
__Docs__
.gitattributes
.gitignore
AssemblyInfo.targets
Clean-BinObj.ps1
LICENSE
ReadMe.md
Xamarin.Forms.Nuke.nuspec
Xamarin.Forms.Nuke.sln
benchmark.txt
make-packages.ps1 update assembly infos and make package Mar 9, 2020

ReadMe.md

Xamarin.Forms.Nuke

Nuke image caching library for Xamarin.Forms.

Get it from NuGet:

Nuget

This repository was inspired by Jonathan Peppers GlideX implementation of the new IImageViewHandler interface for Xamarin.Forms (https://github.com/jonathanpeppers/glidex).

Its goal is to provide the same kind of implementation for iOS, achieving a complete image caching solution for Xamarin.Forms: you don't have to change any line of your existing project, the Xamarin.Forms image source handlers will just be overridden with cache-enabled ones.

Installation

Xamarin.Forms.Nuke

  1. Install https://www.nuget.org/packages/xamarin.forms.nuke/ in your xamarin forms iOS project
  2. Add this Init method after Forms.Init call:
Xamarin.Forms.Forms.Init();
Xamarin.Forms.Nuke.FormsHandler.Init(debug: false);
LoadApplication(new App());

GlideX.Forms

  1. Install https://www.nuget.org/packages/glidex.forms/ in your xamarin forms Android project
  2. Add this one liner after your app's Forms.Init call:
Xamarin.Forms.Forms.Init (this, bundle);
//This forces the custom renderers to be used
Android.Glide.Forms.Init (this);
LoadApplication (new App ());

BOOM

You just achieved 90%+ memory reduction when manipulating Image views on both platforms.

Benchmark

I changed a bit the glidex benchmark samples to have a more fair comparison. I switched from a random distribution of the images to a deterministic one to be sure we are comparing the same data set.

I used System.Diagnostics.Process.GetCurrentProcess().WorkingSet64 to have the memory workload of the process. The value given in the results are the consumed bytes between the MainPage and the complete loading of the target page.

The tests have been made on an iPhone 7 (real device, not a simulator).

For each test:

  1. Launch iPhone 7
  2. Wait 4-5 seconds on MainPage
  3. Launch a Page
  4. Scroll till the end of page
  5. Get consumed bytes in the output window
  6. Empty caches
  7. Kill app
Page Data Type Xamarin.Forms 4.5.0.356 Xamarin.Forms.Nuke 8.4.0
GridOnlyRemotePage Remote only 248 905 728 15 073 280 (-94%)
GridPage Remote and local mix 195 035 136 15 040 512 (-92%)
ViewCellPage Remote and local mix 41 418 752 20 758 528 (-50%)
ImageCellPage Remote and local mix 27 000 832 20 611 072 (-24%)
HugeImagePage Local only 128 516 096 8 634 368 (-93%)

Comparison with FFImageLoading

Before I could successfully bind the Nuke swift library, I tried to use FFImageLoading as image source handler. You can find the older repository here:

https://github.com/roubachof/Xamarin.Forms.ImageSourceHandlers

As expected the native Nuke library outperforms FFImageLoading on every test.

Page Data Type FFImageLoading 2.4.11.982 Xamarin.Forms.Nuke 8.4.0
GridOnlyRemotePage Remote only 25 722 880 15 073 280 (-41%)
GridPage Remote and local mix 24 674 304 15 040 512 (-39%)
ViewCellPage Remote and local mix 28 852 224 (1) 20 758 528 (-28%)
ImageCellPage Remote and local mix 28 868 608 (2) 20 611 072 (-28%)
HugeImagePage Local only 10 059 776 8 634 368 (-14%)
  • (1) often fails to load first images (failed 7 times on 10)
  • (2) often fails to load some images (failed 6 times on 10)

And more importantly, it loads way faster the cells images:

View Cells test

FFImageLoading Nuke

Image Cells test

FFImageLoading Nuke
You can’t perform that action at this time.