iOS WebView 业务场景IP连接有哪几种方法（1）

概述


本文主要介绍，防 DNS 污染方案在 WebView 场景下所遇到的一些问题，及解决方案。

WKWebView 无法使用 NSURLProtocol 拦截请求


针对该问题方案如下：

1. 换用 UIWebView
2. 使用私有API进行注册拦截

换用 UIWebView 方案不做赘述，说明下使用私有API进行注册拦截的方法：

1. //注册自己的protocol
2.     [NSURLProtocol registerClass:[CustomProtocol class]];
4.     //创建WKWebview
5.     WKWebViewConfiguration * config = [[WKWebViewConfiguration alloc] init];
6.     WKWebView * wkWebView = [[WKWebView alloc] initWithFrame:CGRectMake(0, 0, [UIScreen mainScreen].bounds.size.width, [UIScreen mainScreen].bounds.size.height) configuration:config];
7.     [wkWebView loadRequest:webViewReq];
8.     [self.view addSubview:wkWebView];
10.     //注册scheme
11.     Class cls = NSClassFromString(@"WKBrowsingContextController");
12.     SEL sel = NSSelectorFromString(@"registerSchemeForCustomProtocol:");
13.     if ([cls respondsToSelector:sel]) {
14.         // 通过http和https的请求，同理可通过其他的Scheme 但是要满足ULR Loading System
15.         [cls performSelector:sel withObject:@"http"];
16.         [cls performSelector:sel withObject:@"https"];
17.     }

使用私有 API 的另一风险是兼容性问题，比如上面的 browsingContextController 就只能在 iOS 8.4 以后才能用，反注册 scheme 的方法 unregisterSchemeForCustomProtocol: 也是在 iOS 8.4 以后才被添加进来的，要支持 iOS 8.0 ~ 8.3 机型的话，只能通过动态生成字符串的方式拿到 WKBrowsingContextController，而且还不能反注册，不过这些问题都不大。至于向后兼容，这个也不用太担心，因为 iOS 发布新版本之前都会有开发者预览版的，那个时候再测一下也不迟。对于本文的例子来说，如果将来哪个 iOS 版本移除了这个 API，那很可能是因为官方提供了完整的解决方案，到那时候自然也不需要本文介绍的方法了。
注意避免执行太晚，如果在 - (void)viewDidLoad 中注册，可能会因为注册太晚，引发问题。建议在 +load 方法中执行。
然后同样会遇到 《HTTPS SNI 业务场景“IP直连”方案说明》 里提到的各种 NSURLProtocol 相关的问题，可以参照里面的方法解决。