1.WKWebView白屏问题
WKWebView自我拥有更快的加载速度，更低的内存占用，但实际上WKWebView是一个多进程组件，网络加载以及UI渲染在其它进程中执行。初次适配WKWebView的时候，我们也惊讶于打开WKWebView其他进程的内存占用会增加。在一些用于webGL渲染的复杂页面比UIWebView少很多。
在UIWebView上当内存占用太大的时候，App Process会崩溃;而在WKWebView上当总体的内存占用比较大的时候，WebContent Process会崩溃，从而出现白屏现象。在WKWebView中加载下面的测试链接可以稳定重现白屏现象：
这个时候WKWebView.URL会变为nil，简单的reload刷新操作已经失效，对于一些长驻的H5页面影响比较大。
我们最后的解决方案是：
A 借助WKNavigtionDelegate
iOS 9以后WKNavigtionDelegate新增了一个回调函数：
- (void)webViewWebContentProcessDidTerminate:(WKWebView *)webView API_AVAILABLE(macosx(10.11), ios(9.0));
当WKWebView总体内存占用过大，页面即将白屏的时候，系统会调用上面的回调函数，我们在该函数里执行[webView reload]（这个时候webView.URL取值尚不为零）解决白屏问题。在一些高内存消耗的页面可能会频繁刷新当前页面，H5侧也要做相应的适配操作。
B 检测webView.title是否为空
并不是所有H5页面白屏的时候都会调用上面的回调函数，比如，最近遇到在一个高内存消耗的H5页面上现在系统相机，拍照完毕后返回原来页面的时候出现白屏现象（拍照过程消耗了解大量内存，导致内存紧张，WebContent Process被系统挂起），但上面的回调函数并没有被调用。在WKWebView白屏的时候，另一种现象是webView.titile会被置空，因此，可以在viewWillAppear的时候检测webView.title是否为空来重装页面。
综合以上两种方法可以解决绝大多数的白屏问题。
2 WKWebView Cookie问题
Cookie问题是目前WKWebView的一大短板
2.1 WKWebView Cookie存储
业界普遍认为WKWebView拥有自己的私有存储，不会将Cookie存储到标准的Cookie容器NSHTTPCookieStorage中。
实践发现WKWebView实例其实也会将Cookie存储于NSHTTPCookieStorage中，但存储时机有延迟，在iOS 8上，当页面跳转的时候，当前页面的Cookie会写入NSHTTPCookieStorage中，而在iOS 10上，JS执行document.cookie或服务器set-cookie注入的Cookie会很快同步到NSHTTPCookieStorage中，FireFox工程师曾建议通过重置WKProcessPool来触发Cookie同步到NSHTTPCookieStorage中，实践发现不起作用，并可能会引发当前页面会话cookie丢失等问题。
WKWebView Cookie问题在于WKWebView发起的请求不会自动带上存储于NSHTTPCookieStorage容器中的Cookie。
比如，NSHTTPCookieStorage中存储了一个Cookie：
name=Nicholas;value=test;domain=y.qq.com;expires=Sat, 02 May 2019 23:38:25 GMT；
通过UIWebView发起请求http://y.qq.com，则请求头会自动带上cookie：Nicholas = test;
而通过WKWebView发起请求http://y.qq.com，请求头不会自动带上cookie ：尼古拉斯=测试。
2.2 WKProcessPool
苹果开发者文档对WKProcessPool的定义是：WKProcessPool对象代表一个Web Content进程池。通过让所有WKWebView共享同一个WKProcessPool实例，可以实现多个WKWebView之间共享Cookie（会话Cookie和持久Cookie）数据。不过WKWebView WKProcessPool实例在app杀进程重启后会被重置，导致WKProcessPool中的Cookie，session Cookie数据丢失，目前也无法实现WKProcessPool实例本地化保存。
2.3 解决方法
由于许多H5业务都依赖于Cookie作登录态校验，而WKWebView上请求不会自动携带Cookie，目前的主要解决方案是：
a WKWebView loadRequest前，在请求头中设置Cookie，解决首个请求Cookie带不上的问题;
WKWebView * webView = [WKWebView new]; NSMutableURLRequest * request = [NSMutableURLRequest requestWithURL:[NSURL URLWithString:@"http://h5.qzone.qq.com/mqzone/index"]];
[request addValue:@"skey=skeyValue" forHTTPHeaderField:@"Cookie"]; [webView loadRequest:request];
b 通过document.cookie设置Cookie解决后续页面（同域）Ajax，iframe请求的Cookie问题;
注意：document.cookie()无法跨域设置 cookie
WKUserContentController* userContentController = [WKUserContentController new]; WKUserScript * cookieScript = [[WKUserScript alloc] initWithSource: @"document.cookie = 'skey=skeyValue';" injectionTime:WKUserScriptInjectionTimeAtDocumentStart forMainFrameOnly:NO];
[userContentController addUserScript:cookieScript];
这请方案无法解决302请求的Cookie问题，比如，第一个请求是www.a.com，我们通过请求标题里带上Cookie解决该请求的Cookie问题，接着页面302跳转到www.b.com ，这个时候www.b.com这个请求就可能因为没有携带cookie而无法访问。当然，由于每一次页面跳转前都会调用回调函数：
- (void)webView:(WKWebView *)webView decidePolicyForNavigationAction:(WKNavigationAction *)navigationAction decisionHandler:(void (^)(WKNavigationActionPolicy))decisionHandler;
可以在该回调函数里拦截302请求，复制请求，在请求标题中带上cookie并重新加载请求。不过这种方法依然解决不知页面iframe跨域请求的Cookie问题，毕竟 - [WKWebView loadRequest：]只适合加载mainFrame请求。
3 WKWebView NSURLProtocol问题
WKWebView在独立于app进程之外的进程中执行网络请求，请求数据不经过主进程，因此，在WKWebView上直接使用NSURLProtocol无法拦截请求。苹果开源的webKit2源码暴露了私有API：
+ [WKBrowsingContextController registerSchemeForCustomProtocol:]
通过注册http（s）scheme WKWebView将可以使用NSURLProtocol渗截http（s）请求：
Class cls = NSClassFromString(@"WKBrowsingContextController”);
SEL sel = NSSelectorFromString(@"registerSchemeForCustomProtocol:");
if ([(id)cls respondsToSelector:sel]) {
// 注册http(s) scheme, 把 http和https请求交给 NSURLProtocol处理
[(id)cls performSelector:sel withObject:@"http"];
[(id)cls performSelector:sel withObject:@"https"];
}
但是这种方案目前存在两个严重缺陷：
a post请求身体数据被清空
由于WKWebView在独立进程里执行网络请求。一旦注册http（s）scheme后，网络请求将从网络流程发送到App Process，这样NSURLProtocol才能拦截网络请求。在webkit2的设计里使用MessageQueue进行进程之间的通信，网络进程会求请求编码成一个消息，然后通过IPC发送给App Process。出于性能的原因，编码的时候HTTPBody和HTTPBodyStream这两个字段被丢弃掉了
参考苹果源码：
及bug报告：
https://bugs.webkit.org/show_bug.cgi?id=138169
因此，如果通过registerSchemeForCustomProtocol注册了http（s）scheme，那么由WKWebView发起的所有http（s）请求都会通过IPC传给主进程NSURLProtocol处理，导致post请求body被清空 ;
B 对ATS支持不足
测试发现一旦打开ATS开关：允许任意加载选项设置为NO，同时通过registerSchemeForCustomProtocol注册了http（s）方案，WKWebView发起的所有http网络请求将被阻塞（即便将允许Web内容中的任意加载选项设置为YES） ;
WKWebView可以注册customScheme，比如动态：//，因此希望使用离线功能又不使用交方式的请求可以通过customScheme发起请求，比如动态：//www.dynamicalbumlocalimage.com/，然后在应用程序进程NSURLProtocol拦截这个请求并加载离线数据。不足：使用post方式的请求该方案依然不适用，同时需要H5侧修改请求方案以及CSP规则;
4 WKWebView loadRequest问题
在WKWebView上通过loadRequest发起的post请求body数据会丢失：
//同样是由于进程间通信性能问题，HTTPBody字段被丢弃[request setHTTPMethod:@"POST"];
[request setHTTPBody:[@"bodyData" dataUsingEncoding:NSUTF8StringEncoding]];
[wkwebview loadRequest: request];
解决方法：
假如想通过 - [WKWebView loadRequest：]加载帖请求请求1：http：//h5.qzone.qq.com/mqzone/index ，可以通过以下步骤实现：
替换请求scheme，生成新的post请求request2：post：//h5.qzone.qq.com/mqzone/index，同时将request1的body字段复制到request2的header中（WebKit不会丢弃header字段）;
通过 - [WKWebView loadRequest：]加载新的post请求request2;
通过+ [WKBrowsingContextController registerSchemeForCustomProtocol：]注册方案：post：// ;
注册NSURLProtocol拦截请求帖子：//h5.qzone.qq.com/mqzone/index，替换请求方案，生成新的请求request3：http：//h5.qzone.qq.com/mqzone/index ，将request2 header的body字段复制到request3的body中，并使用NSURLConnection加载request3，最后通过NSURLProtocolClient将加载结果返回WKWebView;
5 WKWebView页面样式问题
在WKWebView适配过程中，我们发现部分H5页面元素位置向下偏移或被拉伸变形，追踪后发现主要是H5页面高度值异常导致：
a 空间H5页面有透明导航，透明导航下拉刷新，全屏等需求，因此之前webView整个是从（0,0）开始布局，通过调整webView.scrollView.contentInset来适配特殊导航栏需求。而在WKWebView上对contentInset的调整会反馈到webView.scrollView.contentSize.height的变化上，比如设置webView.scrollView.contentInset.top = a，那么contentSize.height的值会增加一，导致H5页面长度增加，页面元素位置向下偏移;
解决方案是：调整WKWebView布局方式，避免调整webView.scrollView.contentInset。实际上，即便在UIWebView上也不建议直接调整webView.scrollView.contentInset的值，这确实会带来一些奇怪的问题。如果某些特殊情况下非得调整contentInset不可的话，可以通过下面方式让H5页面恢复正常显示：
/**设置contentInset值后通过调整webView.frame让页面恢复正常显示
*参考：http://km.oa.com/articles/show/277372
*/ webView.scrollView.contentInset = UIEdgeInsetsMake(a, 0, 0, 0);
webView.frame = CGRectMake(webView.frame.origin.x, webView.frame.origin.y, webView.frame.size.width, webView.frame.size.height - a);
b 在接入现在直播的时候，我们发现在iOS 9上WKWebView会出现页面被拉伸变形的情况，最后发现是window.innerHeight值不准确导致（在WKWebView上返回了一个非常大的值），而H5同学通过获取window.innerHeight来设置页面高度，导致页面整体被拉伸。通过查阅相关资料发现，这个bug只在iOS 9的几个系统版本上出现，苹果后来修复了这个bug。我们最后的解决方案是：延迟调用窗口。 innerHeight
setTimeout(function(){height = window.innerHeight},0);
要么
Use shrink-to-fit meta-tag
<meta name="viewport" content="width=device-width, initial-scale=1.0, user-scalable=no, maximum-scale=1, shrink-to-fit=no">
6 WKWebView截屏问题
空间玩吧H5小游戏有截屏分享的功能，WKWebView下通过 - [CALayer renderInContext：]实现截屏的方式失效，需要通过以下方式实现截屏功能：
@implementation UIView (ImageSnapshot)
- (UIImage*)imageSnapshot {
UIGraphicsBeginImageContextWithOptions(self.bounds.size,YES,self.contentScaleFactor);
[self drawViewHierarchyInRect:self.bounds afterScreenUpdates:YES];
UIImage* newImage = UIGraphicsGetImageFromCurrentImageContext();
UIGraphicsEndImageContext();
return newImage;
}
@end
然而这种方式依然解决不了webGL页面的截屏问题，笔者已经翻译苹果文档，研究过webKit2源码里的截屏私有API，依然没有找到合适的解决方案，同时发现Safari以及Chrome这两个全量切换到WKWebView的浏览器也存在同样的问题：对webGL页面的截屏结果不是空白就是纯黑图片。无奈之下，我们只能约定一个JS接口，让游戏开发商实现该接口，具体是通过canvas getImageData()方法取得图片数据后返回base64格式的数据，客户端在需要截图的时候，调用这个JS接口获取base64字符串并转换成UIImage。
7 WKWebView崩溃问题
WKWebView放量后，外网新增了一些崩溃，其中一类崩溃的主要堆栈如下：
...
28 UIKit 0x0000000190513360 UIApplicationMain + 208 29 Qzone 0x0000000101380570 main (main.m:181)
30 libdyld.dylib 0x00000001895205b8 _dyld_process_info_notify_release + 36 Completion handler passed to -[QZWebController webView:runJavaScriptAlertPanelWithMessage:initiatedByFrame:completionHandler:] was not called
主要是JS调用window.alert()函数引起的，从crash堆栈可以看出是WKWebView回调函数：
+ (void) presentAlertOnController:(nonnull UIViewController*)parentController title:(nullable NSString*)title message:(nullable NSString *)message handler:(nonnull void (^)())completionHandler;
completionHandler没有被调用导致的。在适配WKWebView的时候，我们需要自己实现该回调函数，window.alert()才能调起alert框，我们最初的实现是这样的：
- (void)webView:(WKWebView *)webView runJavaScriptAlertPanelWithMessage:(NSString *)message initiatedByFrame:(WKFrameInfo *)frame completionHandler:(void (^)(void))completionHandler
{
UIAlertController *alertController = [UIAlertController alertControllerWithTitle:@"" message:message preferredStyle:UIAlertControllerStyleAlert];
[alertController addAction:[UIAlertAction actionWithTitle:@"确认" style:UIAlertActionStyleCancel handler:^(UIAlertAction *action) { completionHandler(); }]];
[self presentViewController:alertController animated:YES completion:^{}];
}
如果WKWebView退出的时候，JS刚好执行window.alert()，alertHandler最后没有被执行，导致崩溃;另一种情况是在WKWebView一打开，JS就执行window.alert()，这个时候由于WKWebView所在的UIViewController出现（ push or present）的动画尚未结束，alert框可能弹不出来，completionHandler最后没有被执行，导致crash。我们最终的实现大致是这样的：
- (void)webView:(WKWebView *)webView runJavaScriptAlertPanelWithMessage:(NSString *)message initiatedByFrame:(WKFrameInfo *)frame completionHandler:(void (^)(void))completionHandler
{
if (/*UIViewController of WKWebView has finish push or present animation*/) {
completionHandler();
return;
}
UIAlertController *alertController = [UIAlertController alertControllerWithTitle:@"" message:message preferredStyle:UIAlertControllerStyleAlert];
[alertController addAction:[UIAlertAction actionWithTitle:@"确认" style:UIAlertActionStyleCancel handler:^(UIAlertAction *action) { completionHandler(); }]];
if (/*UIViewController of WKWebView is visible*/)
[self presentViewController:alertController animated:YES completion:^{}];
else
completionHandler();
}
确保上面两种情况下completionHandler都能被执行，消除了WKWebView下弹警报框的崩溃，WKWebView下弹确认框的崩溃的原因与解决方式和警类类似。
另一个crash发生在WKWebView退出前调用：
-[WKWebView evaluateJavaScript: completionHandler:]
执行JS代码的情况下.WKWebView退出并被释放后导致completionHandler变成野指针，而此时javaScript核心还在执行JS代码，待javaScript核心执行完毕后会调用completionHandler()，导致崩溃。这个崩溃只发生在iOS 8系统上，参考Apple Open Source，在iOS9及以后系统苹果已经修复了这个bug，主要是对completionHandler block做了copy（参考：https：//trac.webkit.org/changeset/179160 ）;对于iOS 8系统，可以通过在completionHandler里保留WKWebView防止completionHandler被过早释放。我们最后用methodSwizzle hook了这个系统方法：
+ (void) load
{
[self jr_swizzleMethod:NSSelectorFromString(@"evaluateJavaScript:completionHandler:") withMethod:@selector(altEvaluateJavaScript:completionHandler:) error:nil];
}
/*
* fix: WKWebView crashes on deallocation if it has pending JavaScript evaluation
*/ - (void)altEvaluateJavaScript:(NSString *)javaScriptString completionHandler:(void (^)(id, NSError *))completionHandler
{
id strongSelf = self;
[self altEvaluateJavaScript:javaScriptString completionHandler:^(id r, NSError *e) {
[strongSelf title];
if (completionHandler) {
completionHandler(r, e);
}
}];
}
8 其它问题
8.1 视频自动播放
WKWebView需要通过WKWebViewConfiguration.mediaPlaybackRequiresUserAction设置是否允许自动播放，但一定要在WKWebView初始化之前设置，在WKWebView初始化之后设置无效。
8.2 goBack API问题
WKWebView上调用 - [WKWebView goBack]，回退到上一个页面后不会触发window.onload()函数，不会执行JS。
8.3 页面滚动速率
WKWebView需要通过scrollView delegate调整滚动速率：
- (void)scrollViewWillBeginDragging:(UIScrollView *)scrollView {
scrollView.decelerationRate = UIScrollViewDecelerationRateNormal;
}
