0
点赞
收藏
分享

微信扫一扫

如何在iOS和Android上选择一个JavaScript 引擎进行应用开发

金穗_ec4b 2022-12-27 阅读 272


在我开始使用​​OpenAphid-Engine​​​的时候,已经有几种类似的iOS/Android 项目.这些商业项目或者开源项目使用JavaScript实现代码特性。比如,​​Titanium​​​ 和​​PhoneGap​​​ 允许开发者使用JavaScript开发本地 iOS/Android apps;​​ngCore​​ 更是可以使用纯正的JavaScript构建跨平台的游戏。JavaScript已经成为了编程语言中的佼佼者,也因为更容易学习吸引了众多开发者参与到这一领域。


怎样在IOS/Android上使用JavaScript

主要有两种方法。一种是使用系统的浏览器组件(IOS中的​​UIWebView​​​和Android中的​​WebView​​),另一方法就是使用整合好的JavaScript引擎。

使用系统的浏览器组件比较容易实现但是更复杂,效率也低。 ​​WebView​​​提供了 ​​addJavascriptInterface​​​ 把Java classes注入到JavaScript文本的方法。但是它只支持最原始的几种数据类型,因此也局限了API设计。并且在Android 2.3模拟器上不稳定,在真机上也会遇到 ​​issue #12987​​​的问题。在IOS上更糟 ​​UIWebView​​​没有公共的APIs支持JavaScript到Objective-C的交互(你必须使用似有的APIs才能达到与​​addJavascriptInterface​​相同的功能)。

​​PhoneGap​​​ 是基于 ​​UIWebView​​​ and ​​WebView​​的比较出名的项目。开发者被迫使用回调函数从JavaScript APIs得到返回值。这在游戏上效率极低,也更为复杂。

早期的​​ngCore​​​同样依赖​​UIWebView​​来支持iOS。但是这个机制由于其糟糕的表现被取代。

为了获得更好的表现、灵活性、兼容性,嵌入全功能的JavaScript引擎变得更为有效。


选择JavaScript 引擎


据我所知,iOS 或 android 上能够运行的JavaScript 引擎有4个:  ​​JavaScriptCore​​

,  ​​SpiderMonkey​​

,  ​​V8​​

 and  ​​Rhino​​

.下面这个表格展示各个引擎在iOS 和 Android 的兼容性 



iOS

Android

JavaScriptCore

Interpreter only

Interpreter and JIT

SpiderMonkey

Interpreter only

Interpreter and JIT

V8

JIT only for jailbroken devices

JIT

Rhino

Unsupported

Interpreter


当我设计 

​​OpenAphid-Engine​​

 成为一个合适的Javascript的引擎的时候,我主要考量以下指标: 


  • 兼容性:同时支持iOS 和 Android 在x86 和 ARM 平台上的 模拟器和 设备。
  • 稳定性. 稳定的运行在对应的平台和CPU的架构上。
  • 扩展性. 能够很方便的利用本地特性进行扩展。例如​​OpenAphid-Engine​​ 通过一个桥接层,实现了通过Javascript 进行OpenGL ES 的使用。
  • 性能好:一个快速的Javascript 引擎主要归结为两个因素:有效的绑定机制和进行较低的开销。. ​​OpenAphid-Engine​​ 在渲染一帧页面的时候通过JavaScript触发数百个OpenGL ES调用来进行渲染。这点是非常有意义的,如果只是把开销放到单纯的执行JavaScript上进行将会导致渲染很慢,。
  • 体积小.:在内存的占用上和自身的执行文件上都要比较小。

