基于AFNetWorking3.0的图片缓存分析

图片在APP中占有重要的角色,对图片做好缓存是重要的一项工作。
[TOC]

理论

不喜欢理论的可以直接跳到下面的Demo实践部分

缓存介绍

缓存按照保存位置可以分为两类:内存缓存、硬盘缓存(FMDB、CoreData...)。
我们常说的数据缓存包含内存缓存、硬盘缓存和网络请求URL缓存。其中网络请求URL缓存也包含内存缓存和硬盘缓存。

图片缓存思路

图片缓存流程图.png

URL缓存(缓存请求)

网络请求除了客户端需要做简单的配置外,最主要需要服务器支持,服务端也很简单,只需要在response里面设置Cache-Control字段就行了.

最常见的URL缓存实现方式:NSURLCache。NSURLCache可以在memory 和 disk 上缓存。
AFNetWorking是基于NSURLSession(iOS7以上的网络请求框架),在生成配置的时候有三种配置选择

+ (NSURLSessionConfiguration *)defaultSessionConfiguration;  
//默认会话模式(default):工作模式类似于原来的NSURLConnection,使用的是基于磁盘缓存的持久化策略,使用用户keychain中保存的证书进行认证授权。
+ (NSURLSessionConfiguration *)ephemeralSessionConfiguration;  
//瞬时会话模式(ephemeral):该模式不使用磁盘保存任何数据。所有和会话相关的caches,证书,cookies等都被保存在RAM中,因此当程序使会话无效,这些缓存的数据就会被自动清空。
+ (NSURLSessionConfiguration *)backgroundSessionConfiguration:(NSString *)identifier;  
//后台会话模式(background):该模式在后台完成上传和下载,在创建Configuration对象的时候需要提供一个NSString类型的ID用于标识完成工作的后台会话。

也就是说default同时实现了内存缓存和硬盘缓存,ephemeral实现了内存缓存,对于图片下载我们当然选择default。
我们还可以对缓存的大小进行设置,只需要对NSURLCache进行初始化就可以了

实现初始化

-application:didFinishLaunchingWithOptions:中对[NSURLCache sharedURLCache]进行初始化设置:

NSURLCache *URLCache = [[NSURLCache alloc] initWithMemoryCapacity:4 * 1024 * 1024
                                                         diskCapacity:20 * 1024 * 1024
                                                             diskPath:nil];
[NSURLCache setSharedURLCache:URLCache];

也可以单独对NSURLSessionconfiguration进行设置,
在AFNetWorking中对于图片网络请求设置了20M的内存缓存和150M的硬盘缓存:

+ (NSURLCache *)defaultURLCache {
    return [[NSURLCache alloc] initWithMemoryCapacity:20 * 1024 * 1024
                                         diskCapacity:150 * 1024 * 1024
                                             diskPath:@"com.alamofire.imagedownloader"];
}
缓存策略

缓存策略是指对网络请求缓存如果处理,是使用缓存还是不使用

NSURLRequestUseProtocolCachePolicy: 对特定的 URL 请求使用网络协议中实现的缓存逻辑。这是默认的策略。
NSURLRequestReloadIgnoringLocalCacheData:数据需要从原始地址加载。不使用现有缓存。
NSURLRequestReloadIgnoringLocalAndRemoteCacheData:不仅忽略本地缓存,
      同时也忽略代理服务器或其他中间介质目前已有的、协议允许的缓存。
NSURLRequestReturnCacheDataElseLoad:无论缓存是否过期,先使用本地缓存数据。
      如果缓存中没有请求所对应的数据,那么从原始地址加载数据。
NSURLRequestReturnCacheDataDontLoad:无论缓存是否过期,先使用本地缓存数据。
      如果缓存中没有请求所对应的数据,那么放弃从原始地址加载数据,
      请求视为失败(即:“离线”模式)。
NSURLRequestReloadRevalidatingCacheData:从原始地址确认缓存数据的合法性后,
      缓存数据就可以使用,否则从原始地址加载。

在AFNetWorking中同样对configuration进行设置

configuration.requestCachePolicy = NSURLRequestUseProtocolCachePolicy;

如果你继承AFImageDownloader重新实现了他的初始化,requestCachePolicy注意AFImageDownloader中只有三种才设置了缓存

case NSURLRequestUseProtocolCachePolicy:
case NSURLRequestReturnCacheDataElseLoad:
case NSURLRequestReturnCacheDataDontLoad:

图片内存缓存

AFNetWorking3.0放弃了NSCache作为图片内存缓存管理,这让我非常不解。
有人说它的性能和 key 的相似度有关,如果有大量相似的 key (比如 "1", "2", "3", ...),NSCache 的存取性能会下降得非常厉害,大量的时间被消耗在 CFStringEqual() 上,不知这是不是放弃使用NSCache的原因。

像素在内存中的布局和它在磁盘中的存储方式并不相同。考虑一种简单的情况:每个像素有R、G、B和alpha四个值,每个值占用1字节,因此每个像素占用4字节的内存空间。一张1920*1080的照片(iPhone6 Plus的分辨率)一共有2,073,600个像素,因此占用了超过8Mb的内存。但是一张同样分辨率的PNG格式或JPEG格式的图片一般情况下不会有这么大。这是因为JPEG将像素数据进行了一种非常复杂且可逆的转化。

