本系列博客是本人的开发笔记。为了方便讨论，本人新建了一个微信群(iOS技术讨论群)，想要加入的，请添加本人微信：zhujinhui207407，【加我前请备注：iOS 】，本人博客http://www.kyson.cn 也在不停的更新中，欢迎一起讨论
不论iOS还是Android，都有浏览器，对应到开发中有个控件叫做UIWebView，在App开发中摒弃原生页面编写，而在App中嵌入UIWebView，使用开发网页的方式开发App，这就是所谓的Hybrid开发吧。
这种开发模式最大的好处是资源在服务端，迭代速度快，不需要频繁提交审核。缺点是：
1.由于HTML等网页资源在服务端，所以加载速度有点慢，用户体验欠佳
2.HTML的能力有限，不能或者有限的能调用诸如定位，蓝牙，支付等功能
3.UIWebView在各个系统版本上的兼容性问题
围绕上面的这几个问题，我们做了如下事情
网页资源提前加载到本地
在App启动时会请求一个配置文件，包含版本号和包地址，举例我们的文件如下：
{"errorMsg": "", "code": 0, "data": [{"zipDownloadUrl": "https://192.168.10.10/cdn/updatepkg/matrix_v2.2.606.zip", "version": "2.2.606", "packageName": "dist"}]}
这个配置文件每次启动会去下载，并比对version跟本地的version是否一致，不一致则下载，一致则略过。
部分对用户体验要求较高的页面使用原生开发
对用户体验要求较高的页面（比如首页），我们最好还是使用原生开发。这也是Hybrid的真正意义所在吧。但随之也会产生一个新的问题：原生页面和H5的跳转实现。
原生->H5，只需要进入一个带UIWebView的原生页面即可
H5->原生，这个有点复杂，需要定义一套协议用于页面跳转。
网上的参考文档不少，比较有名的是叶小钗的博客：http://www.cnblogs.com/yexiaochai/p/4921635.html
这里我在添加一些我们团队总结的吧
<font color="red">1.http和https的处理</font>
由于现在对网络安全的重视（当然苹果也由于要求），越来越多的App加入了https的支持。有一种非常普遍的问题需要我们注意：跨域。举个例子，我们的UIWebView加载的页面是https://www.baidu.com，但baidu.com这个页面中的某段js代码会执行页面跳转，而跳转的协议是hybrid，也就是诸如hybrid://AViewController类似的URL地址。App意识到这可能是一段不安全的代码，因此不给于执行，之前就是遇到了这个问题导致我们App不能响应任何【H5->原生】跳转。那如何“鱼和熊掌兼得”呢，解决方案有两种，各有利弊：
在调用UIWebView的loadRequest方法时，先去判断本地有没有资源，有的话加载本地资源，这样其实就变相的走了http协议或者file协议，就不存在https跨域的问题。但是对于UIWebView的js请求我们还是要进行拦截，走本地的https请求即可。这个方案的优点在于，由于html文件资源在本地所以加载资源速度比较快，用户体验不错；缺点就是我们必须通过URLProtocol重新定义所有的请求，这就需要我们在Request请求的时候避免在httpbody或者httpbodystream中设置参数，转而在header中设置。另外一种解决方案是，请求的时候将URL地址直接从https替换成http，这样的好处就是不需要定义所有的网络请求，但由于html文件资源在远端所以加载资源速度比较慢。
<font color="red">2.参数的传递</font>
在原生和H5之间跳转的时候，参数传递都作为URL地址的一部分，例如AViewController中有属性username和tel，那我们在跳转到AViewController是路由的写法应该是类似：
hybrid://AViewController?username=123&tel=1526181629x
这个很好理解，但有种情况，如果接受的是个url，并且url中也有参数怎么办？（啥啥啥？黑人问号脸。。。）举例
hybrid://AViewController?url=http://www.baidu.com?username=123&tel=1526181629x
那请问，tel是AViewController的参数还是url自带的参数？这是个问题。解决方案其实也很简单：一层层encode，比如有一个url那就encode一次，如果url中还带url那再encode一次。decode的时候也是一样，一层一层decode。
使用原生SDK编写一套可供js调用的API
路由除了可以用于原生页面和H5页面跳转，还可以用于调用本地的一些功能（或者称“API”或者 “服务”，是的，我习惯称“服务”这种说法），下面是我们App预设的一些服务：
// 打开新页面
#define SERVICE_OPENNEWPAGE @"hybrid://openNewPage?param="
// 更新导航栏
#define SERVICE_UPDATEUIHEADER @"hybrid://updateNavigationBar?param="
// 回退
#define SERVICE_PAGEBACK @"hybrid://back?param="
// 获取定位
#define SERVICE_GETLOCATION @"hybrid://getLocation?param="
// 获取网络类型，状态
#define SERVICE_NETWORKTYPE @"hybrid://getNetWorkType?param="
因此只要在html中指明如上的链接即可。有时我们需要在调用服务成功后给个反馈，那就需要在native调H5的方法，幸好JSContext帮我们实现了这个想法。
应对UIWebView在各个系统版本上的兼容性问题
这个问题基本是无解的：在iOS9.1中，如果调用UIWebView的goback方法是不起作用的，是的，很遗憾这是UIWebView的一个Bug，因此尽量少的在一个页面中进行html的跳转是唯一的解决方案。如果你够棒，可以将一些开源的浏览器内核写进你的App，除此之外你毫无办法。
好了，基本的理论知识已经完了，框架的代码可以在这里获取：
https://github.com/zjh171/Watermelon
下面我们来看下我们的这个西瓜框架。
如图，当一个Request 发起后（这个Request 可以是UIWebView中的某个链接点击产生，也可以UIWebView的Ajax请求），通过Watermelon 进行拦截，如果是正常的HTTP请求则放过，如果是我们定义的scheme则单独做处理。OHHttpStub是基于NSURLProtocol实现的URL Request 拦截系统。方法
+(id<OHHTTPStubsDescriptor>)stubRequestsPassingTest:(OHHTTPStubsTestBlock)testBlock
withStubResponse:(OHHTTPStubsResponseBlock)responseBlock;
而参数testBlock就是需要拦截的Request请求，拦截后我们可以自己实现自己的Request请求，并返回数据给responseBlock。至于这里为什么使用OHHttpStub不使用原生的NSURLProtocol是为了避免与其他的使用NSURLProtocol 的三方库（比如Bulgly）冲突。当拦截成功后，我们再把结果分发给WebView。
WebView接受到数据就解析Request请求中的数据，并做相应处理。大概的流程就是这样。