Sdwebimage: App crashes when load many images from firestore - swift

[SamboVisal]

New Issue Checklist

• [x] I have read and understood the CONTRIBUTING guide
• [x] I have read the Documentation

• [x] I have searched for a similar issue in the project and found none

  Info | Value |
  -------------------------|-------------------------------------|
  Platform Name | ios
  Platform Version | 10.13.0 / 11.0
  SDWebImage Version | 4.2.0
  Integration Method | cocoapods
  Xcode Version | Xcode 9
  Repro rate |all the time (100%)
  Repro with our demo prj | It happens with my demo project

Issue

I was trying to load imageUrl from firestore and load it to my application. Initially i tried to load around 4 or 10 images and it works fine. But when i want to load around 20 images and my app crashes and it also shows error in my console states that Message from debugger: Terminated due to memory issue .

[bpoplauschi]

@SamboVisal thanks for taking the time do describe the issue. We had similar issues in the past, usually because the iOS system cannot handle decompressing of many images at once, due to the memory spike that causes an out-of-memory crash. You can look at similar issues here: https://github.com/rs/SDWebImage/search?q=Terminated+due+to+memory+issue&type=Issues

One thing you can try is disabling the decompression:

[[SDImageCache sharedImageCache] setShouldDecompressImages:NO];
[[SDWebImageDownloader sharedDownloader] setShouldDecompressImages:NO];

Also check out these points about reducing the memory footprint: https://github.com/rs/SDWebImage/issues/2252#issuecomment-375891085

One thing I recommend is just running the app through instruments and inspecting the memory.

[SamboVisal]

Thank for your reply. I will try to fix this. But i have another question, when images are loading and i have seen some images are in not correct order and some images are duplicate in different cells. But after, images are loaded successfully then all images are in correct order. I wonder why?

[bpoplauschi]

@SamboVisal regarding the other issue, it would have been ideal to have a separate issue. But I can respond here: we also had similar issues: https://github.com/rs/SDWebImage/search?q=wrong+image&unscoped_q=wrong+image&type=Issues
I suggest you take a try with this suggestion: https://github.com/rs/SDWebImage/issues/968#issuecomment-64246783

[fschaus]

Hi guys,

I am having a very similar issue (using GIFs with v5.0 Beta 2) but can't get hold of the of the shouldDecompress method/ variable in Swift (went through the doc but couldn't find it)...

Do you mind letting me know how to set off the decompression in Swift? I'll try to see if this works before opening a new issues (if necessary).

Thanks!
Francois

[dreampiggy]

@fschaus Hi. The SDWebImage 5.x, change that global control level shouldDecompress, to the SDWebImageOptions level, which allow you to control each image request instead of a global one (Because some small images, it's no need to trun off that force decode feature, which cause a frame rate drop). See the related PR for this #2283 #1927

You can also find it on the migration guide here : 5.0-Migration-guide. The correspond options, was moved from cache/loader-level , to each image request level.

You should now use like this to disable the force decode feature:

imageView.sd_setImage(with: url, placeholderImage: nil, options: [.avoidDecodeImage])

And also, could I ask the issue why cause your application out of memory ? Did you setup a maxmium cache size SDImageCacheConfig.maxMemoryCost or maxMemoryCount to avoid cache too much of image in memory ? Did you try to load animation GIF on normal UIImageView ? (You can disable animation suppoert, by using firstFrameOnly options for each image request, or totally remove SDImageGIFCoder from coders list)

[fschaus]

Thanks for the input, I should have looked in the migration guide.

So I profiled a bunch of tests on my app to get to the bottom of this and see really weird behavior. See the link below for the details:
• My debug version runs as expected - once loaded my app allocates ~70Mb in memory (which is in line with what I saw previously when I was using KF). After a bit of usage (message loading + images) it goes up to 120-13Mb, rarely above (maxCache works) and flushes itself once the app enters background.
• My release/ prod scheme however shots straight to 160Mb at load, quickly goes to 300Mb (or more if I keep loading but then more often than not crashes) which doesn't respect my cache limit. If I don't turn off decoding the memory doesn't get flushed once the app enters the background (it decoding is off but still retains more than expected at 120-140Mb vs. 20-30Mb w/ my debug scheme).
• I use 5.0 beta 2, with a mix of fixed images and gifs (the initial loading screens only have fixed images). I also tested with UIImageView and AnimatedImgView but that makes no difference
• I also used Kingfisher to compare and its behavior with my prod release was similar to SDWI with my debug scheme. In all cases I use the "default" manager settings (except decode that I toggle on/ off for one of my use case).

My detailed tests are here: https://drive.google.com/open?id=1HIRHttQYn1NIJr0Omb9BG2FLOeWa8E_9

I am not deep enough in this library nor in iOS image frameworks to understand how they differ between the debug and the release scheme but I feel like the culprit is likely there (given the vastly different behavior observed).

I really like SDWebImg as it is the only library with a strong gif manager which allows me to have a single cache/ image processor for PGN & Gifs (I had a weird convoluted kingfisher + FLAnimatedImg setup before) and like how more flexbile SDWebImg is (e.g., add fade, progress bar, etc.) so really hope we can get to the bottom of this together J

Thanks!
Francois

[bpoplauschi]

@fschaus thanks for the detailed write-up, we will look into this issue in detail.
For now, I think it's a good idea to move your scenario to a separate issue, to keep the conversation clean. I don't think it's the exact same issue as the one in the description.

[bpoplauschi]

Moved @fschaus conversation to #2448

[bpoplauschi]

@SamboVisal can we close this issue now? Did you get what you needed?