在我开始使用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引擎: JavaScriptCore, SpiderMonkey, V8Rhino。下表显示了在iOS和Android的兼容性。

iOS Android
JavaScriptCore Interpreter only Interpreter and JIT
SpiderMonkey Interpreter only JIT
Rhino Unsupported Interpreter
V8 JIT only for jailbroken devices Interpreter and JIT

当我为OpenAphid-Engine选择正确的JavaScript引擎时,我是以以下几点作为评估标准:

  • 兼容性:引擎必须同时兼容Android和IOS;既可以在虚拟机上运行,也可以在真机上运行;既支持ARM,也支持X86。
  • 稳定性:在平台和CPU结构下都可以运行。
  • 拓展性:很容易添加本地特性。比如说,OpenAphid-Engine需要一个连接OpenGL ES和JavaScript的中间件。
  • (良好的)表现:简单概括为两点:快速执行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查看精确的时间)
benchmark on iPod Touch4(smaller is Better)
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