前言
出于节省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没这个问题)
解决方案：
- 我们将NSURLSessionConfiguration的属性
protocolClasses的get方法hook掉,
通过返回自定义的protocol,这样,
我们就能够监控到通过sessionWithConfiguration:delegate:delegateQueue:
得到的session的网络请求
- 我们将NSURLSessionConfiguration的属性
- 在AFHTTPSessionManager中注册
NSMutableArray *protocols = [NSMutableArray arrayWithArray:manager.session.configuration.protocolClasses];
[protocols insertObject:[customeURLProtocol class] atIndex:0];
manager.session.configuration.protocolClasses = [protocols copy];
manager是你发送请求时的AFHTTPSessionManager类，注意不能用[AFHTTPSessionManager manager]代替
[AFHTTPSessionManager manager]其实不是单例，每次调用的时候都会init出一个新的manager，因此只能在每次初始化好manager之后都注册一次NSURLProtocol
网友评论