​​Rhino​​​和 ​​V8​​​出现的最早,但是不支持iOS。我非常希望可以使用 ​​V8​​​开发 ​​OpenAphid-Engine​​​ ,在初次使用时就发现它拥有优雅的代码结构,良好的表现,但是我非常失望,因为 ​​V8​​​只能在JIT模式下使用,而IOS不支持。除非你使用jailbroken设备。(详情请参考 ​​issue #1312​​)

我在​​JavaScriptCore​​​和​​SpiderMonkey​​间纠结了很久。在成功部署了Android和IOS项目后,我通过实验找到更好的一个。

​​SpiderMonkey​​​ 容易得到开发权限,但是在与​​JavaScriptCore​​​比较时甘拜下风。SpiderMonkey产生了大量的二进制文件 (在ARMv7上大约1.3MB);JavaScript执行得更慢,在JavaScript和C++的桥接表现更为重要。另外一个让我远离​​SpiderMonkey​​的原因是在iOS模拟器上出现随机崩溃现象。

JavaScript引擎会受很多东西影响,比如交叉编译器的版本、引擎的版本和操作系统的种类等。下表列举了几种运行在​​iPod Touch 4​​​上引擎的运行时间。(有兴趣请于​​Google Doc​​查看精确的时间)

如何在iOS和Android上选择一个JavaScript 引擎进行应用开发_Android

  • ​​JavaScriptCore​​ 大比分领先。
  • 我没有找到​​SpiderMonkey​​,所以就使用了下面的三种自定义搭建​​Cocos2d-iPhone-2.1-beta4​​, ​​Cocos2d-x-2.1-beta3​​和​​iMonkey​​。
  • 所有测试的apps都基于LLVM 4.1版本,所有的引擎都运行在解释器模式(iOS受限)。
  • 几种基准的介绍:
  • 1m-js_loop执行空循环一百万次。
  • 1m-native_function请求调用一百万次返回undefined的本地函数
  • 1m-js_function跟上面一个相同,只是换成了JavaScript。
  • fib(30)递归的方式计算Fibonacci(30)。
  • sudoku-5用​​这里​​的算法解决Sudoku问题。
  • 1m-native_function ​​JavaScriptCore​​使用可移植的​​C APIs​​实现,当然这不是最有效引入本地函数的方法。
  • ​​SpiderMonkey​​ 在台式电脑上由于高级的JIT追踪方法运行更快,但是在IOS设备上却与之相反。
  • 在大部分的基准上,使用​​iMonkey​​比​​SpiderMonkey​​更快
  • 很明显的,使用​​SpiderMonkey​​将会在iOS上获得更好的表现。​​ngCore​​ 1.10在iOS上加入自定义功能,所以要更优于像​​SpiderMonkey​​这样的变体。

对于JavaScript Code 的挑战

在我专心于 ​​JavaScriptCore​​之后,我的研究更进了一步:

1. 它在运行 一百万 次 native_function和 一百万次Math.abs(0)  的时间六倍于 使用 ​​JavaScriptCore​​.我观察到同样的性能问题出现在通过注入的方式访问对象的属性。


2. 利用  ​​C APIs​​

 进行设计虽然开发简单,但是缺乏灵活的内存管理机制。缺乏一个高级的内部垃圾回收机制很难解决类似于  ​​circular references​​

 的问题。 



3. 众多的 

​​JavaScriptCore​​

 正式版本都是可用的 。 不过  ​​OpenAphid-Engine​​

 是更好的一个,它不但速度快,而且相当小。 

我抛弃了原来的使用 

​​C APIs ​​

方案因此解决了 问题 1 和 2.  使用的JSC 版本来自于iOS4.3.3,因为同样在解析器模式下这个版本相比来自于iOS 5 的版本更快,执行文件更小。 


在其他产品上使用的JS引擎

在开发​​OpenAphid-Engine​​期间,我一直保持对其他引擎的关注,以下这个表格总结了其他JS引擎的使用情况


iOS

Android

ngCore 1.6 and above

UIWebView

V8

ngCore 1.7 and later

SpiderMonkey

V8

Titanium

JavaScriptCore

V8 or Rhino

PhoneGap

UIWebView

WebView

Cocos2D-x JavaScript

SpiderMonkey

SpiderMonkey

CocoonJS

JavaScriptCore

JavaScriptCore

Ejecta

JavaScriptCore

Unsupported

directCanvas

JavaScriptCore

No clue



举报

相关推荐

0 条评论