通过网上调研发现用于实现 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 中选择使用，至于上面提到的第三种方式，其实本质上已经是另一种类型的应用了，这里就不展开谈论了。
