iosuiwebview清除缓存
① 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-关于WebView在长时间使用下的卡顿现象测试
我的手机里常驻浏览器是海豚，最近在使用的时候发现出现卡顿现象，让使用体验变得非常不爽，大过年的闲来无聊就做了点测试。
症状：当一个WebView在重复打开达数十次甚至上百次时整个页面在滑动时会出现非常明显的卡顿现象。
解决方法：将WebView销毁，重新创建一个即可消除卡顿，除此之外刷新WebView亦或是其他方法都无法消除卡顿。
为了了解其实际情况，我制作了一个简单的Demo，通过Xcode相关工具实际检验来确定卡顿缘由。
我简单地创建了一个对照组，分别是UIWebView以及WKWebView制作的简易浏览器。
最开始我的想法是大量加载界面造成的卡顿可能是Safari内核的问题，UIWebView及WKWebView在大量重复加载后可能都会出现卡顿现象，总不可能海豚浏览器还是在使用UIWebViewd吧哈哈哈……哈哈……哈……
在实验结束后我开始不确定是我的检验手法出现问题还是海豚V9.3.0版本是使用UIWebView搭建的，本来我恶意地猜测是Safari内核有问题或者在WebView内部做了某些限制，在WebView大量重复使用后会限制什么东西，结果没想到最大的可能居然只是UIWebView的问题，真是索然无味。
两个对照组使用同样的样本进行测试，测试设备为iPhone5S，版本为9.3.2，测试样本为一本网络小说的前200章。
初始状态：
以上两张分别是UIWebView在初始状态下默认加载小说首页时静止状态与滑动状态下的资源利用率，可以发现CPU占用不高，此时界面也属于流畅状态。
以上两张分别是WKWebView的静止状态及滑动状态的资源占有率，不得不说苹果对WKKit的优化做足了心，内存占有根本不是一个级别的。
我们在WK的滑动图可以看出，此时两者在滑动状态下的CPU使用率是相近的，而实际上两者在初始状态下滑动手感也并无差别。
五十章节后：
可以看到，UIWebView的内存占用减少了，这是因为进入章节界面后图片的减少，之后的数据中内存占用大多保持在这一程度左右。而CPU在滑动状态下的占用率则是大大提升，并且峰值可以达到40%左右。
而相对的，WKWebView的占用率并没有明显提升。
此时，UIWebView的网页已经可以感觉到少许的卡顿。
一百章节后：
UIWebView的界面已造成明显卡顿现象，同时，CPU的占用率在滑动状态下也达到50%以上（测试下峰值曾达到80%以上）
WK淡定地表示再来一百章。
两百章后：
UIWebView因为疯狂卡顿导致Demo 页面长时间凝滞，无法测试。
而此时WK依旧淡定。
结论：Just Fuck UIWebView.出现的卡顿现象只是UIWebView自身缺陷导致的CPU使用量暴增从而造成的卡顿，在不清楚苹果在当初设计UIWebView的时候做了什么而在WKKit中又修改了什么东西弥补了这部分缺陷的情况下这只是又一次老生常谈，告诉大家抛弃UIWebView投向WKKit的怀抱。
③ wkwebview的缓存设置策略
对于iOS8之后新推出的WKWebView还是有显着的有点相对于传统的UIWebView; 但是对于一些网页的缓存策略就比较苍白了，尽管UIWebView已经有很有的缓存设置策略了，但是对于刚推出的WKWbeView并没有设置缓存的功能；
UIWebView设置缓存的方法：
不过自iOS9之后WKWebView缓存设置的API才正式推出：
types是指存在指定缓存类型的一个集合，包括：
④ 解决UIWebView内存占用过高
iOS8以上使用WKWebView。。需要支持iOS7,这就必须要UIWebview和WKWebview的混合使用，这里讲一下怎么解决UIWebView内存问题
首先你在APPDelagate,改变缓存策略,使他到达你设定的值后,进行强制内存回收,这样做还有一个好处就是提高网页加载速度
然后在页面消失的时候,强制把webview的delegate设置为nil，并清除缓存
⑤ ios webview的cookie怎么清楚
UIWebView清除Cookie：
//清除cookies
NSHTTPCookie *cookie;
NSHTTPCookieStorage *storage = [NSHTTPCookieStorage sharedHTTPCookieStorage];
for (cookie in [storage cookies])
{
[storage deleteCookie:cookie];
}
UIWebView清除缓存：
//清除UIWebView的缓存
[[NSURLCachesharedURLCache] removeAllCachedResponses];
NSURLCache * cache = [NSURLCache sharedURLCache];
[cache removeAllCachedResponses];
[cache setDiskCapacity:0];
[cache setMemoryCapacity:0];
⑥ ios前端有缓存
ios前端有缓存的解决方法：
1.此时在ios app的沙盒文件中将保存好已经缓存的文件，如果此时没有退出APP,那么缓存的内容同时也会保存在内存中；如下图（此处针对的UIWebView）
2.此时可以看到这Caches文件中，后面的Paul.H5下面多了Cache.db的数据库，打开数据库可以看到以下内容；注意 此时的图片资源也是保存在Paul.H5下面的文件中
⑦ UIWebView怎么设置缓存
UIWebView可以看一下sdk，之前做过的浏览器都是用哈希表来缓存的。
⑧ 请问清除UIWebView的缓存
设置程序清空
⑨ 如何解决 UIWebview 内存泄漏
解决的第一个步骤就是无缝切换到wkwebview：
我动手封装了一下，识别了一下iOS的版本，IOS8+的就切换到wkwebview。
没想到这么一切换，出了问题。（切换wkwebview的注意点）“AController中的wkwebview” 和 “BController中的wkwebview”的localstorage信息不一致。
什么意思呢，就是在B中保存了数据，回到A中，数据没同步到。
貌似真的无解.....
只能一个个API查看（怎么查看？）
后来发现一个东西有点可疑wkwebviewconfiguration。（configuration）
其中有一个值，processPool，描述是：The process pool from which to obtain the view’s Web Content process.
再搜了一下，stackoverflow上有关于的cookie的问答刚好和这个有关，处理方法是将config中的processPool变为单例。
然后我也弄成单例，然后问题就解决了。
然后IOS7怎么办？
解决的第二个步骤是检查是否存在循环引用。
哈哈，我也是切换过去才知道原来内存泄漏是有解的。
最初也是试了一轮网上的方案，然后都没什么用。
就在我尽人事听天命的时候，我在controller退出的时候，手动置空了所有引用。在页面返回的时候强制清了一轮缓存
[plain] view plain
NSUserDefaults.standardUserDefaults().setInteger(0, forKey: "WebKitCacheModelPreferenceKey")
NSUserDefaults.standardUserDefaults().synchronize()
然后再去看内存，还是会增长，不过已经平和了很多，页面返回内存也会降低回去。