详细解析几个和网络请求有关的类(十) —— 理解获取缓存(六)

版本记录

版本号 时间
V1.0 2018.03.12

前言

我们做APP发起网络请求,一般都是使用框架,这些框架的底层也都是苹果的API,接下来几篇就一起来看一下和网络有关的几个类。感兴趣的可以看上面几篇文章。
1. 详细解析几个和网络请求有关的类 (一) —— NSURLSession
2. 详细解析几个和网络请求有关的类(二) —— NSURLRequest和NSMutableURLRequest
3. 详细解析几个和网络请求有关的类(三) —— NSURLConnection
4. 详细解析几个和网络请求有关的类(四) —— NSURLSession和NSURLConnection的区别
5. 详细解析几个和网络请求有关的类(五) —— 关于NSURL加载系统(一)
6. 详细解析几个和网络请求有关的类(六) —— 使用NSURLSession(二)
7. 详细解析几个和网络请求有关的类(七) —— URL数据的编码和解码(三)
8. 详细解析几个和网络请求有关的类(八) —— 处理重定向和其他请求更改(四)
9. 详细解析几个和网络请求有关的类(九) —— 身份验证挑战和TLS链验证(五)

回顾

上一篇主要讲述身份验证挑战和TLS链验证,这里我们就看一下关于获取缓存方面的理解。


Understanding Cache Access - 理解缓存的获取

URL加载系统提供了对请求的响应的复合磁盘和内存缓存。 此缓存允许应用程序减少对网络连接的依赖并提高其性能。


Using the Cache for a Request - 使用缓存进行请求

NSURLRequest实例通过将缓存策略设置为NSURLRequestCachePolicy值之一来指定本地缓存的使用方式:NSURLRequestUseProtocolCachePolicyNSURLRequestReloadIgnoringCacheDataNSURLRequestReturnCacheDataElseLoadNSURLRequestReturnCacheDataDontLoad

NSURLRequest实例的默认缓存策略是NSURLRequestUseProtocolCachePolicyNSURLRequestUseProtocolCachePolicy行为是协议特定的,并被定义为协议的最佳符合策略。

将缓存策略设置为NSURLRequestReloadIgnoringCacheData将导致URL加载系统从原始源加载数据,并完全忽略缓存。

NSURLRequestReturnCacheDataElseLoad缓存策略会导致URL加载系统使用缓存数据,忽略其时间或到期日期,并且仅在没有缓存版本时才从原始源加载数据。

NSURLRequestReturnCacheDataDontLoad策略允许应用程序指定只返回缓存中的数据。如果响应不在本地缓存中,尝试使用此缓存策略创建NSURLSessionTask实例将立即返回nil。这在功能上与“脱机”模式类似,并且永远不会启动网络连接。

注意:目前只缓存对HTTP和HTTPS请求的响应。 FTP和file协议尝试访问缓存策略允许的发起源。自定义NSURLProtocol类可以选择性的提供缓存。


Cache Use Semantics for the HTTP Protocol - 缓存使用HTTP协议的语义

最复杂的缓存使用情况是当请求使用HTTP协议并将缓存策略设置为NSURLRequestUseProtocolCachePolicy时。

如果请求中不存在NSCachedURLResponse,则URL加载系统将从原始源获取数据。

如果请求存在缓存的响应,则URL加载系统会检查响应以确定它是否指定内容必须重新生效。

如果内容必须重新生效,则URL加载系统会向始发源发出HEAD请求,以查看资源是否已更改。如果它没有改变,那么URL加载系统返回缓存的响应。如果它已更改,则URL加载系统将从原始源中提取数据。

如果缓存的响应未指定必须重新验证内容,则URL加载系统将检查缓存响应中指定的最大使用期限或到期日期。如果缓存的响应足够接近最近的时间,则URL加载系统返回缓存的响应。如果响应失效,则URL加载系统向始发源发出HEAD请求以确定资源是否已更改。如果是这样,则URL加载系统从原始源获取资源。否则,它返回缓存的响应。

RFC 2616第13节(http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13)详细说明了详细涉及的语义。


Controlling Caching Programmatically - 以编程方式控制缓存

默认情况下,根据请求的缓存策略对请求的数据进行缓存,正如处理请求的NSURLProtocol子类所解释的那样。

如果您的应用程序需要对缓存进行更精确的编程控制(并且协议支持缓存),则可以实现代理方法,以便应用程序根据每个请求确定是否应缓存特定的响应。

对于NSURLSession数据和上传任务,实现URLSession:dataTask:willCacheResponse:completionHandler:方法。此委托方法仅用于数据和上载任务。下载任务的缓存策略由指定的缓存策略独占决定。

对于NSURLSession,您的代理方法调用完成处理程序块来告诉会话要缓存的内容。代理通常会提供以下一个值:

  • 提供的响应对象以允许缓存
  • 新创建的响应对象来缓存修改后的响应 - 例如,具有允许将内容缓存到内存但不保存到磁盘的存储策略的响应
  • nil以防止缓存

您的代理方法还可以将对象插入到与NSCachedURLResponse对象关联的userInfo字典中,从而将这些对象作为响应的一部分存储在缓存中。

重要:你的代理方法必须调用提供的完成处理handler,否则会引起内存泄露。

Listing 5 - 1 中的例子阻止了HTTPS响应的磁盘缓存。 它还会将当前日期添加到用户信息字典中以缓存响应。

// Listing 5-1  Example URLSession:dataTask:willCacheResponse:completionHandler: implementation

- (void)URLSession:(NSURLSession *)session dataTask:(NSURLSessionDataTask *)dataTask
 willCacheResponse:(NSCachedURLResponse *)proposedResponse
 completionHandler:(void (^)(NSCachedURLResponse * __nullable cachedResponse))completionHandler {
    NSCachedURLResponse *newCachedResponse = proposedResponse;
    NSDictionary *newUserInfo;
    newUserInfo = [NSDictionary dictionaryWithObject:[NSDate date]
                                              forKey:@"Cached Date"];
    if ([proposedResponse.response.URL.scheme isEqualToString:@"https"]) {
#if ALLOW_IN_MEMORY_CACHING
        newCachedResponse = [[NSCachedURLResponse alloc]
                             initWithResponse:proposedResponse.response
                             data:proposedResponse.data
                             userInfo:newUserInfo
                             storagePolicy:NSURLCacheStorageAllowedInMemoryOnly];
#else // !ALLOW_IN_MEMORY_CACHING
        newCachedResponse = nil;
#endif // ALLOW_IN_MEMORY_CACHING
    } else {
        newCachedResponse = [[NSCachedURLResponse alloc]
                             initWithResponse:[proposedResponse response]
                             data:[proposedResponse data]
                             userInfo:newUserInfo
                             storagePolicy:[proposedResponse storagePolicy]];
    }
 
    completionHandler(newCachedResponse);
}

后记

本篇主要介绍了关于缓存获取方面的内容,喜欢的给个关注,谢谢~~~

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 194,524评论 5 460
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 81,869评论 2 371
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 141,813评论 0 320
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 52,210评论 1 263
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 61,085评论 4 355
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 46,117评论 1 272
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 36,533评论 3 381
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 35,219评论 0 253
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 39,487评论 1 290
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 34,582评论 2 309
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 36,362评论 1 326
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 32,218评论 3 312
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 37,589评论 3 299
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 28,899评论 0 17
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 30,176评论 1 250
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 41,503评论 2 341
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 40,707评论 2 335

推荐阅读更多精彩内容