甜橘子，专注成都网站制作网站设计与营销型网站建设与优化
QQ :532337155
电话：028-86922220
浏览器缓存机制是指通过HTTP协议头里的Cache-Control(或Expires)和Last-Modified(或Etag)等字段来控制文件缓存的机制。这应该是WEB中最早的缓存机制了，是在HTTP协议中实现的，有点不同于DomStorage、AppCache等缓存机制，但本质上是一样的。可以理解为，一个是协议层实现的，一个是应用层实现的。
目前成都创新互联已为上1000+的企业提供了网站建设、域名、网络空间、网站运营、企业网站设计、吐鲁番网站维护等服务，公司将坚持客户导向、应用为本的策略，正道将秉承"和谐、参与、激情"的文化，与客户和合作伙伴齐心协力一起成长，共同发展。
Cache-Control用于控制文件在本地缓存有效时长。最常见的，比如服务器回包：Cache-Control:max-age=600表示文件在本地应该缓存，且有效时长是600秒(从发出请求算起)。在接下来600秒内，如果有请求这个资源，浏览器不会发出HTTP请求，而是直接使用本地缓存的文件。
Last-Modified是标识文件在服务器上的最新更新时间。下次请求时，如果文件缓存过期，浏览器通过If-Modified-Since字段带上这个时间，发送给服务器，由服务器比较时间戳来判断文件是否有修改。如果没有修改，服务器返回304告诉浏览器继续使用缓存;如果有修改，则返回200，同时返回最新的文件。
Cache-Control通常与Last-Modified一起使用。一个用于控制缓存有效时间，一个在缓存失效后，向服务查询是否有更新。
Cache-Control还有一个同功能的字段：Expires。Expires的值一个绝对的时间点，如：Expires:Thu,10Nov201508:45:11GMT，表示在这个时间点之前，缓存都是有效的。
Expires是HTTP1.0标准中的字段，Cache-Control是HTTP1.1标准中新加的字段，功能一样，都是控制缓存的有效时间。当这两个字段同时出现时，Cache-Control是高优化级的。
Etag也是和Last-Modified一样，对文件进行标识的字段。不同的是，Etag的取值是一个对文件进行标识的特征字串。在向服务器查询文件是否有更新时，浏览器通过If-None-Match字段把特征字串发送给服务器，由服务器和文件最新特征字串进行匹配，来判断文件是否有更新。没有更新回包304，有更新回包200。Etag和Last-Modified可根据需求使用一个或两个同时使用。两个同时使用时，只要满足基中一个条件，就认为文件没有更新。
当我们使用webview加载html资源时，本质上就是向服务器索取资源的http请求过程，如果我们不注意资源的缓存策略的话，就可能会造成这样那样的问题，比如：实时性要求较高的功能却老是走缓存不更新，有些基本不会变动的页面却又每次都重新去服务器拉请求。
iOS自带的缓存策略，提供了一个内存和磁盘混合的缓存，一共有7种缓存策略，使用较多的是其中的四种（ 下方编号1，2，5，6 ）
上面介绍了iOS自带的缓存控制 NSURLRequestCachePolicy ，也说到当 NSURLRequestCachePolicy 设为默认的 NSURLRequestUseProtocolCachePolicy 时，主要是根据http的缓存策略来决定是否使用缓存。
那么就简单的介绍一下，http的缓存控制和缓存校验。
在http中，控制缓存开关的字段有两个，Pragma和Cache-Control
Pragma有两个字段no-cache和expires，当pragma为no-cache时表示禁用缓存，expires的值是一个GMT时间，表示该缓存的有效时间。但是已经被逐步抛弃了，有些网站为了向下兼容还保留了这两个字段。
Cache-Control除了在响应中使用，在请求中也可以使用。
在请求中使用，Cache-Control可选的值有：
在响应中使用，Cache-Control可选的值有：
在缓存中，我们需要一个机制来验证缓存是否有效。比如服务器的资源更新了，客户端需要及时刷新缓存；又或者客户端的资源过了有效期，但服务器上的资源还是旧的，此时不需要重新发送。缓存校验就是用来解决这些问题的，在http1.1中，主要关注下 Last-Modified 和 etag 这两个字段。
服务端在返回资源时，会将该资源的最后更改时间通过 Last-Modified 字段返回给客户端。客户端下次请求时通过 If-Modified-Since 或者 If-UnModified-Since 带上 Last-Modified ，服务端检查该时间是否与服务器的最后修改时间一致：如果一致，则返回304状态码，不反悔资源；如果不一致，则返回200和修改后的资源，并带上新的时间。
单纯的以修改时间来判断还是有缺陷，比如文件的最后修改时间变了，但内容没变。对于这样的情况，我们可以使用etag来处理。
etag的方式是这样：服务器通过某个算法对资源进行计算，取得一串值(类似于文件的md5值)，之后将该值通过etag返回给客户端，客户端下次请求时通过If-None-Match或If-Match带上该值，服务器对该值进行对比校验：如果一致则不要返回资源。
当我们的webview缓存到一定的峰值的时候，需要手动的清除一下wenview的缓存，方法如下：
找出web缓存的路径，清空该路径
webKit除了清除缓存的API
觉得有用，请帮忙点亮红心
Better Late Than Never!
努力是为了当机会来临时不会错失机会。
共勉！
最近公司有一个需求，要对webView（UIWebView）实现缓存机制。即在无网条件下，打开webView页面，能读取到网页，有网情况下，缓存未过期也可以使用本地缓存，加快用户读取网页速度。
实现缓存策略的方案有很多，为了保证有效，可控等多方面因素，本文采用NSURLProtocol来实现该需求，它的优势很多，楼主就不再累述了。
关于NSURLProtocol，网上给出了很多资料，但很多方案都有缺陷，包括github上有star的项目，会遇到在特定情况下，网页加载不出来的问题，导致一直显示空白页。本文成功解决了这些问题，目前该项目已在线上稳定运行。
写这篇文章，一方面为了自己，做一些整理，另一方面如果小伙伴，遇到类似需求后，不至于走太多弯路，所谓前人栽树，后人乘凉。废话不多说了，直接上内容。
首先关于URL Loading System
简单来说， URL Loading System 是iOS一系列网络请求类的集合，包括老的NSConnection和现在流行的NSURLSession，还包括一些请求认证的类，一个sessionConfig的类，还有关于处理请求缓存的类等，当然也包括NSURLProtocol类。
当我们需要拦截URL请求时，我们只要通过 - registerClass: 方法注册我们的NSURLProtocol类，然后去重写NSURLProtocol类中的方法，就能对我们发起的请求做处理。
NSURLProtocol 是一个抽象类，所以使用的时候必须定义一个它的子类：
需要拦截URL的控制器中注册该类：
记得在不需要的时候，及时关闭它：
注意一点：如果是基于 NSURLSession 进行的请求，注册的时候需要注册到 NSURLSessionConfiguration 中：
注册成功之后，需要子类CLURLSessionProtocol去实现抽象方法：
+ (BOOL)canInitWithRequest:(NSURLRequest*)request
此处可以拦截需要处理的URL，已经处理过的请求，需要标记请求是否被处理过，防止死循环
+ (NSURLRequest *)canonicalRequestForRequest:(NSURLRequest *)request
这个方法用来统一处理请求 request 对象的，可以修改头信息，或者重定向。没有特殊需要，则直接return request;
如果要在这里做重定向以及头信息的时候注意检查是否已经添加，因为这个方法可能被调用多次，也可以在后面的方法中做。
+ (BOOL)requestIsCacheEquivalent:(NSURLRequest*)a toRequest:(NSURLRequest*)b
判断网络请求是否一致，一致的话使用缓存数据。没需要就调用 super 的方法。
- (void)startLoading
这个方法作用很大，把当前请求的request拦截下来以后，在这个方法里面对这个request做各种处理，比如添加请求头，重定向网络，使用自定义的缓存等。
重点：需要标记已经处理过的 request：
- (void)stopLoading
取消流程
流程图：
首先， SDWebImage 的图片缓存采用的是 Memory (内存) 和 Disk (硬盘) 双重 Cache 机制， SDImageCache 中有一个叫做 memCache 的属性，它是一个 NSCache 对象，用于实现我们对图片的 Memory Cache ，其实就是接受系统的内存警告通知，然后清除掉自身的图片缓存。 Disk Cache ，也就是文件缓存， SDWebImage 会将图片存放到 NSCachesDirectory 目录中，然后为每一个缓存文件生成一个 md5 文件名, 存放到文件中。 整体机制如下：
原文地址
ios内嵌h5页面，从a页面跳转到b页面，b页面设置了缓存，然后走h5的返回，到a页面时，a页面无法获取到缓存
其实并不是a页面拿不到缓存，而是因为ios的缓存机制造成。返回本页面时，页面没有重新请求，所以你拿到的缓存实际是你第一次进入本页面时拿到的缓存值，所以自然无法走得通。
通过windows页面监听，监听页面隐藏显示，当从另一个页面返回时，刷新当前页面即可。
附带一个我用的获取设备类型的方法：checkDevice()吧，有需要自取。