iOS WKWebview 网页开发适配指南【转】

微信iOS客户端将于2017年3月1日前逐步升级为WKWebview内核，须要网页开发者提早作好网站的兼容检查和适配。若有问题，可参考文末联系方式，向咱们咨询。

背景

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

切换方法

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 。

前端适配关注的要点

适配的首要原则：若不能区分是WKWebview的新特性新行为仍是微信内部逻辑致使原有页面出现问题时，可以使用测试页面分别在Safari和微信中的WKWebview内核分别测试，用以快速定位问题产生的缘由。

适配指南

切换为WKWebview后，微信中的Webview行为和Safari中保持高度一致，惟一的区别是微信Webview中会注入微信JSBridge相关的脚本。因此适配的重点须要关注如下几个方面： 

一：页面功能是否正常 

二：页面屏幕适配是否正常 三：页面行为是否正常（例如用户在浏览页面时点击返回按钮返回上一个页面时的页面逻辑是否正常） 

四：页面使用的语法是否兼容。 

五：JSSAPI是否正常完美的工做。 

六：重点关注Cookie和LocalStorage等相关的逻辑是否正常。 

七：若服务器有设置返回 Cache-Control缓存有效时间，则须要检查相关逻辑是否正常。

 

正常状况下，你的页面是不须要作特别的适配，但若你的页面有涉及到如下几个受影响的逻辑，则须要根据适配建议进行适配和确认。

 

JSAPI相关适配

一：将再也不支持cache 

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

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

 

二：页面经过LocalID预览图片 

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

适配建议：直接将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  ）

 

三：有使用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技术更改页面导航地址的页面彻底没有此类问题，依然须要开发者注意关注此类问题。

 

Cookie和LocalStorage设置相关

一：退出微信帐号后，将会清空全部Cookie和LocalStorage。

 

二：页面功能依赖Cookie，或有涉及到Cookie的相关逻辑 
WKWebview内部实现变动，会影响目前页面Cookie相关的逻辑。

变化1：跨域存取Cookie
问题说明：在访问一个页面A时，若是页面A引用了另外一个页面B的资源（页面A和B为不一样的域名），这时页面B就被认为是第三方页面。若在页面B中设置Cookie，就会命中WKWebview下阻止第三方跨域设置Cookie的安全策略，致使问题出现。
适配建议：
在WKWebview中是默认阻止跨域的第三方设置Cookie。全部经过Cookie传递的信息，可经过业务后台存储须要传递的信息，而后给页面一个存储信息相对应的access_token加密码，再经过Url中加入本身业务的access_token进行页面间的信息传递。

变化2：微信原生层面的网络请求读取不到WKWebview中设置的cookie，即便域名是相同的。
问题说明：若是页面的资源或图片存储的服务器依赖校验Cookie来返回数据的状况，在切换到WKWebview后，在微信内长按保存，或者点击预览大图时，原生层面发起的网络请求将不会完整地带上所设置的Cookie，会致使图片保存失败或预览失败。
适配建议：
建议静态资源cookie free。若是确实有信息须要传递，可经过业务后台存储须要传递的信息，而后给页面一个存储信息相对应的access_token加密码，再经过Url中加入本身业务的access_token进行页面间信息传递。

除上述两种状况，开发者不用担忧其余状况下Cookie丢失的问题，全部请求都会带上完整的Cookie。

 

页面视频小窗播放

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

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

适配建议：须要彻底按照如下代码设置video标签才可同时兼容不一样的iOS版本

<video webkit-playsinline playsinline> </video>

 

WKWebview页面行为与Safari彻底一致，会致使页面依赖UIWebview页面行为的逻辑失效或异常：（可根据业务自身逻辑，实现测试页面后分别在Safari和微信WKWebview中验证）

一：Safari或微信WKWebview中 页面A跳转到页面B再返回页面A后不会从新执行Script和Ajax(也不会触发页面reload)。 

二：Safari或微信WKWebview中，在页面弹出输入键盘后，会触发JQuery的resize事件，而在UIWebView下不会。 

三：Safari或微信WKWebview中， window unload 事件在只有刷新才能触发，退出页面或者跳转到其余页面都没法触发。 

四：Safari或微信WKWebview中，极少数状况下某些特殊实现的页面点击事件会失效。

若是有涉及或者遇到以上问题，以兼容Safari行为为准。

其余问题

一：页面自定义重载标准方法或者函数时，须要确保不会与微信注入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，因此本地找不到数据，此时加载页面就会失败。

 

联系咱们

若是在适配过程当中有任何问题，能够发送邮件到 wx_wkwebview@qq.com 。请提供详细问题说明 ，强烈建议附上问题页面的连接，并告知如何复现大家的问题。