ios开发缓存机制,ios进程内存限制

ios 应用删掉了为什么webview之前的缓存还存在

浏览器缓存机制是指通过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可根据需求使用一个或两个同时使用。两个同时使用时，只要满足基中一个条件，就认为文件没有更新。

iOS web缓存策略以及手动清除缓存

当我们使用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!

努力是为了当机会来临时不会错失机会。

共勉！

iOS webView利用NSURLProtocol实现离线缓存

最近公司有一个需求，要对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

取消流程

流程图：

iOS面试题：简单的描述一下 SDWebImage的缓存策略？

首先， SDWebImage 的图片缓存采用的是 Memory (内存) 和 Disk (硬盘) 双重 Cache 机制， SDImageCache 中有一个叫做 memCache 的属性，它是一个 NSCache 对象，用于实现我们对图片的 Memory Cache ，其实就是接受系统的内存警告通知，然后清除掉自身的图片缓存。 Disk Cache ，也就是文件缓存， SDWebImage 会将图片存放到 NSCachesDirectory 目录中，然后为每一个缓存文件生成一个 md5 文件名, 存放到文件中。 整体机制如下：

原文地址

ios h5 返回上一页 页面不刷新(ios h5 无法获取缓存)

ios内嵌h5页面，从a页面跳转到b页面，b页面设置了缓存，然后走h5的返回，到a页面时，a页面无法获取到缓存

其实并不是a页面拿不到缓存，而是因为ios的缓存机制造成。返回本页面时，页面没有重新请求，所以你拿到的缓存实际是你第一次进入本页面时拿到的缓存值，所以自然无法走得通。

通过windows页面监听，监听页面隐藏显示，当从另一个页面返回时，刷新当前页面即可。

附带一个我用的获取设备类型的方法：checkDevice()吧，有需要自取。