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 新特性

原创声明,本文系作者授权云+社区-专栏发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

编辑于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏吉浦迅科技

Jetson TX1首发评测

NVIDIA嵌入式开发板家族迎来了新成员——Jetson TX1。这个新的开发模组旨在针对机器人、无人飞机等应用。在这个设计紧凑的,只有50mmx90mm的Je...

2918
来自专栏编程

极客手工:自制51四驱无线遥控小车

遥控小车大家应该都玩过,网上也有各种DIY小车的制作详解。我做的这个遥控小车和其他的作品大同小异,但作为单片机设计,这次我把单片机按键发送程序、无线模块使用、电...

1788
来自专栏施炯的IoT开发专栏

Windows on Device 项目实践 5 - 姿态控制灯制作

在前面几篇文章中,我们学习了如何利用Intel Galileo开发板和Windows on Device来设计并完成PWM调光灯、感光灯、火焰报警器和智能风扇的...

1726
来自专栏腾讯IVWEB团队的专栏

全面进阶 H5 直播(下)

MSE 提供了一系列的接口,使开发者可以直接提供 media stream。那 MSE 是如何完成视频流的加载和播放呢?

1.2K0
来自专栏梦里茶室

【Chromium中文文档】Chromium如何展示网页

这个文档从底层描述了Chromium是如何展示网页的。请确认你已经读过多进程架构这篇文章。你会特别想要了解主要组件的框架。你也可能对多进程资源加载感兴趣,以了解...

1895
来自专栏Android机动车

实用的 Android 开源库整理

在Android的开发过程中,每个开发者或多或少的都使用过第三方的开源库,使用第三方的开源库可以给开发者节省大量的精力和时间,进而更好的关注应用本身的业务逻辑。

611
来自专栏ios 技术积累

聊聊怎么阅读SDWebImage源码

关于SDWebImage的介绍就不多说了,网上很多。我们主要聊聊怎么阅读SDWebImage的源码。 阅读源码前首先我们要思考几个问题: 1.SDWebIm...

471
来自专栏微信终端开发团队的专栏

新年新语言,WCDB Swift

WCDB 作为微信的开发者们的需求,并不断优化性能。而这其中,呼声最高的莫过于对 Swift 的支持。

6808
来自专栏技术碎碎念

windows API 开发飞机订票系统 图形化界面 (二)

首先,用到的数据结构的定义、以及全局变量和函数的声明如下: 1 // Flight.c : 定义应用程序的入口点。 2 // 3 #include ...

3347
来自专栏腾讯Bugly的专栏

WKWebView 那些坑

导语 WKWebView 是苹果在 WWDC 2014 上推出的新一代 webView 组件,用以替代 UIKit 中笨重难用、内存泄漏的 UIWebView。...

52211

扫码关注云+社区