[Enhancement] Convert all default image handling in Android over to using Glidex

[PureWeen]

Description

Handling images in Android has always been problematic. We've made a number of improvements for a few use cases but overall it still isn't great.

Natively on Android google recommends using Glide for everything image related and we should do the same thing

@jonathanpeppers has already started the work over here
https://github.com/jonathanpeppers/glidex

Ideally we can take that work and pull it into the Android Platform core.
Glide can also handle animating gifs and efficiently caching all various sources of images

Implementation Details

• The latest version of @jonathanpeppers library doesn't ship with a binding library https://www.nuget.org/packages/glidex.forms/2.0.0-pre1 it just takes a dependency on https://www.nuget.org/packages/Xamarin.Android.Glide/. For this implementation we will just merge in his 2.0.0 changes and take a dependency onto https://www.nuget.org/packages/Xamarin.Android.Glide/
• Take notice of this commit jonathanpeppers/glidex@ff8886f which allows the developer to tap into the Glide library and influence the Builder. This will be a useful extension point for people
• Delete all the custom GIF code and make sure all the GIF APIs still work correctly
• Delete the current native URI Cache we have on android that's caching web images https://github.com/xamarin/Xamarin.Forms/blob/52a2581dfe4bd52f8bcabfb714c63e784735fee3/Xamarin.Forms.Platform.Android/ImageCache.cs

Considerations

• Performance impact of including the glide.jar (compile times, start times, package size)
• Test with ProGuard, MultiDex, and both enabled. see if we need ProGuard rules

Performance Analysis

@jsuarezruiz performance tests are here https://github.com/jsuarezruiz/xamarin-forms-perf-playground

ImagePerformance.zip

The result:

ImagePerformance|GridImagesView Memory, Used: 150360064 (143MB), Peak: 150622208, Lowest: 148054016, MaxConsumed: 2568192
ImagePerformance|GridImagesView Memory, Used: 343740416 (327MB), Peak: 344121344, Lowest: 147951616, MaxConsumed: 196169728

Sharing some data like these in the Spec will help to easily understand the idea and why we want this change.

NOTE: Using 400 images. Tested with OnePlus 6.

Difficulty: Low

Peppers has already done all the heavy lifting

[BillyMartin1964]

Not only pull it in, but make it a priority!

[ederbond]

Any news on this ?

[psp589]

Also interested in this!

[daniel-luberda]

@ederbond @psp589 While you're waiting for Glide support, maybe this would helpful:

You can now easily use FFImageLoading with standard views like Xamarin.Forms.Image. Just call this after Xamarin.Forms.Init call:

• CachedImageRenderer.InitImageViewHandler() on Android
• CachedImageRenderer.InitImageSourceHandler() on iOS / Mac / others

... and that's all. Also SVG files do work when providing SvgImageSource as a Source

[SagarPanwala]

so for iOS, what we need to use ?
As of now , I don't have any problem with FFImageLoading, Instead of using glide for Android only, can we not think for Android and iOS both ?

Due to curiosity, I'm asking, can we not use FFImageLoading directly for Android and iOS both for Image view in built ?

[PureWeen]

@kingces95

GlideX has a sample app here and instructions about how to init
https://github.com/jonathanpeppers/glidex

It's basically just an Init call

Android.Glide.Forms.Init (this);

That replaces our ImageHandlers for use with GlideX. If you look at the readme on that repository you'll see there are a number of tests @jonathanpeppers has done around Memory usage benefits but I'm also curious how adding the GlideX dependency influences startup performance.

Here are the viable scenarios I see to test

• how much startup overhead does just adding the GlideX nuget and the init call cause? So with a blank forms app that has no images how does the startup performance differ with and without GlideX? I think for this test we'll need to test with the GlideX nuget completely removed vs with it added to the project since the extra binaries will affect load time
• Startup performance when loading a single image with GlideX vs without GlideX?
• Startup performance when loading 5 or 10 of the same images with GlideX vs without GlideX?
• Startup performance when loading 5 or 10 different images with GlideX vs without GlideX?

With the image tests I'm curious if we will start seeing better load times with GlideX as the number of images that have to be processed increases.

[kingces95]

Sure. I'll validate the performance aspect of a private branch of main. Just cut the branch, prepare the PR, and I'll provide a profile against main. Right now I'm profiling the startup time of template apps. So what's the sartup time of zero images. It's not that the startup time of n images is not interesting, it's just that customers can always delay load images whereas there's nothing they can do about the template startup time -- that all us and only us.

That said, there's nothing stopping a customer from injecting sampling points into their app (or trying the Android profiler if/when we can get accurate statup times). Given an app, I can demonstrate how to inject the sampling points. Tho, I'm fairly sure the advice I'd give would still be to delay load the images.

like the PR will literally be as simple as just modifying the nuspec and platform to include https://www.nuget.org/packages/glidex.forms and then using his Init to replace our handlers

[jfversluis]

This will not happen anymore for Xamarin.Forms and I think we're already doing this or at least making great improvements in this area for .NET MAUI. Be sure to track the developments there :) Thanks!