Support Skiko SVG rendering on Android

[colinrtwhite]

Is your feature request related to a problem? Please describe.
Our default Android SVG renderer, androidsvg, is a common pain point with coil-svg as it's more prone to rendering issues compared to our non-Android SVG renderer, Skiko. We use androidsvg as it's completely written in Java with no native libraries so it's impact on binary size is very small. Skiko, on the other hand, uses native libraries that increase the binary size by megabytes. That said, we should figure out a better story for users who need to fix the rendering issues introduced by androidsvg without writing our own custom SVG parser (a giant undertaking).

Describe the solution you'd like
Coil 3.3.0 exposes a new Svg.Parser interface. Given we already support Skiko and androidsvg implementations of this interface, I propose we separate out our Skiko SVG renderer into a new module so folks who want to use it and don't care about the increased binary size can do something like this to use Skiko instead of androidsvg on Android:

val ImageLoader.Builder(context)
    .components {
        // Skiko is just a Kotlin wrapper for Skia.
        add(SvgDecoder.Factory(parser = SkiaSvg.Parser())
    }
    .build()

Additional context
This may or may not actually work given I'm not sure how well Skiko supports Android and Compose Multiplatform (and Coil) only uses Skiko on non-Android platforms. Also Skiko uses a different set of bitmap classes that we'll have to translate to Android bitmaps. There's also no timeline to release this. Also if someone wants to take a shot at this, PR welcome!

[Irineu333]

Does Skiko manage to render SVG on Android? I thought it couldn't due to the lack of support in compose resources.

[colinrtwhite]

@Irineu333 I'm not sure either 😬. I only saw this, which made me think it might be doable.

[colinrtwhite]

Took a run at this and I think we're blocked by Skiko. I'm running into the same exception Skiko's Android sample app is crashing with:

Caused by: java.lang.UnsatisfiedLinkError: dlopen failed: cannot locate symbol "__aarch64_ldadd4_relax" referenced by "/data/app/~~W9Is_uPeRW9rl5oBE-7iEg==/sample.compose-WMe-omYHl4rWR7XpsLvfrQ==/base.apk!/lib/arm64-v8a/libskiko-android-arm64.so"...
	at java.lang.Runtime.loadLibrary0(Runtime.java:1090)
	at java.lang.Runtime.loadLibrary0(Runtime.java:1012)
	at java.lang.System.loadLibrary(System.java:1765)
	at org.jetbrains.skiko.Library.findAndLoad(Library.kt:75)
	at org.jetbrains.skiko.Library.load(Library.kt:56)
	at org.jetbrains.skia.impl.Library$Companion.staticLoad(Library.jvm.kt:12)
	at org.jetbrains.skia.svg.SVGDOM.<clinit>(SVGDOM.kt:21)
	... 36 more

Posted my prototype in the colin/skiko_svg_android branch: https://github.com/coil-kt/coil/tree/colin/skiko_svg_android

Also it looks like Skiko adds ~10MB of download size and ~28MB of uncompressed size on disk. Not ideal, but I still think it's the best library for resolving our rendering issues. Every other SVG rendering library is going to add a similar amount as they're all using native libraries.

[petrichor]

Also it looks like Skiko adds ~10MB of download size and ~28MB of uncompressed size on disk. Not ideal, but I still think it's the best library for resolving our rendering issues. Every other SVG rendering library is going to add a similar amount as they're all using native libraries.

Have you considered using resvg?
According to its README, it would only add less than 3 MB, and it has excellent SVG feature support.
I’ve found a Flutter wrapperr for it, which seems to be mostly some FFI bindings, but I’m not sure whether integrating resvg into Coil would be difficult.