Memory issue when caching too many GIFs in List / LazyVStack

[tatsuz0u]

Clearing memory caches manually doesn't help.
Reproduced in 2.0.0 & 2.0.1.

I used 70 gifs (5-7 MB each) to reproduce with my 4GB memory iPhone.

import SwiftUI
import SDWebImageSwiftUI

struct ContentView: View {
    let gifs = // bunch of gifs here
    
    var body: some View {
        ScrollView {
            LazyVStack {
                ForEach(gifs, id: \.hashValue) { gif in
                    WebImage(url: URL(string: gif))
                        .resizable()
                        .indicator(.progress)
                        .scaledToFit()
                }
            }
        }
    }
}

[tatsuz0u]

Doesn't have to be GIF, normal images can reproduce it too.

[dreampiggy]

Use the .purgeable modifier. By default the individual frames image cache is kept in memory (Inside the WebImage's observed ImagePlayer instance level, so not effected by global SDImageCache). even if the image is not visible (animation is stop).

[dreampiggy]

Or you can try to use the AnimatedImage to see if this behavior matches the same.

[tatsuz0u]

Thanks, I'll try that modifier :-)

But why the caches weren't cleared even if I manully call the clear method?
I suppose the caches should be cleared after SDWebImage received the memory warning.

[dreampiggy]

It should. If you use simulator, iPhone simulator use your Mac RAM. Which may not trigger the warning notification.

See source code, which explain what we did: https://github.com/SDWebImage/SDWebImage/blob/master/SDWebImage/Core/SDAnimatedImagePlayer.m#L71-L86

[tatsuz0u]

That's weird, I used a real device.

[dreampiggy]

@arakitatsuzou Can you run Instruments Profile with Allocation or Leak to see the result ? Or upload here (Use Instruments's Save button)

You can check the Head Allocation to find, whether there are more than 70 SDAnimatedImagePlayer instances inside memory. For normal, each WebImage loading animation, will finally associated one SDAnimatedImagePlayer instance. If there are more than one, may be something issues.

I previouslly fix one issue using the Insturments there via #163. But you says you use v2.0.1, sounds strange.

[tatsuz0u]

OK, I'll try it later.

[tatsuz0u]

I finished the profile, no leaks and only one SDAnimatedImagePlayer.
It crashed due to memory issue anyway.

I can upload the trace file to Mega, or full allocation summary screenshots instead?

Update: The .purgeable modifier doesn't help.

[dreampiggy]

@arakitatsuzou It's OK to upload to any Cloud File Server like Mega, or better Google Drive.

[dreampiggy]

Try some magic to config the cache used for animation player.

1. The .maxBufferSize() modifier. Which controls each WebImage's max buffer. You can limit to a really small size (such as 1MB per WebImage), so that player will not allocate larget than buffer. But remember, this will cause CPU heavy work because we can not cache the each frame buffer and have to re-decode each time it should render on screen. (trade time for space).

2. Don't use .avoidDecodeImage in SDWebImageOptions for animation. Which will re-draw with CGContext and transfer the RAM usage to the Core Animation render server (which is another XPC process, not in your App process). This magic will make iOS system not so aggressive to kill your App. :)

[tatsuz0u]

https://drive.google.com/file/d/1lPFrRLghcn5B9zkGFMLLqa27EcBYkjYD/view?usp=sharing

I tried setting .maxBufferSize() to 1024 * 1024 * 500 or 1024 * 1024 * 1 just now but it didn't work.

Check this, please :-)
onevcat/Kingfisher#1638

[dreampiggy]

The trace seems does not contains the debugging symbol to show your business code...So I have to guess your use case.

There are 45 SDAnimatedImagePlayer in the memory and does never release. Is that means, your SwiftUI WebImage showing 45 WebImage at the same time ? Or your SwiftUI code using one of NagivationLink, TabView or something, which will keep the View visible or retain it. So that it does not release the RAM.

• There are also 142 individual GIF frame inside memory. Each of them use 2.1MB (Means your frame pixel is like 725x725 ?), so this will consume at least 298MB .

• There are also 52 individual GIF frame consume 7.9MB per each. Is this your own image such as placeholder or somethinig ? It does not loaded by SDWebImage (because we use initWithCGImage: API), this at least 411MB.

• There are also 97 individual GIF frame consume 3.27MB per each. This at least 317.19MB.

• There are also 50 individual GIF frame consume 2.23MB per each. This at least 111.5MB.

And even, there are some large NSData inside memory by using dataWithContentsOfFile:. Which consume 50MB.

So, totally: 1200MB. Which may match your current memory pressure. (1.77GB and terminated)

---

I think this is because of your own code in App, which does not manage the large amount of images. For example, you can use the thumbnailPixelSize to limit the frame size of GIF frame, or destroy some non-visible images. (Are you really want to show 45 WebImage view at the same time ?)

[dreampiggy]

Seems I need more useful information, like a workable demo, or at least some UI strcture for analyze. Or you can analyze by yourself with the description I talked.

WebImage is not magic. If you show large amount of animation at the same time, you'd better limit the RAM usage for each one, or you can pause some of images and setup puragable to free the GIF frame buffer which is not animating.