不论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请求中的数据,并做相应处理。大概的流程就是这样。