SDWebImage和图片压缩、缓存

iOS中的图片加载

加载方式

imageWithContentsOfFile:+图片路径([[NSBundle mainBundle] pathForResource:@”icon” ofType:@”png”]),不会缓存到内存,适合用于加载较大的不常用的图片降低内存消耗。

imageNamed:+图片名,会缓存到内存且无法释放。

imageWithData:+二进制data,不缓存,适合网络下载图像生成UIImage。

然后将生成的UIImage赋值给UIImageView,CA捕捉到图层树的变化在下一个run loop中提交,然后对图片进行copy操作:解压缩成位图、读到内存中、CA渲染到UIImageView图层。

解压缩

位图其实是一个像素集合,所以图片的文件大小和其解压后所占的内存没有任何关系,只跟图片的像素有关(图片大小:像素宽*像素高*4字节)。但解压缩需要消耗大量CPU时间而且默认在主线程进行。所以出现了,在子线程提前强制解压缩的方案(因为默认的解压缩步骤是在显示到屏幕上的时候才执行的),核心函数:CGBitmapContextCreate。

SDWebImageDecoder中的decodedImageWithImage函数提供了解决方案,原理如下:CGBitmapContextCreate创建一个位图上下文→CGContextDrawImage绘制原始位图到上下文→CGBitmapContextCreateImage创建解压后的新位图。

注:CGContextDrawImage过程中把alpha通道移除了,所以不支持透明度的图片。

图片压缩

对于超大的图片,sd还提供了decodedAndScaledDownImageWithImage压缩方法,避免内存爆炸。原理:将图像矩阵按照规则分割成小型子矩阵进行压缩,然后插值拼接。

SDWebImage

UIImageView+WebCache.h → SDWebImageManager → SDImageCache → SDWebImageDownloader

源码解析

加载:通常我们使用UIImageView显示图片,所以SDWebImage提供了它的扩展方法,一般使用

- (void)sd_setImageWithURL:(nullable NSURL *)url  //路径

placeholderImage:(nullableUIImage *)placeholder  //缺省图

options:(SDWebImageOptions)options  //加载规则

progress:(nullableSDWebImageDownloaderProgressBlock)progressBlock  //进度

completed:(nullableSDExternalCompletionBlock)completedBlock;  //完成的block

或其变种方法进行图片加载(底层依赖UIView+WebCache的扩展方法,更底层是SDWebImageManager的loadImageWithURL方法)。

注:底层流程,SDImageCache的queryCacheOperationForKey方法判断缓存,imageDownloader的downloadImageWithURL方法开启下载任务(方法中利用SDWebImageDownloaderOperation对象配置各种属性以及实现提前子线程解压缩的流程)。

SDWebImageManager

下载图片:核心方法→loadImageWithURL

注:其中还封装了缓存类和下载器的单例;shouldDownloadImageForURL代理设置是否在无缓存时下载;transformDownloadedImage设置是否对图片进行transform操作。

SDImageCache

请求获取缓存:核心方法→queryCacheOperationForKey(一般用url做key),实现流程→imageFromMemoryCacheForKey判断是否在缓存中,self.memCache;diskImageForKey从磁盘中获取,含解码decodedImageWithImage。

生成缓存:核心方法→storeImage: forKey: completion:(可设置是否缓存到硬盘等),实现流程→self.memCache setObject: forKey: cost: 实现内存缓存,storeImageDataToDisk: forKey: 实现磁盘缓存(文件名使用了key即URL的MD5转换)。

缓存清理:核心方法→clearMemory清理内存,clearDiskOnCompletion异步清理磁盘;每次app退出接收到UIApplicationWillTerminateNotification通知时执行deleteOldFilesWithCompletionBlock方法清理过期缓存,若清理完成后磁盘占用大于设定值self.config.maxCacheSize,则按照时间排序(NSURLContentModificationDateKey)后删除。

注:可设置maxMemoryCost最大空间花销或者maxMemoryCountLimit最大数量进行缓存约束;SDImageCacheConfig中控制了maxCacheAge过期时间和maxCacheSize最大缓存空间。

SDWebImageDecoder:

提前解码图片:核心方法→decodedImageWithImage,image.CGImage获取CGImageRef位图,CGColorSpaceRef色彩空间,宽高等,根据前文中的解压缩原理返回一个新的UIImage对象。

压缩图片:核心方法:decodedAndScaledDownImageWithImage,根据属性判断是否需要压缩,然后获取图形上下文和位图,计算像素并分块,然后循环插值。

底层依赖于Quartz 2D的图像处理库。

图片缓存模块

核心功能:根据键值从缓存中获取图片;缓存图片到内存或硬盘;缓存管理机制(过期、清理、限制大小)。

缓存淘汰算法之FIFO

原理:按照时间顺序先进先出,队列。

Second-Chance(FIFO变种1)

原理:给对象加标志位,如果引用了则设置标志位为1。淘汰时判断如果标志位为1,则置为0后加入队列尾部,淘汰一下个为0的对象。

复杂度:需要记录标志位和数据移动,命中率和代价比FIFO高。

Clock(Second-Chance改进版

通过指针实现环形队列避免数据移动,降低代价。

注:FIFO及其变种算法,命中率过低,实际很少使用。

缓存淘汰算法之LRU

原理:最近最少使用。判断最近被使用的时间,最远的优先淘汰。新数据插入链表头部,缓存被命中时移动到链表头部,链表满时丢弃尾部。

命中率:存在热点数据时效率很好但偶发性、周期性的批量操作会导致命中率急剧下降,缓存污染情况严重。

代价:遍历链表找命中的数据块,然后移动到头部。

LRU-K(解决LRU-1的缓存污染)

原理:需要两个队列,首次访问的数据加入到历史队列中,当数据访问次数达到K次时,放入正式的缓存队列中,并删除历史队列中的索引。淘汰数据时,先按照FIFO或者LRU淘汰历史队列中的数据,再按照时间排序淘汰缓存队列中的数据。

命中率:降低了缓存污染问题,命中率提高。但适应性差,K值大时需要大量访问才能将数据移除历史队列,加入缓存。

代价:由于要维护两个队列,所以内存消耗大;由于要基于时间排序,所以CPU消耗高;由于是优先级队列,算法复杂度也较高。

Two queues(2Q,FIFO+LRU)

原理:第一次访问加入FIFO队列中,第二次访问将数据从FIFO移入LRU,两队列各自按照规则淘汰数据。

命中率:高于LRU,代价是FIFO和LRU之和。

缓存淘汰算法之LFU

原理:每个数据块都有一个引用计数,按照引用计数排序,相同按时间。新数据插入到队列尾部,被访问时引用计数+1,队列重新排序。淘汰数据时直接淘汰尾部。

命中率:一般情况下优于LRF,但需要时间适应新的访问模式。

代价:需要记录所有访问数据,内存消耗较高;需要排序,性能消耗较高。

变种:LFU*,只淘汰引用计数为1的数据,无法适应访问模式。

LFU-Aging,考虑访问时间,通过最大访问数来控制访问时间,比如达到100了,就变成50,能更快适应新的访问模式。

Window-LFU,不记录所有历史访问,只记录一段时间内的访问,节约了内存和性能。

你可能感兴趣的:(SDWebImage和图片压缩、缓存)