WKWebView 那些坑

作者：林泽水

导语

WKWebView是苹果在WWDC 2014上推出的新一代webView组件，用以替代UIKit中笨重难用、内存泄漏的UIWebView, 拥有60fps滚动刷新率、和safari相同的JavaScript引擎。简单的适配方法就不细说了，本文主要讲述适配WKWebView过程中填过的坑以及善待解决的技术难题。

1、WKWebView白屏问题

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

在一些用webGL渲染的复杂页面，使用WKWebView总体的内存占用（app process memory + other process memory）不见得比UIWebView少很多。在UIWebView上当内存占用太大的时候，app process会crash；而在WKWebView上当总体的内存占用比较大的时候，webContent process会crash，从而出现白屏现象。在WKWebView中加载下面的测试链接可以稳定重现白屏现象:http://people.mozilla.org/~rnewman/fennec/mem.html

这个时候webView.URL会变为nil, 简单的reload刷新操作已经失效，对于一些长驻的H5页面影响比较大。我们最后的解决方案是：

1.1、借助WKNavigtionDelegate

ios 9以后WKNavigtionDelegate新增了一个回调函数：

- (void)webViewWebContentProcessDidTerminate:(WKWebView *)webView API_AVAILABLE(macosx(10.11), ios(9.0)); 当WKWebView总体内存占用过大，页面即将白屏的时候，系统会调用上面的回调函数，我们在该函数里执行[webView reload] (这个时候webView.URL取值尚不为nil)解决白屏问题。在一些高内存消耗的页面可能会频繁刷新当前页面，H5侧也要做相应的适配操作。

1.2、检测webView.title是否为空

并不是所有页面白屏的时候都会调用上面的回调函数，比如，最近遇到在一个高内存消耗的H5页面上present系统相机，拍照完毕后返回原来页面的时候出现白屏现象（拍照过程消耗了大量内存，导致内存紧张，webContent process被系统挂起），但上面的回调函数并没有被调用。在WKWebView白屏的时候，另一种现象是webView.titile会被置空, 因此可以在viewWillAppear的时候检测webView.title是否为空来reload页面。综合以上两种方法可以解决绝大多数的白屏问题。

2、WKWebView Cookie问题

Cookie问题是目前WKWebView的一大短板

2.1、WKWebView Cookie存储

业界普遍认为WKWebView拥有自己的私有存储，不会将Cookie存入到标准的Cookie容器NSHTTPCookieStorage中。实践发现WKWebView实例其实也会将Cookie存储于NSHTTPCookieStorage中，但存储时机有延迟，在iOS8上，当页面跳转的时候，当前页面的Cookie会写入NSHTTPCookieStorage中，而IOS10上，JS执行document.cookie或服务器set-cookie注入的Cookie会很快同步到NSHTTPCookieStorage中，FireFox工程师曾建议通过reset WKProcessPool来触发Cookie同步到NSHTTPCookieStorage中,实践发现不起作用，并可能会引发当前页面session cookie丢失等问题。WKWebView Cookie问题在于WKWebView发起的请求不会自动带上存储于NSHTTPCookieStorage容器中的Cookie。 比如，NSHTTPCookieStorage中存储了一个Cookie: name=Nicholas;value=test;domain=y.qq.com;expires=Sat, 02 May 2009 23:38:25 GMT，通过UIWebView发起请求http://y.qq.com，则请求头会自动带上cookie:Nicholas=test； 而通过WKWebView发起请求 http://y.qq.com，请求头不会自动带上cookie:Nicholas=test。

2.2、WKProcessPool

苹果开发者文档对WKProcessPool的定义是：A WKProcessPool object represents a pool of Web Content process. 通过让所有WKWebView共享同一个WKProcessPool实例，可以实现多个WKWebView之间共享Cookie数据。不过WKWebView WKProcessPool实例在app杀进程重启后会被重置，导致WKProcessPool中的Cookie、session Cookie数据丢失，目前也无法实现WKProcessPool实例本地化保存。

2.3、Workaround

空间的许多H5业务都依赖于Cookie作登录态校验，而WKWebView上请求不会自动携带Cookie, 目前的主要解决方案是：

a、WKWebView loadRequest前，在request header中设置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, 我们通过在request header里带上Cookie解决该请求的Cookie问题，接着页面302跳转到www.b.com, 这个时候www.b.com 这个请求就可能因为没有携带cookie而无法访问。当然，由于每一次页面跳转前都会调用回调函数：

- (void)webView:(WKWebView *)webView decidePolicyForNavigationAction:(WKNavigationAction *)navigationAction decisionHandler:(void (^)(WKNavigationActionPolicy))decisionHandler;

可以在该回调函数里拦截302请求，在request header中带上cookie并重新loadRequest。不过这种方法依然解决不了页面iframe跨域请求的Cookie问题，毕竟-[WKWebView loadRequest:]只适合加载mainFrame请求。

3、WKWebView NSURLProtocol问题

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

+ (void)registerSchemeForCustomProtocol:(NSString *)scheme 通过注册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请求body数据被清空

