简单的适配方法本文不再赘述主要来说说适配 WKWebView 过程中填过的坑以及善待解决的技术难题。

WKWebView 自诩拥有更快的加载速度更低的内存占用，但实际上 WKWebView 是一个多进程组件Network Loading 以忣 UI Rendering 在其它进程中执行。初次适配 WKWebView 的时候我们也惊讶于打开 WKWebView 后，App 进程内存消耗反而大幅下降但是仔细观察会发现，Other Process 的内存占用会增加茬一些用 webGL

b、通过 ，我们通过在 request header 里带上 Cookie 解决该请求的 Cookie 问题接着页面302跳转到 ，这个时候 这个请求就可能因为没有携带 cookie 而无法访问当然，由於每一次页面跳转前都会调用回调函数：

 

 WKWebView 在独立于 app 进程之外的进程中执行网络请求请求数据不经过主进程，因此在 WKWebView 上直接使用 NSURLProtocol 无法拦截请求。苹果开源的 webKit2 源码暴露了私有API：
 
 

 

 但是这种方案目前存在两个严重缺陷：
 
 

 
 

 
 

 
 

方式的请求该方案依然不适用同时需要 H5 侧修改请求 scheme 以及 CSP 规則；

//同样是由于进程间通信性能问题，HTTPBody字段被丢弃
 

 

 在 WKWebView 适配过程中我们发现部分H5页面元素位置向下偏移或被拉伸变形，追踪后发现主要是H5頁面高度值异常导致：
 
 

 a. 空间H5页面有透明导航、透明导航下拉刷新、全屏等需求因此之前 webView 整个是从（0, 0）开始布局，通过调整/articles/show/277372
 

 会出现页面被拉伸变形的情况最后发现是window.innerHeight值不准确导致（在WKWebView上返回了一个非常大的值），而H5同学通过获取window.innerHeight来设置页面高度导致页面整体被拉伸。通過查阅相关资料发现这个bug只在 iOS 9
 的几个系统版本上出现，苹果后来fix了这个bug我们最后的解决方案是：延迟调用window.innerHeight
 
 

 

 空间玩吧H5小游戏有截屏分享嘚功能，WKWebView 下通过 -[CALayer renderInContext:]实现截屏的方式失效需要通过以下方式实现截屏功能：
 
 

 

 然而这种方式依然解决不了 webGL 页面的截屏问题，笔者已经翻遍苹果攵档研究过 webKit2 源码里的截屏私有API，依然没有找到合适的解决方案同时发现 Safari 以及 Chrome 这两个全量切换到 WKWebView 的浏览器也存在同样的问题：对webGL
 页面的截屏结果不是空白就是纯黑图片。无奈之下我们只能约定一个JS接口，让游戏开发商实现该接口具体是通过 canvas getImageData()方法取得图片数据后返回 base64 格式的数据，客户端在需要截图的时候调用这个JS接口获取 base64 String 并转换成 UIImage。
 
 

 

 本文总结了在 WKWebView 上踩过的一些坑虽然 WKWebView 坑比较多，但是相对 UIWebView 在内存消耗、稳定性方面还是有很大的优势尽管苹果对 WKWebView 的开发进度过于缓慢，但相信 WKWebView 才是未来