通过网上调研发现用于实现 JS
和 OC
交互的第三方库比较少,比较知名的有且只有一个:WebViewJavascriptBridge,但通过查看网上资料,我发现实现 JS
和 OC
交互的功能不一定需要使用第三方库,总结了一下大概有以下六种方式:
- 1.在
JS
中做一次URL
跳转,然后在OC
中拦截跳转。(这里分为UIWebView
和WKWebView
两种,WKWebView
是苹果在 iOS 8 中推出的框架,如果需要兼容更低的版本,可以使用UIWebView
来做。) - 2.利用
WKWebView
的MessageHandler
。 - 3.利用系统库
JavaScriptCore
,来做相互调用。(iOS 7 推出的) - 4.利用第三方库
WebViewJavascriptBridge
。 - 5.利用第三方
cordova
库,以前叫PhoneGap
。(这是一个库平台的库,类似于React Native
) - 6.当下盛行的
React Native
。
因为以上都可以实现 JS
和 OC
的交互,如果用一个一个实现代码测试来对比优劣的话,效率太慢,所以我采用的方式是通过网上资料,把以上实现方式的底层技术两两对比,来选择出适合自己开发的方式。
一、UIWebView 和 WKWebView 的比较
在 iOS 8 以后,iOS 中自带实现加载 web
页面的控件由过去的一种变成了两种:UIWebView
和 WKWebview
。WKWebView
作为新加入的组件,目的是提供一个现代的支持最新 Webkit
功能的网页浏览控件,摆脱过去 UIWebView
的老、旧、笨,特别是内存占用量巨大的问题。它使用与 Safari 中一样的 Nitro JavaScript
引擎,大大提高页面 js 执行速度。相对于 UIWebView
的优势:
- 1.内存占用是
UIWebView
的1/4~1/3(有一篇文章里测试用模拟器加载百度与开源中国网站时,WKWebView占用23M,而UIWebView占用85M)。 - 2.页面加载速度有提升,有的文章说它的加载速度比
UIWebView
提升了一倍左右。 - 3.更为细致地拆分了
UIWebViewDelegate
中的方法。 - 4.自带进度条。不需要像
UIWebView
一样自己做假进度条(通过NJKWebViewProgress
和双层代理技术实现),技术复杂度和代码量,根贴近实际加载进度优化好的多。 - 5.支持了更多的
HTML5
特性,允许JavaScript
的Nitro
库加载并使用(UIWebView
中限制)。 - 6.可以和
js
直接互调函数,不像UIWebView
需要第三方库WebViewJavascriptBridge
来协助处理和js
的交互。 - 7.高达60fps的滚动刷新率以及内置手势。
但也存在一些缺点:
- 1.不支持页面缓存,需要自己注入
cookie
,而UIWebView
是自动注入cookie
。 - 2.无法发送
POST
参数问题
二、JavaScriptCore 和 WebViewJavascriptBridge
技术介绍
JavaScriptCore
框架 是一个苹果在 iOS 7 引入的框架,该框架让Objective-C
(或Swift
) 和JavaScript
代码直接的交互变得更加的简单方便。JavaScriptCore
使用 JavaScriptCore 框架可以实现 OC 和 JS 的互相调用,而不需要依赖WebViewJavascriptBridge
类似于「桥梁」的机制来实现。WebViewJavascriptBridge
主要作用用于:Objective-C
和javascript
相互通信,即oc
和js
方法的互相调用。WebViewJavascriptBridge
的原理是通过自定义scheme
,在加载一个特定标识的URL
( wvjbscheme://BRIDGE_LOADED)时在UIWebView
的代理方法webView:shouldStartLoadWithRequest:navigationType:
中拦截URL
并通过UIWebView
的stringByEvaluatingJavaScriptFromString:
方法执行一段JS
,这个JS
文件中声明了一些变量和方法,在通讯中作为一个桥梁。JavaScriptCore
和WebViewJavascriptBridge
都可以看成在UIWebview
和WKWebview
的自带方法上更深度的实现js
和oc
的交互。虽然实现机制有些差别,但总体来说都是oc
往h5
页面注入js
代码和截获js
页面让js
可以调用oc
代码,实际性能没有具体测试过。不过值得一提的是,虽然WebViewJavascriptBridge
知名度很高,而且很多应用都用了这个框架,比如 Facebook Messenger、FacebookPaper 等,但它本身的仓库已经两年没更新了,而JavaScriptCore
是苹果官方框架,可以说是随着 Xcode 和 iOS 本身一起迭代的框架,所以在考虑选择哪个来实现js
和oc
的交互时,可以把这点纳入参考。
三、cordova 和 React Native 的比较
技术介绍
Cordova
是一个开源的移动开发框架。允许用户使用标准的web
技术HTML5
,CSS
和JavaScript
做开发平台,应用在每个平台的具体执行被封装了起来,并依靠符合标准的API绑定去访问每个设备的功能,比如说;传感器、数据、网络状态等。(摘自Cordova
官方中文文档)。React Native
是由 Facebook 研发的一套跨平台开发技术,是在JavaScript
和React
的基础上获得一致的开发体验构建原生 APP。宗旨是 Learn once, write anywhere。(摘自React Native
官方中文文档)
他们的最大区别在于,可以把 Cordova
理解成内嵌一个移动端的 web 页面,需要依托于原生平台上实现页面展示,业务逻辑处理等功能。
而 React Native
则相当与一个区别于原生的一个独立拥有自己体系的一个平台。其特点是使用 JavaScript
编写出的代码会转为原生平台的 API
。
通过网上资料 iOS原生,React Native,Cordova技术选型对比,得到结果。
开发模式 /对比项 | Cordova | React Native | 原生 |
---|---|---|---|
内存 | 差 | 一般 | 优 |
运行效率 | 一般 | 优 | 优 |
帧率 | - | - | - |
其他对比,跨平台特性:
- Cordova: write once, run anywhere ( 一次开发,随处运行)
- React-Native: Learn once, write anywhere ( 一次学习,随处开发)
功能支持:
- Cordova: 基本功能完全具备,对于底层,如摄像头之类的,需要插件。
- React-Native: 完全支持。 Android 端不是很完善。
风险程度:
Native 比 cordova 高。
开发成本:
- Cordova: 完全基于 html,css,js 。写一次代码,两个平台都适用。
- React-Native: 具有相同语法体系,但需要根据不同平台编写不同代码。
运行速度:
- Cordova: 相对较慢
- React-Native: 跟 Native 基本相当
总结
通过以上对比,我们暂时可以得出一个初步结论,当你应用的 h5 交互较少的情况下可以使用原生的控件。当你的 h5 较多时可以在 WebViewJavascriptBridge
和 JavaScriptCore
中选择使用,至于上面提到的第三种方式,其实本质上已经是另一种类型的应用了,这里就不展开谈论了。