Sdwebimage: Need an inexpensive way to check if image is cached on disk

Created on 12 Dec 2013  ·  13Comments  ·  Source: SDWebImage/SDWebImage

Now to check if image for a URL is cached on disk, we need to call

  • (UIImage *)imageFromDiskCacheForKey:(NSString *)key
    or
  • (void)queryDiskCacheForKey:(NSString *)key done:(void (^)(UIImage *image, SDImageCacheType cacheType))doneBlock
    which needs to read the whole file and decode the image. I am only interested in whether it's already cached and want to use the iOS 7 background fetching mechanism (NSURLSessionDownloadTask) to fetch it if not, and store it back to SDWebImage cache when it's done. It would be way more performant to have a function that checks either an in-memory dictionary or even just check for existence of the cached file to see if the image is cached.

Most helpful comment

Not true:

SDWebImageManager.h

/**
 * Check if image has already been cached
 */
- (BOOL)diskImageExistsForURL:(NSURL *)url;

All 13 comments

Not true:

SDWebImageManager.h

/**
 * Check if image has already been cached
 */
- (BOOL)diskImageExistsForURL:(NSURL *)url;

This was fixed in the last release, which I did not pick up yet. Closing

@donholly many thanks

What's an inexpensive way to check if an image is cached in memory? Is it okay just to access -(UIImage *)imageFromMemoryCacheForKey:(NSString *)key;? Is this expensive?

SDWebImageManager.h file you can find one method

/ - (BOOL)cachedImageExistsForURL:(NSURL *)url;

Using this method you can check

@PKrupa94 it seems that the function you mention is async. Is there a sync alternative?

Also interested in a sync alternative that just returns quickly. Or potentially a way to load only images that are cached.

I was able to work around my issue which was about loading specifically sized images from an API, and I suppose a sync method does not exist. In my case I needed to re-fetch the image from url if the sdimagecachetype was anything but memory. Not sure the reason for that. I had to create a separate cache and query the contents of that - get the image and cache type with the query and if it wasn't a memory cache type I'd fetch again, store to my cache, then reload the whole cell from table view.

Yea I'm working with an API where I don't get the size until the image loads. And I'm storing them in a UICollectionView which is very upset to recalculate the sizes multiple times for cells since on scroll the images are still loading async. I'm having to set a fixed size for the images as a work around at this point. There must be a way to make it work but the collection view was very unhappy. Scrolling performance dropped to 10fps because of the images loading from cache so quickly but not instantly.

I tried using a DispatchGroup to wait if I knew the image was cached, but it was still too slow.

I think with a method to load a cached image from memory synchronously, I'd have been able to pull it off. Because I could do that or if it was null, I could give the cell a default size and wait for the image to load. But there would be sufficient time at that point for the load that the collection view would only be sizing cells seconds apart rather than ms apart.

I think I read somewhere here that even loads from disk cache are too slow and would cause jumpy UI performance which is why sdwebimage obviously (?) does disk loading on a background thread, which actually should be the correct way. So in any case image fetching should not be done in sync in the main thread.

If you're using a collection view then I suppose your case could maybe be fixed in a similar way with mine. I had a set width for the images, but I still needed to maintain the original aspect ratio of each image, which needed to be calculated after an image was fetched, and then set through a layout constraint. I got it to work in the end.

Yea I was looking for an in memory cache check I could use, since the size would be called immediately after the image loads the slower way.

But I guess we'll live with fixed size for now until we can write our own cache or write our own API that returns the size of the image in the initial object load.

Sdwebimage even has this cache class which can be instantiated like this. I put this in the specific thumbnail cell class I used. Might be worth checking out.

private static let cache = SDImageCache.init(namespace: "mynewcache")

2018/01/27 9:29、Ryan Poolos notifications@github.comのメール:

Yea I was looking for an in memory cache check I could use, since the size would be called immediately after the image loads the slower way.

But I guess we'll live with fixed size for now until we can write our own cache or write our own API that returns the size of the image in the initial object load.


You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

@zapjonny The diskImageExistsWithKey: has been removed during 4.x. Through I think that it's a bad idea. I didn't experienced that time but the reason to do that may be that SD 3.x expose the ioQueue to the user, so if user call from ioQueue with a dispatch_sync, the dead lock occur. However, this issue should be not happend now because we do not expose this queue.

So I put back the sync version API diskImageDataExistsWithKey: in SD 4.3.0, see #2190. The 4.3.0 version will be released in the end of January in plan :)

Was this page helpful?
0 / 5 - 0 ratings

Related issues

paul-lavoine picture paul-lavoine  ·  4Comments

rpstro02 picture rpstro02  ·  3Comments

doingy picture doingy  ·  4Comments

onato picture onato  ·  3Comments

cyanzhong picture cyanzhong  ·  5Comments