WKWebView中NSURLProtocol的使用以及对H5的缓存

前言

出于节省hybrid app的性能，以及加载时间，对app内的一些资源做缓存处理，包括：图片、js文件。
首先，我们需要能拦截到这些请求，实验之后，发现NSURLProtocol在WKWebViwe中不生效。
本文分一下两个部分：

让WKWebView支持NSURLProtocol，摘抄了这篇博客大篇幅内容，其中有关于苹果对私有API的监测以及开发人员的应对措施
对资源做缓存措施

让WKWebView支持NSURLProtocol

在UIWebView中，只需要一行代码[NSURLProtocol registerClass:[customeURLProtocol class]];，就可以对app内所有的网络请求进行拦截处理。
但是在WKWebView中，除了一开始会调用一下 + [NSURLProtocol canInitWithRequest:] 方法，之后就全拦截不到了。网上查，说是WKWebView 的请求是在单独的进程里，所以不走 NSURLProtocol。

# registerSchemeForCustomProtocol

从方法名来猜测，它的作用的应该是注册一个自定义的 scheme，这样对于 WebKit 进程的所有网络请求，都会先检查是否有匹配的 scheme，有的话再走主进程的 NSURLProtocol 这一套流程
博客作者猜测这么做可能是为了保证效率 (NSURLRequest 的 HTTPBody 属性在 WKWebView 中被忽略了应该也出于这个原因!!! --- 这是个大坑不能发POST请求了！)，毕竟 IPC 代价挺高的。详细可以看： WebKit::CustomProtocolManager 和 WebKit::WebProcessPool 等相关源码

解决方案：

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"];

此时，[NSURLProtocol registerClass:[customeURLProtocol class]]就可以生效了

# 优化 - 私有API检测

## 关于私有 API

按照 @sunnyxx 的总结，Apple 检查私有 API 的使用，大概会采取下面几种手段：

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

Class cls = NSClassFromString(@"WKBrowsingContextController");
SEL sel = NSSelectorFromString(@"registerSchemeForCustomProtocol:");

上面两行代码非常之符合第四条。

解决方案：
查询 WKWebView.h 可以看到，有个方法 - browsingContextController 的方法名跟 WKBrowsingContextController 长得很像，通过 KVC 取出来（没错，KVC 不但可以取 property 取 ivar，还可以取无入参 selector 的返回值）发现它就是 WKBrowsingContextController 的一个实例，这样一来这个私有类就可以通过 KVC 的方式来得到了：

Class cls = [[[WKWebView new] valueForKey:@"browsingContextController"] class];

valueForKey 比直接使用 NSClassFromString安全了许多。
其他解决方案：这些字符串也可以不明着写出来，只要运行时算出来就行，比如用 base64 编码啊，图片资源里藏一段啊，甚至通过服务器下发……

## 使用私有 API 的另一风险是兼容性问题

比如上面的 browsingContextController 就只能在 iOS 8.4 以后才能用，反注册 scheme 的方法 unregisterSchemeForCustomProtocol:也是在 iOS 8.4 以后才被添加进来的。

要支持 iOS 8.0 ~ 8.3 机型的话，只能通过动态生成字符串的方式拿到 WKBrowsingContextControlle，而且还不能反注册，不过这些问题都不大。至于向后兼容，这个也不用太担心，因为 iOS 发布新版本之前都会有开发者预览版的，那个时候可以提前关注测一下。对于以上的例子来说，如果将来哪个 iOS 版本移除了这个 API，那很可能是因为官方提供了完整的解决方案，到那时候自然也不需要以上的方法了。

对资源做缓存措施

# 1. 图片资源

通过response.MIMEType判断如果是: image/gif image/jpeg image/jpg image/png利用SDWebImage提供的缓存api来存储数据：

- (void)storeImage:(nullable UIImage *)image
     imageData:(nullable NSData *)imageData
        forKey:(nullable NSString *)key
        toDisk:(BOOL)toDisk
    completion:(nullable SDWebImageNoParamsBlock)completionBlock;

# 2. 文件

文件之类的我们是使用本地存储来做缓存

遇到的问题

这么做有隐患，自定义NSURLProtocol 会影响WKWebView中POST请求，所以使用起来还得根据场景来看
- 控制自定义的协议的开关时机
- 如果实在冲突可以再创建一个WKWebView、UIWebView的控制器，根据场景分开使用
有一阵，页面上有一些图片资源无法正常加载，下拉刷新无效，怀疑是缓存了错误资源，两个方面：1. CDN资源有问题 2. 缓存策略有问题。当时由于紧急修复，后来由于求稳...功能暂时搁置了
不会拦截原生AFN请求(也不算问题，一般也没必要)

如果监控网络是通过注册NSURLProtocol来进行网络监控的,而且是用的AFN3.0，那么是拦截不到的，通过 sessionWithConfiguration:delegate:delegateQueue:
得到的session,他的configuration中已经有一个NSURLProtocol,
所以不会走自定义的protocol（通过share得到的session没这个问题)