让WKWebview支持NSURLProtocol总结

前言:知识体系的快速建立总是需要踩在前人的肩膀上,很感谢有分享精神的开发者,只有分享才能让知识快速传播,才能推动技术更快发展。

UIWebview中对请求进行拦截,我们的做法是注册一个自定义的NSURLProtocol子类,然后在子类中对请求追加一些额外操作。
而在WKWebview中,我们注册一个自定义的protol类后,除了一开始的时候会调用+ [NSURLProtocol canInitWithRequest:] 方法,之后的整个请求就与NSURLProtocol无关了。难道真是WKWebview不支持NSURLProtocol了吗?
经过查证,有前人已经做了一番探索,并给出来答案。下面详细讲一下:
1、在webkit的源码中:Apple在单元测试TestProrocol.mm中用到了NSURLProtocol ,注册了一个自定义的protocol。代码如下:

+ (void)registerWithScheme:(NSString *)scheme
{
    testScheme = [scheme retain];
    [NSURLProtocol registerClass:[self class]];//这里还是注册了自定义的urlProtocol
#if WK_API_ENABLED
    [WKBrowsingContextController registerSchemeForCustomProtocol:testScheme]; //而且为自定义的protocol这里绑定了scheme
#endif
}复制代码

从上面的代码中我们可以看到:在WKBrowsingContextController中通过registerSchemeForCustomProtocol :注册了一个scheme,而这个scheme很有可能是用来同WKWebview中请求URL的scheme做匹配的,只有匹配成功,才会执行去执行自定义的URLProtocol。
至于为什么要做这种匹配,有人给出的答案是:因为WKWebview是通过Webkit的IPC消息分发机制来进行进程间通信的,IPC的代价还是很大的。我们可以断点看一下堆栈。

2、我们仿照测试用例代码进行改造:

Class cls = NSClassFromString(@"WKBrowsingContextController");
    SEL sel = NSSelectorFromString(@"registerSchemeForCustomProtocol:");
    if([cls respondsToSelector:sel]) {
        //这里我们只需要匹配http和https的scheme
        [cls performSelector:sel withObject:@"http"];
        [cls performSelector:sel withObject:@"https"];
    }复制代码

果然注册后我们自定义的URLProtocol就可以被执行到。(js 执行的网络请求应该还是不会被拦截到)
3、避免Apple检查到使用私有API
这里WKBrowsingContextController和registerSchemeForCustomProtocol:很明显是两个私有的类和方法。如果直接用可能会违反苹果的审核原则。
这里作者提到sunny关于Apple检测是否使用私有API的一些总结:

1、是否 link 了私有 framework 或者公开 framework 中的私有符号,这可以防止开发者把私有 header 都 dump 出来供程序直接调用。
2、同上,使用@selector(_private_sel)加上-performSelector:的方式直接调用私有 API。
3、扫描所有符号,查看是否有继承自私有类,重载私有方法,方法名是否有重合。
4、扫描所有string,看字符串常量段是否出现和私有 API 对应的。

针对改造用到的两处私有API,原作者分别提供了解决方法:
1、WKBrowsingContextController
这个私有类的获取通过KVC方式,获取一个没有入参的selector的返回值。这里的selector是: - browsingContextController , 定义在WKWebview.h的中。

Class cls = [[[WKWebView new] valueForKey:@"browsingContextController"] class];复制代码

这里有两点让人钦佩:(文末会附上连接)
(1)使用kvc来获取无入参的selector的返回值。
(2)WKWebview runtime的源码原作能够去读,很不容易。这里是iOS10的runtime 源码,11上也可验证。

2、registerSchemeForCustomProtocol:这个私有API,则是通过NSSelectorFromString:方式来获得。

return NSSelectorFromString(@"registerSchemeForCustomProtocol:");复制代码

至此,关于WKWebview支持NSURLProtocol的改造可以说已经完成。还是那句话:源码面前了无秘密。

既然已经跟到了这里,还是稍微了解了下webkit的大体结构:但是不做深究:感兴趣可以参考源码和以下博客:webkit2解析

这种解决方法的两个不足:(来源腾讯bugly)

1、post请求body数据被清空。
NSURLProtocol不被执行原因:WKWebview是在独立的进程中进行网络请求。请求数据不经过app主进程,因此在WKWebview上使用注册的NSURLProtocol,也无法拦截请求。
body被清掉原因:webkit2中使用MessageQueue进行进程间通信,会把网络请求encode成一个message,通过IPC发送给App process进程。出于性能的原因,encode 的时候 HTTPBody 和 HTTPBodyStream 这两个字段被丢弃掉了

2、在 WKWebView 上通过 loadRequest 发起的 post 请求 body 数据会丢失的问题也是由于这个原因
针对这个问题我们的思路是:
1、替换url 的scheme ,修改为自定义的scheme。例如:sinaCustomScheme://www.sina.com.cn
2、根据新生成的url,创建一个新的request,并将body数据存放到请求头中。
3、通过上面的方式注册自定义的scheme。
4、在自定义的NSURLProtocol中,将url的scheme替换为原来的scheme。即:www.sina.com.cn,并从requestHeader中取出body,并使用NSURLSession发起新的网络请求。

3、对ATS支持不好。
测试发现一旦打开ATS开关:Allow Arbitrary Loads 选项设置为NO,同时通过 registerSchemeForCustomProtocol 注册了 http(s) scheme,WKWebView 发起的所有 http 网络请求将被阻塞(即便将Allow Arbitrary Loads in Web Content 选项设置为YES);

参阅:
webkit探究
wkwebview探究


作者:不想做iOS了
链接:https://juejin.cn/post/6844903712779927559
来源:掘金
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。
posted @ 2021-08-20 11:20  zzfx  阅读(560)  评论(0编辑  收藏  举报