iOS WKWebView设置cookie方法总结

这个问题首先你要明白，WKWebView有自己的进程，使用自己的存储空间来存储cookie和cache，WKWebView会忽视NSURLCache、NSHTTPCookieStorage、NSCredentialStorage这些默认的网络存储， 其他的网络类如NSURLConnection是无法访问到的。 同时WKWebView发起的资源请求也是不经过NSURLProtocol的，导致无法自定义请求。

让WKWebview支持NSURLProtocol可参考： NSURLProtocol对WKWebView的处理

所以这里应该很清楚，NSHTTPCookieStorage已经用不到了，但是你可以把他作为存储cookie到本地的工具使用。我自己的项目里面已经全部删除了它的使用

以我项目为例，这种方法设置的cookie，不能被js读取到，在浏览器调试中也不能看到。所以通过js开发的此方式不可用，但是可以被PHP等动态语言读取，由于我的项目都是用js开发的，故不用此方式，也不做兼容。这里就不做过多的使用介绍。

这种方式不好的地方就是，只能在初始化的时候注入，如果cookie的值发生变化，就需要重新初始化，就变得比较low。所以这种方式的cookie尽量保证他的值是不变的，比如设备号、设备类型、来源等信息。使用方法如下图：

使用起来就比较方便了。如图：

最后可能还会遇到问题，前端获取不到，但是我的cookie确实设置成功了，在safari调试器中可以明确的看到cookie确实设置成功了。我猜想可能是由于cookie设置成功的时机在前端使用cookie值的时机之后造成，也无法解决。

前几天看到一篇文章： 苹果拒绝了16个Web API

说了一堆，总结一下就是苹果觉得cookie不安全。所以cookie中尽量设置一些无关紧要的参数，或者就尽量不去使用。

毕竟cookie这个坑，踩起来难受！！！

个人不推荐使用Cookie！

这都是避免出现Android和iOS出现两种不同的传值方式，测试效果上看性能无优劣，只是一种传值方式而已！！！，且看使用起来是否顺手。

一、可以拼接在地址后面，有加密需要的加密

二、通过JSBridge传值，我自己使用的 WebViewJavascriptBridge， 这种方式需要在页面加载完成之后才会起效。

三、将要传的值添加到NSMutableURLRequest的header内，如图：

WKWebView 是在 Apple 的 WWDC 2014 随 iOS 8 和 OS X 10.10 出来的，是为了解决 UIWebView 加载速度慢、占用内存大的问题。

使用 UIWebView 加载网页的时候，我们会发现内存会无限增长，还有内存泄漏的问题存在。

WebKit 中更新的 WKWebView 控件的新特性与使用方法，它很好的解决了 UIWebView 存在的内存、加载速度等诸多问题。

在性能、稳定性、功能方面有很大提升（最直观的体现就是加载网页是占用的内存）；

允许 JavaScript 的 Nitro 库加载并使用（ UIWebView 中限制）；

支持了更多的 HTML5 特性；

高达 60fps 的滚动刷新率以及内置手势；

将 UIWebViewDelegate 与 UIWebView 重构成了14类与3个协议 查看苹果官方文档 ；

简单使用，直接加载url地址

自定义配置

再 WKWebView 里面注册供 JS 调用的方法，是通过 WKUserContentController 类下面的方法：

实现 WKScriptMessageHandler 协议方法

注意：上面将当前 ViewController 设置为 MessageHandler 之后需要在当前 ViewController 销毁前将其移除，否则会造成内存泄漏。

如果实现了代理方法，一定要在 decidePolicyForNavigationAction 和 decidePolicyForNavigationResponse 方法中的回调设置允许跳转。

---