前言：知识体系的快速建立总是需要踩在前人的肩膀上，很感谢有分享精神的开发者，只有分享才能让知识快速传播，才能推动技术更快发展。
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。即：http://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探究
