iOS - 关于NSURLCache


一、简介

  • NSURLCache 为应用的 URL 请求提供了内存以及磁盘上的综合缓存机制,作为基础类库 URL 加载的一部分,任何通过 NSURLConnection 加载的请求都将被 NSURLCache 处理。
  • 网络缓存减少了需要向服务器发送请求的次数,同时也提升了离线或在低速网络中使用应用的体验。
  • 当一个请求完成下载来自服务器的回应,一个缓存的回应将在本地保存。下一次同一个请求再发起时,本地保存的回应就会马上返回,不需要连接服务器。NSURLCache
    自动透明 地返回回应。
  • 为了好好利用 NSURLCache
    ,你需要初始化并设置一个共享的 URL 缓存。在 iOS 中这项工作需要在 -application:didFinishLaunchingWithOptions:
    完成
 - (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions{ NSURLCache *URLCache = [[NSURLCache alloc] initWithMemoryCapacity:4 * 1024 * 1024 
diskCapacity:20 * 1024 * 1024
 diskPath:nil];
 [NSURLCache setSharedURLCache:URLCache];}

缓存策略由请求(客户端)和回应(服务端)分别指定。理解这些策略以及它们如何相互影响,是为您的应用程序找到最佳行为的关键。

二、NSURLRequestCachePolicy

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

注意

NSURLRequestReloadIgnoringLocalAndRemoteCacheData
和NSURLRequestReloadRevalidatingCacheData
根本没有实现Link to Radar)更加加深了混乱程度!

  • 关于 NSURLRequestCachePolicy
    ,以下才是你 实际 需要了解的东西:

常量 -------------------------------意义
UseProtocolCachePolicy------------- --默认行为
ReloadIgnoringLocalCacheData---------不使用缓存
ReturnCacheDataElseLoad-------------使用缓存(不管它是否过期),如果缓存中没有,那从网络加载吧
ReturnCacheDataDontLoad------------离线模式:使用缓存(不管它是否过期),但是从网络加载
NSURLRequestReloadIgnoringLocalAndRemoteCacheData,NSURLRequestReloadRevalidatingCacheData根本没有实现


三、HTTP 缓存语义

  • 因为 NSURLConnection被设计成支持多种协议——包括 FTP、HTTP、HTTPS——所以 URL 加载系统用一种协议无关的方式指定缓存。为了本文的目的,缓存用术语 HTTP 语义来解释
  • HTTP 请求和回应用 headers 来交换元数据,如字符编码、MIME 类型和缓存指令等。
  • Request Cache Headers
    • 在默认情况下,NSURLRequest 会用当前时间决定是否返回缓存的数据。为了更精确地控制,允许使用以下请求头:
      • If-Modified-Since- 这个请求头与 Last-Modified 回应头相对应。把这个值设为同一终端最后一次请求时返回的 Last-Modified 字段的值。
      • If-None-Match - 这个请求头与与 Etag 回应头相对应。使用同一终端最后一次请求的 Etag 值。
  • Response Cache Headers
    • NSHTTPURLResponse 包含多个 HTTP 头,当然也包括以下指令来说明回应应当如何缓存:
      • Cache-Control - 这个头 必须由服务器端 指定以开启客户端的 HTTP 缓存功能。这个头的值可能包含 max-age(缓存多久),是公共 public 还是私有 private,或者不缓存no-cache 等信息。详情请参阅 Cache-Control section of RFC 2616
    • 除了 Cache-Control 以外,服务器也可能发送一些附加的头用于根据需要有条件地请求(如上一节所提到的)
      • Last-Modified - 这个头的值表明所请求的资源上次修改的时间。例如,一个客户端请求最近照片的时间线,/photos/timeline,Last-Modified 的值可以是最近一张照片的拍摄时间。
      • Etag - 这是 “entity tag” 的缩写,它是一个表示所请求资源的内容的标识符。在实践中,Etag 的值可以是类似于资源的 MD5 之类的东西。这对于那些动态生成的、可能没有明显的 Last-Modified
        值的资源非常有用。
  • NSURLConnectionDelegate
    • 一旦收到了服务器的回应,NSURLConnection 的代理就有机会在 -connection:willCacheResponse: 中指定缓存数据。
    • NSCachedURLResponse 是个包含 NSURLResponse 以及它对应的缓存中的 NSData 的类.
    • 在 -connection:willCacheResponse: 中,cachedResponse 对象会根据 URL 连接返回的结果自动创建。因为 NSCachedURLResponse 没有可变部分,为了改变 cachedResponse 中的值必须构造一个新的对象,把改变过的值传入 –initWithResponse:data:userInfo:storagePolicy:,例如:
 - (NSCachedURLResponse *)connection:(NSURLConnection *)connection willCacheResponse:(NSCachedURLResponse *)cachedResponse
{ NSMutableDictionary *mutableUserInfo = [[cachedResponse userInfo] mutableCopy]; 
NSMutableData *mutableData = [[cachedResponse data] mutableCopy];
 NSURLCacheStoragePolicy storagePolicy = NSURLCacheStorageAllowedInMemoryOnly; 
// ...
 return [[NSCachedURLResponse alloc] initWithResponse:[cachedResponse response] 
data:mutableData 
userInfo:mutableUserInfo
 storagePolicy:storagePolicy];
}

如果 -connection:willCacheResponse: 返回 nil,回应将不会缓存。

 - (NSCachedURLResponse *)connection:(NSURLConnection *)connection willCacheResponse:(NSCachedURLResponse *)cachedResponse
{
 return nil;
}

如果不实现此方法,NSURLConnection 就简单地使用本来要传入 -connection:willCacheResponse:的那个缓存对象,所以除非你需要改变一些值或者阻止缓存,否则这个代理方法不必实现。

文章参考自这里

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

推荐阅读更多精彩内容

  • #iOS网络缓存扫盲篇 #--使用两行代码就能完成80%的缓存需求 下篇预告:[使用80%的代码来完成剩下的20%...
    coding_chen阅读 2,089评论 0 11
  • 概览 缓存组件应该说是每个客户端程序必备的核心组件,试想对于每个界面的访问都必须重新请求势必降低用户体验。但是如何...
    默默_David阅读 1,858评论 1 9
  • 概述 NSURLCache类通过将NSURLRequest对象映射到NSCached URLResponse对象来...
    夏天的风_song阅读 1,150评论 1 2
  • 转自:http://blog.csdn.net/ruiwang321/article/details/510363...
    飞雨2013阅读 848评论 0 2
  • 回到宿舍,大家都在娱乐,打游戏,听歌,看电影,我也照旧点了根烟,戴上耳机,听歌,浏览网页。看着看着也就无聊了。觉得...
    陈二狗的话阅读 200评论 0 1