AFNetWorking3.0的图片缓存类貌似是基于这个理论来做内存大小管理的(之前AF的内存大小计算方法有错,我修改了一下提交了,现在已经审核通过合并进去了,哈哈哈哈哈,我也算是贡献过AF了)。AFNetWorking2.x中还是使用AFImageCache进行memory上缓存。

NSCache在memory上缓存,类似于NSMutableDictionary ,以 哈希算法 管理。有自动清理机制,当缓存到memory时,如果memory空间不够,则会自动删除memory中当前界面不使用的空间。

AFAutoPurgingImageCache使用NSMutableDictionary <NSString* , AFCachedImage*>进行内存缓存映射,并进行管理,当内存警告时就清空NSMutableDictionary。如果内存占用超过限制,则按照时间顺序进行删除。

图片硬盘缓存

就是我们常说的把数据保存在本地,比如FMDB、CoreData、归档、NSUserDefaults、NSFileManager等等,这里就不多说了。
AFNetWorking3.0没有直接做图片硬盘缓存,而是通过URL缓存做的硬盘缓存。也就是说,如果内存缓存没有读取到图片,就会调用下载逻辑,通过下载缓存的内存缓存硬盘缓存来获取到已下载过的图片,如果没有下载过,就会重新下载。
如果我们自己做图片硬盘缓存建议使用NSFileManager,因为一般图片data会比较大,测试证明路径缓存会比放在数据库有更高的性能。

实践

Demo下载

使用NSURLSession做网络请求缓存。

    NSURLSessionConfiguration *config = [NSURLSessionConfiguration defaultSessionConfiguration];     //使用default配置,自带网络请求缓存
    [config setHTTPAdditionalHeaders:@{@"Accept":@"image/*"}];//设置网络数据格式
    NSURLSession *session = [NSURLSession sessionWithConfiguration:config];
    NSURLRequest *request = [NSURLRequest requestWithURL:url];
    WEAKSELF
    NSURLSessionDataTask *task = [session dataTaskWithRequest:request 
      completionHandler:^(NSData * _Nullable data, 
    NSURLResponse * _Nullable response, NSError * _Nullable error) { 
    //使用’获取数据(NSURLSessionDataTask)‘的方式发起请求
        UIImage *image = [UIImage imageWithData:data];
        dispatch_async(dispatch_get_main_queue(), ^{
            weakSelf.imageView.image = image;
        });
    }];
    [task resume];

我们通过连续两次下载图片可以发现defaultSessionConfiguration下NSURLSession会自动做网络请求缓存。

使用AFNetWorking下载图片

导入头文件#import "UIImageView+AFNetworking.h"
使用特别简单,只有一行代码:[imageView setImageWithURL:url];
UIImageView+AFNetworking做了内存缓存和基于NSURLSession的网络请求缓存,并没有做硬盘缓存,估计是考虑到图片的网络请求硬盘缓存足以满足需要,所以省略了额外的硬盘缓存,内存缓存加快了读取速度,这个是非常有必要的。

进入UIImageView+AFNetworking代码分析:

if ([urlRequest URL] == nil) {
        [self cancelImageDownloadTask];
        self.image = placeholderImage;
        return;
    }
//如果新传入的URL为空则取消图片下载并设置图片为默认图
if ([self isActiveTaskURLEqualToURLRequest:urlRequest]){
        return;
    }
//如果新传入的URL与当前URL相同则直接返回,否则取消当前下载,重新进行图片查找下载
UIImage *cachedImage = [imageCache imageforRequest:urlRequest withAdditionalIdentifier:nil];
//从内存缓存中读取image,如果没有则发起新的请求
AFImageDownloader *downloader = [[self class] sharedImageDownloader];
//使用单例下载,内存缓存为downloader.imageCache
//downloader设置的网络请求20M的内存缓存和150M的硬盘缓存
//downloader设置的网络请求缓存策略为NSURLRequestUseProtocolCachePolicy
//imageCache设置了内存60M最大100M
//网络请求发起前会再次判断imageCache中是否含有该image

测试

使用Charles查看图片下载的网络请求发生了几次,判断缓存是否成功。
其中硬盘缓存需要写入时间,网络请求完成后略等一下,否则硬盘缓存不会生效

设置默认网络缓存大小

如果没有对NSURLRequestURLCache进行设置,默认是使用[NSURLCache sharedURLCache],所以如果有需要可以如下设置

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
    // Override point for customization after application launch.
    [AFNetworkActivityIndicatorManager sharedManager].enabled = YES;
    //网络请求时状态栏网络状态小转轮
    
    NSURLCache *URLCache = [[NSURLCache alloc] initWithMemoryCapacity:4 * 1024 * 1024
                                                         diskCapacity:20 * 1024 * 1024
                                                             diskPath:nil];
    //内存4M,硬盘20M
    [NSURLCache setSharedURLCache:URLCache];
    
    return YES;
}
最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 202,056评论 5 474
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 84,842评论 2 378
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 148,938评论 0 335
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,296评论 1 272
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,292评论 5 363
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,413评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,824评论 3 393
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,493评论 0 256
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,686评论 1 295
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,502评论 2 318
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,553评论 1 329
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,281评论 4 318
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,820评论 3 305
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,873评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,109评论 1 258
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 42,699评论 2 348
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,257评论 2 341

推荐阅读更多精彩内容