Asset images are loaded asynchronously on Android

[dfabulich]

skip-ui/Sources/SkipUI/SkipUI/Components/Image.swift

Line 155 in 6e2e63e

SubcomposeAsyncImage(model: model, contentDescription: nil, loading: { _ in

All asset images are being loaded with coil3.compose.SubcomposeAsyncImage.

As a result, when you navigate to the Image playground in the showcase, on Android, you see a layout shift as the asset images pop in, but on iOS, there isn't.

Ordinarily when using AsyncImage I'd use its placeholder: argument to prevent layout shift, but this is just a simple Image, so there's no way to use a placeholder.

Ideally, asset images should loaded synchronously by default. If not that, then there should be some way to load asset images synchronously. If not that, then there should at least be a way to provide a placeholder for asynchronously loaded asset images, and this should be documented.

[dfabulich]

Screen recording of layout shift on Android.

Screen_recording_20250318_202150.webm

[marcprux]

Agreed that this is a very annoying visual glitch, and inconsistent with the behavior of SwiftUI. AFAIK, there isn't any way to convince coil to behave in a synchronous way, but I would love to be wrong about this.

[marcprux]

Perhaps it could be done using the ImageLoader.executeBlocking call mentioned at https://github.com/coil-kt/coil/blob/main/docs/java_compatibility.md, or by calling ImageRequest.Builder.dispatcher(Dispatchers.Main.immediate) as mentioned at coil-kt/coil#2138 (comment)

[dfabulich]

I've never heard of anyone using Coil for bundled asset images. All the documentation I've seen just says to use a painterResource(id = R.drawable.my_asset_name) in your Image/Icon components.

Does SkipUI's Image component have to use Coil for this?

[marcprux]

All our image formats and loading behavior are based on Coil (see Image.swift). In theory there could be a parallel path that uses a different mechanism, but we would need to re-implement a lot of it. Furthermore, we don't use R.drawable.image_name, since that doesn't work well with our handling of named images (which we need in order to have parity with SwiftUI/UIKit's image loading APIs).

I think a much more expedient solution would be to try to coerce Coil to behave synchronously in certain cases (like when loading a resource whose URL is "asset:/path/to/asset.png").

[marcprux]

I'll share some of the (inconclusive) thoughts I've had on this issue. The problem comes down to the fact that Coil is an intrinsically asynchronous library. Coil can't be easily replaced, because our AsyncImage is mostly just a wrapper around their SubcomposeAsyncImage, which does a lot. Plus, we take advantage of their plugin architecture to provide support for SVG and PDF images, which are not handled by default.

We might consider adding support for Glide (the other very popular image loading library, which is more mature and is recommended by the Android docs for loading bitmap images). One problem is that we'd need to re-implement all of our special-case handling of PDF and SVG images. Another issue is that we would be adding the sizable (686 KB) Glide library to every apk that uses SkipUI.

It might be worth coming up with a quick proof of concept to see whether we can easily get Glide to handle our synchronous image needs, and then assess the level of effort we would need to get it to handle all the formats we support.

[marcprux]

Another option we might consider if we are adding a new image library is Sketch (https://github.com/panpf/sketch), which supports SVG (but not PDF).

[aabewhite]

I worry that any attempt to load synchronously will be too slow on Android. Another option would be to use Android's APIs for getting an image's dimensions:

BitmapFactory.Options options = new BitmapFactory.Options();
options.inJustDecodeBounds = true;
BitmapFactory.decodeFile(yourImageFilePath, options);
int imageWidth = options.outWidth;
int imageHeight = options.outHeight;

We could avoid the layout jank while still doing asynchronous display

[marcprux]

Another option would be to use Android's APIs for getting an image's dimensions

One problem with dropping down to Android's native image decoding is that it doesn't handle all of our image formats (the aforementioned PDF and SVG and possibly others), and is a bit less sophisticated in terms of processing. For example, in skiptools/skip-kit#15 we see that an image taken by the camera that is automatically correctly rotated based on the EXIF data with Coil is mis-rendered by Android's native image handling.

[dfabulich]

skiptools/skipapp-showcase#78

https://github.com/dfabulich/skipapp-showcase/blob/c3f1cf8c13b7afd0bcba5915b450f501b6193cbc/Sources/Showcase/ImagePlayground.swift#L395-L416

private struct ImagePlaygroundButterflyGridStressView: View {
    private let butterflies = Array(0..<600)
    private let rows: [GridItem] = Array(repeating: GridItem(.fixed(24), spacing: 4), count: 10)

    var body: some View {
        ScrollView(.horizontal) {
            LazyHGrid(rows: rows, spacing: 4) {
                ForEach(butterflies, id: \.self) { _ in
                    Image("Butterfly", bundle: .module, label: Text("Butterfly SVG image"))
                        .resizable()
                        .scaledToFit()
                        .frame(width: 24, height: 24)
                }
            }
            .padding(8)
        }
    }
}

This sample renders smoothly on iOS, and terribly on Android. It takes a very long time to load (even in Release mode) and it drops frames when you scroll.

This is not merely because asset images are using Coil, but specifically using SubcomposeAsyncImage.

NOTE: This API uses subcomposition, which is slow. Avoid using this composable in places that need high performance (e.g. LazyRow/LazyColumn).

[marcprux]

I agree that SubcomposeAsyncImage is probably sub-optimal. So maybe we could fix this, but I still think there is value in trying to render these synchronously (being mindful of the ANR risk) using something like sketch or glide.