在上一篇关于WKWebView的文章浅谈iOS中的WKWebView和H5之间通信及WKWebViewJavascriptBridge源码分析中，最后笔者遗留了一个问题，就是关于NSURLProtocol在拦截WKWebView请求时候会出现的问题。
问题点主要是：
1、首先，NSURLProtocol在拦截WKWebView请求时，按照之前拦截UIWebView的方式是拦截不到的
笔者在demo（最下方已提供）中使用：
[NSURLProtocol registerClass:[BLURLProtocol class]];
然而并没有进
+ (BOOL)canInitWithRequest:(NSURLRequest *)request{
return YES;
}
在此基础上，笔者也看了一下webkit的源码，大致的原理：
在WebView初始化之后，在WKBrowsingContextController中会有一步注册scheme的步骤：
而这个步骤跟接下来苹果自己创建的WKCustomProtocol类有关，这个类也是直接继承于NSURLProtocol的。在这个类的拦截方法中：
所以照着webkit源码分析可得，其实NSURLProtocol这个类还是可以拦截request的，只不过在某些特定的情况下不支持，首当其冲的就是WKWebView。说明在WKWebView初始化的过程中，就没有注册http和https两个scheme。并且大家都知道WKWebView和UIWebView的内核都不是同一个，这也说明苹果公司在这方面在做改动。所以针对NSURLProtocol可以拦截request却无法拦截WKWebView的request这一现象，网友们也是道法万千，想尽各种办法。
2、针对NSURLProtocol无法拦截WKWebView请求的各种办法
首先一开始的时候网友们直接在WKBrowsingContextController在注册协议的方法registerSchemeForCustomProtocol上做手脚。目的就是为了使NSURLProtocol可以不管在任何情况下可以拦截http和https。基本代码如下：
Class cls = [[[WKWebView new] valueForKey:@"browsingContextController"] class];
SEL sel = NSSelectorFromString(@"registerSchemeForCustomProtocol:");
if ([(id)cls respondsToSelector:sel]) {
#pragma clang diagnostic push
#pragma clang diagnostic ignored "-Warc-performSelector-leaks"
// 注册http(s) scheme, 把 http和https请求交给 NSURLProtocol处理
[(id)cls performSelector:sel withObject:@"http"];
[(id)cls performSelector:sel withObject:@"https"];
#pragma clang diagnostic pop
}
当然下有对策，上有政策，iOS11之后，这个方式就直接被杀死，毕竟开发者直接使用了底层的私有API，风险太大。
iOS11之后，苹果公司，自己提供一个看似网友们都十分欢喜的新的API：
- (void)setURLSchemeHandler:(nullable id <WKURLSchemeHandler>)urlSchemeHandler forURLScheme:(NSString *)urlScheme API_AVAILABLE(macos(10.13), ios(11.0));
代码中的WKURLSchemeHandler，如下（简洁版）：
API_AVAILABLE(macos(10.13), ios(11.0))
@protocol WKURLSchemeHandler <NSObject>
- (void)webView:(WKWebView *)webView startURLSchemeTask:(id <WKURLSchemeTask>)urlSchemeTask;
- (void)webView:(WKWebView *)webView stopURLSchemeTask:(id <WKURLSchemeTask>)urlSchemeTask;
@end
很开心啊，苹果直接提供了scheme的拦截！！！其实，这个拦截操作，只能拦截带着我们自定义的scheme的url，比方说笔者demo中的：
[configaration setURLSchemeHandler:self.schemeHandler forURLScheme:@"bltest"];
但是，虽然只能拦截自定义的scheme，我们开发者也可以做很多想做的事。
3、回到初衷，做我们想做的事
对于NSURLProtocol在拦截WKWebView请求上这个问题，我们大部分开发者，主要目的就是为了在拦截请求之后，做自己想做的事，比如笔者demo中所实现的，index.html中本身没有testFunc方法，在通过拦截之后，读取了本地的js文件之后添加了这个方法。只不过就是以前我们常规的js加载方式是这样的：
<script src="https://xxx/xxx.js"></script>
而我们现在需要写成的是这样的：
<script src="bltest://test.js"></script>
因为之后写成自定义scheme之后，我们才可以使用WKURLSchemeHandler去拦截这个请求，从而加载我们原本就在本地准备好的js文件资源。
其实WKURLSchemeHandler拦截的方法的出现，主要也是苹果公司给开发者提供的一些便捷，至少可以实现那些需要加载本地资源文件的需求。当然笔者感觉后续对于WKWebView请求的拦截操作，苹果公司应该还会有所优化，我们也拭目以待！
