在之前的一篇文章《iOS开发——从UIWebView说起》中，介绍了UIWebView的常规用法以及注意事项，这篇文章将深入介绍一些工作中可能需要的高级用法。
UIWebView与native交互
工作中，我们经常遇到二者交互的需求，例如native根据webview内容的高度自适应处理布局或者事件响应，webview调用native实现h5无法完成的功能等。下面就从两个方面介绍一下UIWebView与native相互交互的方法。
native获取webview信息
通常的做法是，native执行h5页面中提供的js方法获得相关信息。这就涉及到native执行js语句的操作，既然介绍UIWebView，这里主要从它的角度去说如何调用js吧。
上一篇文章中介绍了UIWebView的实例方法：
- (nullable NSString *)stringByEvaluatingJavaScriptFromString:(NSString *)script;
script为要执行的js语句，返回值即得到的结果，这个结果是string类型的，一般还要经过相关的转换处理。
下面列举一些常用的webview信息获取方法。
- 取消长按webView上的链接弹出actionSheet
[webView stringByEvaluatingJavaScriptFromString:@"document.documentElement.style.webkitTouchCallout = 'none';"];
- 根据内容获取webview高度
NSString *fitHeight = [webview stringByEvaluatingJavaScriptFromString:@"document.body.scrollHeight;"];
- 获取webview页面内容
NSString *docStr=[webView stringByEvaluatingJavaScriptFromString:@"document.documentElement.textContent"];
- 去除某个标签内容
[webView stringByEvaluatingJavaScriptFromString:@"document.getElementById('some-tag-id’).remove();"];
- 获取当前页面的title：
NSString *title = [webview stringByEvaluatingJavaScriptFromString:@"document.title"];
- 获取当前页面的url
NSString *url = [webview stringByEvaluatingJavaScriptFromString:@"document.location.href"];
- 获取环境变量
[webView valueForKeyPath:@"documentView.webView.mainFrame.javaScriptContext"];
- 禁止弹出菜单
[webView valueForKeyPath:@" document.documentElement.style.webkitTouchCallout = "none";"];
- 禁止选中
[webView valueForKeyPath:@"document.documentElement.style.webkitUserSelect = "none";"];
webview调用native方法
UIWebView中的处理要想调用native方法，就需要约定一些伪协议接口，常称做bridge接口，然后拦截请求去判断是否符合协议，主要判断schema，满足则调用相关的接口。上篇文章中提到了通过UIWebViewDelegate的方法去处理，这里不再赘述。
iOS7.0开始引入了JavaScriptCore.framework，这个库为我们带来了很多惊喜。这个库提供了访问webkit的JavaScript引擎，是objective-c的封装。有了这个框架，objective-c或swift都可以很方便的与JavaScript进行互通。
打开JavaScriptCore.h文件，你会发现，其实你需要掌握的只有这几个类：
#import "JSContext.h"
#import "JSValue.h"
#import "JSManagedValue.h"
#import "JSVirtualMachine.h"
#import "JSExport.h"
####### JSVirtualMachine
先说 JSVirtualMachine 类，原因是所有 JavaScript 代码的执行都依赖虚拟机对象资源，JSVirtualMachine 代表一个对象空间，拥有自己的堆结构和垃圾回收机制，为 JavaScript 的运行提供了底层资源。一般情况下，开发者不需要与该类的实例交互，除非要处理设计多线程或内存管理等问题。
####### JSContext
JSContext 对象为 JavaScript 代码的执行提供了上下文环境，在 web 开发中，相当于 window 对象。通过JSContext对象可以执行 js 代码，因此，经常通过它给 JavaScript 注册接口，或者拿到 JavaScript 的某些信息。JSContext 对象的初始化需要指定一个 JSVirtualMachine ，你可以理解为，一个 JSContext 的存在必然有一个指定的 JSVirtualMachine 去承接，
####### JSValue
JSValue 是 JavaScript 对象的实体，包括数字、字符串、自定义对象、函数等，只不过经过 objective-c 的包装，因此也就有转换成 objective-c 对象的方法。
####### JSManagedValue
JSManagedValue 的本质其实就是一个JSValue，但是这个类可以处理内存管理相关的问题，辅助更高效地管理 JavaScript 对象的内存。一般用的也比较少。
####### JSExport
JSExport 是一个 JavaScriptCore 中很关键的协议，是 objective-c 与 JavaScript 交互的核心方法。通过该协议，开发者可以给 JavaScript 暴露接口，也可以通过 callback 参数去完成 JavaScript 的调用。
请求拦截
说到请求拦截，大家立刻会想到UIWebView的代理方法：
- (BOOL)webView:(UIWebView *)webView shouldStartLoadWithRequest:(NSURLRequest *)request navigationType:(UIWebViewNavigationType)navigationType
是的，没错！在上篇文章中也有提到，该方法用于判断是否要处理收到的URL请求，return YES;表示开始加载请求，return NO;则拦截当前的请求并按照自己的方式在return之前去处理。
NSURLProtocol拦截
其实对于UIWebView还有更专业地操作方式，那就是使用NSURLProtocol类。在苹果的url loading系统中，NSURLProtocol是非常重要的一个类，它独立存在但又能拦截整个URL loading系统中所有的网络请求，同时该类提供了丰富的接口辅助开发者根据自己需求去处理拦截到的请求。（更详细介绍见这里）
下面从应用的角度，介绍一下如何将NSURLProtocol于UIWebView结合起来进行请求拦截。首先看一下URLProtocol常用的属性和方法：
@property (nullable, readonly, retain) id <NSURLProtocolClient> client;
@property (nullable, readonly, copy) NSCachedURLResponse *cachedResponse;
// 该子类化的Protocol能否处理给定的request (2)
+ (BOOL)canInitWithRequest:(NSURLRequest *)request;
// 根据给定request，返回一个规范的request (3)
+ (NSURLRequest *)canonicalRequestForRequest:(NSURLRequest *)request;
// 启动加载请求(规范后的)，在这里实现本地请求处理
- (void)startLoading; (4)
// 停止请求加载
- (void)stopLoading; (5)
// 存储属性信息，用于传递request相关信息
+ (void)setProperty:(id)value forKey:(NSString *)key inRequest:(NSMutableURLRequest *)request;
// 获取存储在request中的属性信息
+ (nullable id)propertyForKey:(NSString *)key inRequest:(NSURLRequest *)request;
// 注册子类化的NSURLProtocol (1)
+ (BOOL)registerClass:(Class)protocolClass;
// 注销子类化的NSURLProtocol (6)
+ (void)unregisterClass:(Class)protocolClass;
上面标记的数字表示请求加载时抽象接口的调用顺序，因此在子类中，需要按照相应的顺序进行处理。
在类中有一个属性 client，该属性正是开发者用于与 loading 系统交互的桥梁，当我们拦截住请求并成功处理之后，需要告诉loading系统，你请求的数据我们已经准备好了，这个时候就是通过这个 client 去代理完成。相关回调参考协议<NSURLProtocolClient>
一般我们这么处理：
if(!error){
[self.client URLProtocol:self didReceiveResponse:response cacheStoragePolicy:NSURLCacheStorageNotAllowed];
[self.client URLProtocol:self didLoadData:data];
[self.client URLProtocolDidFinishLoading:self];
} else {
[self.client URLProtocol:self didFailWithError:error];
[self.client URLProtocolDidFinishLoading:self];
}
其中，response、data需要我们提前准备好。
使用注意
NSURLProtocol是一个抽象类，要想使用必须子类化它，并且，最好在用完之后能 unregister，避免无休止的拦截判断，影响app性能。
Protocols 的遍历是反向的，如果客户端同时注册了多个 NSURLProtocol，那么首先会走到最后一个注册的 Protocol 里，直到第一个。
NSURLCache 拦截
为提高 webview 加载体验，缓存是必不可少的部分，除了上面的方法，其实苹果专门提供了一个强大却经常被开发者忽略的类来处理 url 请求的缓存——NSURLCache。观察苹果的URL loading系统，Cache Management 部分其实很值得注意。通常情况下，当loading系统加载一个请求时，首先会从NSURLCache 里查找有没有缓存，有缓存就拿来用，没有则根据url去网络加载。
因此，无论如何，系统都会带着 request 走到 NSURLCache 中，然后判断。因此，与 NSURLProtocol 思路相同，我们也可以子类化 NSURLCache 然后判断是否要对request进行拦截。
看一下 NSURLCache 提供的常用属性和方法：
- (nullable NSCachedURLResponse *)cachedResponseForRequest:(NSURLRequest *)request;
- (void)storeCachedResponse:(NSCachedURLResponse *)cachedResponse forRequest:(NSURLRequest *)request;
- (void)removeCachedResponseForRequest:(NSURLRequest *)request;
@property NSUInteger memoryCapacity;
@property NSUInteger diskCapacity;
@property (readonly) NSUInteger currentMemoryUsage;
@property (readonly) NSUInteger currentDiskUsage;
之所以很多开发者忽略NSURLCache，是因为虽然 NSURLCache 内存缓存和磁盘缓存，支持设置最大缓存大小，但是实际上，NSURLCache 只能使用内存缓存，并且最大容量为4M。但是，作为拦截只用，NSURLCache 还是可以支持的。
