iOS - JavaScript 第三方库调研

 通过网上调研发现用于实现 JSOC 交互的第三方库比较少,比较知名的有且只有一个:WebViewJavascriptBridge,但通过查看网上资料,我发现实现 JSOC 交互的功能不一定需要使用第三方库,总结了一下大概有以下六种方式:

  • 1.在 JS 中做一次 URL 跳转,然后在 OC 中拦截跳转。(这里分为 UIWebViewWKWebView 两种,WKWebView 是苹果在 iOS 8 中推出的框架,如果需要兼容更低的版本,可以使用 UIWebView 来做。)
  • 2.利用 WKWebViewMessageHandler
  • 3.利用系统库 JavaScriptCore,来做相互调用。(iOS 7 推出的)
  • 4.利用第三方库 WebViewJavascriptBridge
  • 5.利用第三方 cordova 库,以前叫 PhoneGap。(这是一个库平台的库,类似于 React Native
  • 6.当下盛行的 React Native

因为以上都可以实现 JSOC 的交互,如果用一个一个实现代码测试来对比优劣的话,效率太慢,所以我采用的方式是通过网上资料,把以上实现方式的底层技术两两对比,来选择出适合自己开发的方式。

一、UIWebView 和 WKWebView 的比较

在 iOS 8 以后,iOS 中自带实现加载 web 页面的控件由过去的一种变成了两种:UIWebViewWKWebviewWKWebView 作为新加入的组件,目的是提供一个现代的支持最新 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 特性,允许 JavaScriptNitro 库加载并使用(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-Cjavascript 相互通信,即 ocjs 方法的互相调用。WebViewJavascriptBridge 的原理是通过自定义 scheme,在加载一个特定标识的 URL( wvjbscheme://BRIDGE_LOADED)时在 UIWebView 的代理方法 webView:shouldStartLoadWithRequest:navigationType: 中拦截 URL 并通过 UIWebViewstringByEvaluatingJavaScriptFromString:方法执行一段 JS,这个 JS 文件中声明了一些变量和方法,在通讯中作为一个桥梁。

    JavaScriptCoreWebViewJavascriptBridge 都可以看成在 UIWebviewWKWebview 的自带方法上更深度的实现 jsoc 的交互。虽然实现机制有些差别,但总体来说都是 och5 页面注入 js 代码和截获 js 页面让 js 可以调用 oc 代码,实际性能没有具体测试过。不过值得一提的是,虽然 WebViewJavascriptBridge 知名度很高,而且很多应用都用了这个框架,比如 Facebook Messenger、FacebookPaper 等,但它本身的仓库已经两年没更新了,而 JavaScriptCore 是苹果官方框架,可以说是随着 Xcode 和 iOS 本身一起迭代的框架,所以在考虑选择哪个来实现 jsoc 的交互时,可以把这点纳入参考。

三、cordova 和 React Native 的比较

技术介绍

  • Cordova 是一个开源的移动开发框架。允许用户使用标准的 web 技术 HTML5CSSJavaScript 做开发平台,应用在每个平台的具体执行被封装了起来,并依靠符合标准的API绑定去访问每个设备的功能,比如说;传感器、数据、网络状态等。(摘自 Cordova 官方中文文档)。
  • React Native 是由 Facebook 研发的一套跨平台开发技术,是在 JavaScriptReact 的基础上获得一致的开发体验构建原生 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 较多时可以在 WebViewJavascriptBridgeJavaScriptCore 中选择使用,至于上面提到的第三种方式,其实本质上已经是另一种类型的应用了,这里就不展开谈论了。

------本文结束 感谢阅读------

本文地址:http://kaaaaai.cn/articles/iOS-javaScript-research.html
本文基于 知识共享署名-相同方式共享 4.0 国际许可协议发布
转载请注明出处,谢谢!

众筹项目:拯救世界!
0%