WKWebview相关知识点记录

背景

WKWebView 是苹果在iOS 8中引入的新组件，目的是提供一个现代的支持最新Webkit功能的网页浏览控件，摆脱过去 UIWebView的老、旧、笨，特别是内存占用量巨大的问题。它使用与Safari中一样的Nitro JavaScript引擎，大大提高了页面js执行速度。

也就是说WKWebview是针对IOS端的手机浏览器内核，本来这不关我们什么事儿的，但是问题在于微信iOS客户端将于2017年3月1日前逐步升级为WKWebview内核，所以此文章的目的是列出WKWebview内核兼容性相关的知识点，以及教大家如何调试发现问题所在，让微信的这次浏览器内核升级能够最大限度的降低对我们原有项目的影响。

切换方法

iOS微信6.5.3版本开始支持开发者手动切换WKWebview和UIWebview，使开发者可提前对WKWebview进行适配。

手动切换入口：

在微信会话列表页点击右上角“加号按钮”，选择菜单中的”添加朋友”，在添加朋友界面的搜索框中输入字符串：“:switchweb”，再点击键盘右下角搜索按钮。切换成功后会提示当前使用的内核是UIWebview或是WKWebview。

校验切换方法：

通过命令成功切换到WKWebview后，可通过以下方法验证当前网页使用的是否是WKWebview内核。 

微信内任意入口进入任意网页，在网页加载成功后向下拉动页面（或点击网页右上角菜单按钮），使之显示出地址栏，当地址栏以 “此网页由” 开头即为当前使用WKWebview，若以“网页由”则是使用的UIWebview。

页面如何判断当前使用的webview内核：

在页面中可通过微信注入的window.__wxjs_is_wkwebview变量判断当前使用的webview内核。 iOS微信6.5.3及其之后的版本 window.__wxjs_is_wkwebview 为true时是使用WKWebview，为 false或者 “undefine”时是 UIWebview 。

以上就是手动切换新内核的方法和检查新内核的方法，在手机上很简单就能够完成。

然后以下便是兼容性方面的重点：

一：将不再支持cache 

变化：在WKWebview中将暂不支持cache jsapi。 

适配建议：所有使用此api的开发者可去掉页面相关逻辑。

总结：有使用的就必须换掉。因为此内核是直接不支持cache jsapi的。而没有使用的则不受影响。

二：页面通过LocalID预览图片 

变化：不再支持通过使用chooseImage api返回的localld以如：”img src=wxLocalResource://50114659201332”的方式预览图片。 

适配建议：

1. 在iOS微信6.5.3版本及之后的版本中，使用新增的jsapi：getLocalImgData 拿到LocalID对应的图片base64编码后再在前端页面中显示。

2. 如果引入了页面有引入JSSDK，则直接将JSSDK升级为1.2.0最新版本即可帮助页面自动适配。（目前JSSDk线上版本是 1.0.0 和 1.1.0，更新版本为1.2.0 ，https://res.wx.qq.com/open/js/jweixin-1.2.0.js  ）

总结：以chooseImage方法预览图片的通通改成getLocalImgData方法就可以了，当然系统上有引入jssdk的话升级也可以自动解决。

三：有使用JSSDK，并且使用了wx.config进行权限授权需关注jsapi调用的失败问题 

变化：WKWebview的内部实现变更使我们对微信内的页面jsapi权限管理做了一定逻辑上的调整，有极小可能会发生以前授权正常的jsapi获取权限不正常，从而导致调用jsapi失败。 

适配建议：

1. iOS微信6.5.1，WKWebview在此版本中已知有以下问题：页面使用HTML5的History API pushState; popstate;      replaceState等控制页面导航（典型的如单应用页面），同时使用JSSDK的wx.config为jsapi授权，此时大几率会出现jsapi因为无权限而调用失败的问题。 在6.5.1中页面若可能的情况下，可使用Anchor hash技术替换History技术来解决此问题。

2. iOS微信6.5.2及其之后版本，将不会存在以上问题，但不能100%确认有使用到 history或hash技术更改页面导航地址的页面完全没有此类问题，依然需要开发者注意关注此类问题。

总结：此问题属于出现概率很小的事件，如果出现了，要么就叫用户升级微信版本，要么就放弃使用H5的History API。

Cookie和LocalStorage设置相关

一：退出微信账号后，将会清空所有Cookie和LocalStorage。

二：页面功能依赖Cookie，或有涉及到Cookie的相关逻辑 

变化：WKWebview内部实现变更，会影响目前页面Cookie相关的逻辑，例如跨域存取Cookie和页面的资源或图片存储服务器依赖校验Cookie来返回数据等情况。

问题说明：在访问一个页面A时，如果页面A引用了另一个页面B的资源（页面A和B为不同的域名），这时页面B就认为是第三方页面。若在页面B中设置Cookie，就会命中WKWebview下阻止第三方跨域设置Cookie的安全策略，导致问题出现。

适配建议：

在WKWebview中是默认阻止跨域的第三方设置Cookie。所有通过Cookie传递的信息，可通过业务后台存储需要传递的信息，然后给页面一个存储信息相对应的access_token加密码，然后通过Url中加入自己业务的access_token进行页面间信息传递。

如果页面的资源或图片存储的服务器依赖校验Cookie来返回数据的情况，在切换到WKWebview后，在微信内长按保存，或者点击预览大图时，将不会完整的带上所设置的Cookie，会导致图片保存失败或预览失败。除了此种情况，开发者不用担心其他情况下Cookie丢失的问题，所有请求都会带上完整的Cookie。

总结：退出微信账号所引发的清空cookie和localstorage是没有办法避免的，不用管，知道就好。而引用第三方页面资源时候，我们就不应该在第三方页面上设置COOKIE，这样会导致错误而且的确也不安全。凡是这种传递参数的方法，都需要修正。

页面视频小窗播放

变化：iOS微信6.5.3及其之后的版本中，Webview默认支持小窗播放。 

开发者需要特别注意小窗播放需要前端同时适配iOS10和iOS10以下的低版本 

适配建议：需要完全按照以下代码设置video标签才可同时兼容不同的iOS版本

<video webkit-playsinline playsinline></video>

总结：加就是了，不用怀疑。

其他问题

一：页面自定义重载标准方法或者函数时，需要确保不会与微信注入Webview中的JSBridge相关方法冲突，否则会导致页面在微信中的行为异常。

二：强烈建议不要在无法确保页面缓存策略和逻辑与服务器逻辑完全保持一致的情况下冒然设置html页面文件(除了html类型的页面，页面引用的其他资源或脚本按照自身业务合理设置即可)相关的Cache-Control属性。 

典型案例： 

如果第一次访问页面A.html 服务器302跳转到A1.html?uid=111设置Cache-Control: max-age=60，此A1.html的uid参数是服务器设置的111（此时A1.html已经被客户端缓存）。 第二次访问页面A.html ，服务器同样302跳转到A1.html?uid=222，但是此时的A1.html页面的uid参数是222， 客户端带参数完整链接询问服务器缓存是否可用， 服务器返回缓存可用304，但是客户端缓存的A1.html完整链接带的uid参数是111，所以本地找不到数据，此时加载页面就会失败。

总结：问题一基本可以确保，因为自定义的方法和函数冲突的话会报错，一般都容易排查，问题二则比较难排查，所以不能随意添加cache-control属性,这点需要确保。（当然我们常用的是no-cache模式，一般不产生缓存）