由于WKWebView在独立进程里执行网络请求。一旦注册http(s) scheme后，网络请求将从network process发送到app process，NSURLProtocol才能拦截网络请求。在webkit2的设计里使用messageQueue进行进程之间的通信，network process会将请求encode成一个Message,然后通过IPC发送给app process。出于性能的原因，encode的时候HTTPBody和HTTPBodyStream这两个字段被丢弃掉了(参考苹果源码：

https://github.com/WebKit/webkit/blob/fe39539b83d28751e86077b173abd5b7872ce3f9/Source/WebKit2/Shared/mac/WebCoreArgumentCodersMac.mm#L71-L80 及bug report: https://bugs.webkit.org/show_bug.cgi?id=138169)。

因此，如果通过registerSchemeForCustomProtocol注册了http(s) scheme, 那么由WKWebView发起的所有http(s)请求都会通过IPC传给主进程NSURLProtocol处理，导致post请求body被清空；

b、对ATS支持不足

测试发现一旦打开ATS开关：Allow Arbitrary Loads 选项设置为NO，同时通过registerSchemeForCustomProtocol注册了http(s) scheme，WKWebView发起的所有http网络请求将被阻塞（即便将Allow Arbitrary Loads in Web Content 选项设置为YES）；

WKWebView可以注册customScheme, 比如dynamic://, 因此希望使用离线功能又不使用post方式的请求可以通过customScheme发起请求，比如dynamic://www.dynamicalbumlocalimage.com/， 然后在app进程NSURLProtocol拦截这个请求并加载离线数据。该方案目前在空间动感影集上实践成功。不足：使用post方式的请求该方案依然不适用，同时需要H5侧修改请求scheme以及CSP规则；

最近了解到QQ浏览器团队已经解决了registerSchemeForCustomProtocol 导致post请求body丢失的问题，并封装在了QBWebView中，也是强大！

4、WKWebView loadRequest问题

在WKWebView上通过loadRequest发起的post请求body数据会丢失：

//同样是由于多进程间通信性能问题，导致HTTPBody字段被丢弃
[request setHTTPMethod:@"POST"];
[request setHTTPBody:[@"bodyData" dataUsingEncoding:NSUTF8StringEncoding]];
[wkwebview loadRequest: request];

workaround: 假如想通过-[WKWebView loadRequest:]加载post请求request1:http://h5.qzone.qq.com/mqzone/index ,可以通过以下步骤实现：

1. 替换请求scheme，生成新的post请求request2: post://h5.qzone.qq.com/mqzone/index, 同时将request1的body字段复制到request2的header中;
2. 通过-[WKWebView loadRequest:]加载新的post请求request2;
3. 通过 +[WKBrowsingContextController registerSchemeForCustomProtocol:]注册scheme: post://;
4. 使用NSURLProtocol拦截请求post://h5.qzone.qq.com/mqzone/index ,替换请求scheme, 生成新的请求request3: http://h5.qzone.qq.com/mqzone/index ，将request2 header的body字段复制到request3的body中，并通过NSURLConnection加载request3，最后将加载结果返回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的值会增加a,导致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. 在接入now直播的时候，我们发现在ios9上WKWebView会出现页面被拉伸变形的情况，最后发现是window.innerHeight值不准确导致（在WKWebView上返回了一个非常大的值），而H5同学通过获取window.innerHeight来设置页面高度，导致页面整体被拉伸。通过查阅相关资料，这个bug只在ios9的几个系统版本上出现，苹果后来fix了这个bug。我们最后的解决方案是：延迟调用window.innerHeight

setTimeout(function(){height = window.innerHeight},0); or

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 string并转换成UIImage。

7、WKWebView crash问题

WKWebView放量后，外网新增了一些crash, 其中一类crash主要堆栈如下：

... 
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(), alert框可能弹不出来，completionHandler最后没有被执行，导致crash；另一种情况是在WKWebView一打开，JS就执行window.alert()，这个时候由于WKWebView所在UIViewController进入（push或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下弹alert框的crash，WKWebView下弹confirm框的crash原因与解决方式与alert类似。

另一个crash发生在WKWebView退出前调用 -[WKWebView evaluateJavaScript:completionHandler:] 执行JS代码的情况下。WKWebView退出并被释放后导致completionHandler变成野指针，而此时javaScript Core还在执行JS代码，待javaScript Core执行完毕后会执行completionHandler，导致crash。这个crash只发生在IOS8系统上，参考apple open source，在IOS9及以后系统苹果已经修复了这个bug,主要是对completionHandler block做了copy（refer: https://trac.webkit.org/changeset/179160）； 对于IOS8系统，可以通过在completionHandler里retain 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。

9、结语

本文总结了那些年和导师seanzhu一起填过的WKWebView的坑。虽然WKWebView坑比较多，但是相对UIWebView在内存消耗、稳定性方面还是有很大的优势。尽管苹果对WKWebView的开发进度过于缓慢，但相信WKWebView才是未来。—>iOS 11 WKWebView 新特性