上一篇我们说到
NSURLPtotocol是作为我们的网路Hooker,给我们的开发带来的爽，但是注意NSURLPtotocol是无法直接拦截AFN的，还有非单利状态生成的NSUrlSession
如果对NSURLPtotocol还比较陌生的小伙伴，不妨可以参考一下。NSURLPtotocol 网络hooker
那么为什么NSURLPtotocol是无法直接拦截AFN的，还有非单利状态生成的NSUrlSession 来分析一下
对于NSURLSession发起的网络请求,我们发现通过shared得到的session发起的网络请求都能够监听到,但是通过方法 sessionWithConfiguration:delegate:delegateQueue:得到的session,我们是不能监听到的,原因就出在NSURLSessionConfiguration上,我们进到NSURLSessionConfiguration里面看一下,他有一个属性
断点监听查看config.protocolClasssess
也许看到这你就明白了!这是一个
NSURLProtocol数组,上面我们提到了,我们监控网络是通过注册NSURLProtocol来进行网络监控的,但是通过sessionWithConfiguration:delegate:delegateQueue:得到的session,他的configuration中已经有一个NSURLProtocol,所以他不会走我们的protocol来,怎么解决这个问题呢? 其实很简单,我们将NSURLSessionConfiguration的属性protocolClasses的get方法hook掉,通过返回我们自己的protocol,这样,我们就能够监控到通过sessionWithConfiguration:delegate:delegateQueue:得到的session的网络请求
- (void)load {
self.isSwizzle=YES;
Class cls = NSClassFromString(@"__NSCFURLSessionConfiguration") ?: NSClassFromString(@"NSURLSessionConfiguration");
[self swizzleSelector:@selector(protocolClasses) fromClass:cls toClass:[self class]];
}
- (void)unload {
self.isSwizzle=NO;
Class cls = NSClassFromString(@"__NSCFURLSessionConfiguration") ?: NSClassFromString(@"NSURLSessionConfiguration");
[self swizzleSelector:@selector(protocolClasses) fromClass:cls toClass:[self class]];
}
- (void)swizzleSelector:(SEL)selector fromClass:(Class)original toClass:(Class)stub {
Method originalMethod = class_getInstanceMethod(original, selector);
Method stubMethod = class_getInstanceMethod(stub, selector);
if (!originalMethod || !stubMethod) {
[NSException raise:NSInternalInconsistencyException format:@"Couldn't load NEURLSessionConfiguration."];
}
method_exchangeImplementations(originalMethod, stubMethod);
}
- (NSArray *)protocolClasses {
return @[[PPSURLProtocol class]];
//如果还有其他的监控protocol,也可以在这里加进去
}
下面是拦截WKWebView
[NSURLProtocol registerClass:[AwesomeURLProtocol class]];
但 WKWebView 中的请求却完全不遵从这一规则，除了一开始会调用一下 + [NSURLProtocol canInitWithRequest:] 方法，之后的整个请求流程似乎就与 NSURLProtocol完全无关了。关于这一点，网络上文章一般都解释说 WKWebView 的请求是在单独的进程里，所以不走 NSURLProtocol。
既然WKWebView 不走 NSURLProtocol，那为什么还要在一开始调一下 canInitWithRequest: 呢？更令我好奇的是从WebKit.framework dump 出的头文件能看出，有几个类（WKCustomProtocol、WKCustomProtocolLoader）明显与 NSURLProtocol 有关，说明 WKWebView很可能是支持 NSURLProtocol 的，只是出于某种原因没开放而已，于是我决定翻 WebKit的源码一探究竟。
WKBrowsingContextController
翻 WebKit 源码的过程就不细说了，光从 GitHub 上拉源码到本地就花了我几个 G 的 ss 流量……总之翻到最后，我在一项单元测试 TestProtocol.mm 中看到了 NSURLProtocol 熟悉的身影：
+ (void)registerWithScheme:(NSString *)scheme
{
testScheme = [scheme retain];
[NSURLProtocol registerClass:[self class]];
#if WK_API_ENABLED
[WKBrowsingContextController registerSchemeForCustomProtocol:testScheme];
#endif
}
从 registerSchemeForCustomProtocol: 这个方法名来猜测，它的作用的应该是注册一个自定义的 scheme，这样对于 WebKit 进程的所有网络请求，都会先检查是否有匹配的 scheme，有的话再走主进程的 NSURLProtocol这一套流程，猜测这么做可能是为了保证效率(NSURLRequest 的 HTTPBody 属性在 WKWebView 中被忽略了应该也出于这个原因)，毕竟 IPC 代价挺高的。后续翻 WebKit::CustomProtocolManager 和 WebKit::WebProcessPool 等相关源码也印证了这个猜想。
看上去没什么问题，于是按照 TestCase 里的例子尝试了一下：
Class cls = NSClassFromString(@"WKBrowsingContextController");
SEL sel = NSSelectorFromString(@"registerSchemeForCustomProtocol:");
if ([(id)cls respondsToSelector:sel]) {
// 把 http 和 https 请求交给 NSURLProtocol 处理
[(id)cls performSelector:sel withObject:@"http"];
[(id)cls performSelector:sel withObject:@"https"];
}
// 这下 AwesomeURLProtocol 就可以用啦
[NSURLProtocol registerClass:[AwesomeURLProtocol class]];
现在 WKWebView中的所有请求都可以被 NSURLProtocol修改了
关于私有 API
按照 @sunnyxx 的总结，Apple 检查私有 API 的使用，大概会采取下面几种手段：
- 是否
link了私有framework或者公开framework中的私有符号，这可以防止开发者把私有header都dump出来供程序直接调用。 - 同上，使用
@selector(_private_sel)加上-performSelector:的方式直接调用私有API。 - 扫描所有符号，查看是否有继承自私有类，重载私有方法，方法名是否有重合。
- 扫描所有string，看字符串常量段是否出现和私有
API对应的。
而本文所介绍的方法，一共有两个地方使用了私有 API：
Class cls = NSClassFromString(@"WKBrowsingContextController");
SEL sel = NSSelectorFromString(@"registerSchemeForCustomProtocol:");
这两个地方都是通过反射的方式拿到了私有的 class/selector，对应上面的第四条。其中第二行那个还好说，因为 registerSchemeForCustomProtocol 这个名词看上去相当普通，如果把这种字符串也禁掉了的话会误伤一大票开发者，所以有风险的主要是 WKBrowsingContextController 这个字符串，要前缀有前缀，要 camel case 有 camel case，再跟私有 class名撞车的话就跟可能被拒了。
那么怎样绕过这个字符串呢？查询 WKWebView.h 可以看到，有个方法 - browsingContextController 的方法名跟 WKBrowsingContextController 长得很像，通过 KVC 取出来（没错，KVC 不但可以取 property 取 ivar，还可以取无入参 selector 的返回值）发现它就是 WKBrowsingContextController 的一个实例，这样一来这个私有类就可以通过 KVC 的方式来得到了：
Class cls = [[[WKWebView new] valueForKey:@"browsingContextController"] class];
比起粗暴地 NSClassFromString，使用 valueForKey 的方法安全了许多。当然，如果还有什么要担心的话，这些字符串也可以不明着写出来，只要运行时算出来就行，比如用 base64 编码啊，图片资源里藏一段啊，甚至通过服务器下发……既然到了这个程度，苹果的静态扫描就很难再 hold住了。
使用私有 API 的另一风险是兼容性问题，比如上面的 browsingContextController 就只能在 iOS 8.4 以后才能用，反注册scheme的方法 unregisterSchemeForCustomProtocol: 也是在iOS 8.4 以后才被添加进来的，要支持iOS 8.0 ~ 8.3机型的话，只能通过动态生成字符串的方式拿到 WKBrowsingContextController，而且还不能反注册，不过这些问题都不大。至于向后兼容，这个也不用太担心，因为 iOS 发布新版本之前都会有开发者预览版的，那个时候再测一下也不迟。对于本文的例子来说，如果将来哪个 iOS版本移除了这个 API，那很可能是因为官方提供了完整的解决方案，到那时候自然也不需要本文介绍的方法了。
最后，支持iOS 8.4+，代码经测试已通过 App Store审核：
github源码