SDWebimage 相同url缓存图片对比问题

1.从服务器的策略来说，通常的做法会返回ETag和Lastmodified，client后续再次请求时，会带上上一次的ETag，服务端如果发现文件没有改变，会返回304，而一旦发生改变（就是你所说的文件换掉），则会返回新数据以及新的ETag。如此循环往复。

2.经过查看源码，找到如下方法：

- (void)sd_setImageWithURL:(NSURL *)url placeholderImage:(UIImage *)placeholder options:(SDWebImageOptions)options progress:(SDWebImageDownloaderProgressBlock)progressBlock completed:(SDWebImageCompletionBlock)completedBlock{}

SDWebImageOptions:其中SDWebImageRefreshCached是专门处理相同url，但不同image的情况的。

3.http://www.mamicode.com/info-detail-511387.html官方文档

SDWebImage does very aggressive caching by default. It ignores all kind of caching control header returned by the HTTP server and cache the returned images with no time restriction. It implies your images URLs are static URLs pointing to images that never change. If the pointed image happen to change, some parts of the URL should change accordingly.

If you don‘t control the image server you‘re using, you may not be able to change the URL when its content is updated. This is the case for Facebook avatar URLs for instance. In such case, you may use theSDWebImageRefreshCachedflag. This will slightly degrade the performance but will respect the HTTP caching control headers:

sdwebimage确实非常积极的缓存默认。它忽略了各种缓存控制头返回的HTTP服务器和缓存返回的图像没有时间限制。它意味着你的图像的网址是静态的网址指向的图像，从来没有改变。如果指向的图像发生改变，一些部分的网址应该相应改变。

如果你不控制你使用的图像服务器，你可能无法改变它的内容更新时的网址。这是一种情况下，脸谱网头像网址为例。在这种情况下，你可以使用sdwebimagerefreshcached旗。这将稍微降低性能，但会尊重HTTP缓存控制头：

[imageViewsd_setImageWithURL:[NSURLURLWithString:@"https://graph.facebook.com/olivier.poitrey/picture"]placeholderImage:[UIImageimageNamed:@"avatar-placeholder.png"]options:SDWebImageRefreshCached];