第一部分:如何在iOS和Android上选择一个JavaScript 引擎进行应用开发
英文原文：PartI:HowtoChooseaJavaScriptEngineforiOSandAndroidDevelopment
在我开始使用OpenAphid-Engine的时候，已经有几种类似的iOS/Android项目.这些商业项目或者开源项目使用JavaScript实现代码特性。比如，Titanium和PhoneGap允许开发者使用JavaScript开发本地iOS/Androidapps;ngCore更是可以使用纯正的JavaScript构建跨平台的游戏。JavaScript已经成为了编程语言中的佼佼者，也因为更容易学习吸引了众多开发者参与到这一领域。
Naixjs
翻译于1个月前
0人顶
顶翻译的不错哦!
怎样在IOS/Android上使用JavaScript
主要有两种方法。一种是使用系统的浏览器组件（IOS中的UIWebView和Android中的WebView），另一方法就是使用整合好的JavaScript引擎。
使用系统的浏览器组件比较容易实现但是更复杂，效率也低。WebView提供了addJavascriptInterface把Javaclasses注入到JavaScript文本的方法。但是它只支持最原始的几种数据类型，因此也局限了API设计。并且在Android2.3模拟器上不稳定，在真机上也会遇到issue#12987的问题。在IOS上更糟UIWebView没有公共的APIs支持JavaScript到Objective-C的交互(你必须使用似有的APIs才能达到与addJavascriptInterface相同的功能)。
Naixjs
翻译于1个月前
0人顶
顶翻译的不错哦!
PhoneGap是基于UIWebViewandWebView的比较出名的项目。开发者被迫使用回调函数从JavaScriptAPIs得到返回值。这在游戏上效率极低，也更为复杂。
早期的ngCore同样依赖UIWebView来支持iOS。但是这个机制由于其糟糕的表现被取代。
为了获得更好的表现、灵活性、兼容性，嵌入全功能的JavaScript引擎变得更为有效。
Naixjs
翻译于1个月前
0人顶
顶翻译的不错哦!
选择JavaScript引擎
据我所知，iOS或android上能够运行的JavaScript引擎有4个：JavaScriptCore,SpiderMonkey,V8andRhino.下面这个表格展示各个引擎在iOS和Android的兼容性
iOSAndroid
JavaScriptCoreInterpreteronlyInterpreterandJIT
SpiderMonkeyInterpreteronlyInterpreterandJIT
V8JITonlyforjailbrokendevicesJIT
RhinoUnsupportedInterpreter
当我设计OpenAphid-Engine成为一个合适的Javascript的引擎的时候，我主要考量以下指标：
兼容性：同时支持iOS和Android在x86和ARM平台上的模拟器和设备。
稳定性.稳定的运行在对应的平台和CPU的架构上。
扩展性.能够很方便的利用本地特性进行扩展。例如OpenAphid-Engine通过一个桥接层，实现了通过Javascript进行OpenGLES的使用。
性能好：一个快速的Javascript引擎主要归结为两个因素：有效的绑定机制和进行较低的开销。.OpenAphid-Engine在渲染一帧页面的时候通过JavaScript触发数百个OpenGLES调用来进行渲染。这点是非常有意义的，如果只是把开销放到单纯的执行JavaScript上进行将会导致渲染很慢，。
体积小.：在内存的占用上和自身的执行文件上都要比较小。
打杂程序猿
翻译于1个月前
1人顶
顶翻译的不错哦!
其它翻译版本(1)
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模拟器上出现随机崩溃现象。
Naixjs
翻译于1个月前
0人顶
顶翻译的不错哦!
JavaScript引擎会受很多东西影响，比如交叉编译器的版本、引擎的版本和操作系统的种类等。下表列举了几种运行在iPodTouch4上引擎的运行时间。（有兴趣请于GoogleDoc查看精确的时间）
JavaScriptCore大比分领先。
我没有找到SpiderMonkey，所以就使用了下面的三种自定义搭建Cocos2d-iPhone-2.1-beta4，Cocos2d-x-2.1-beta3和iMonkey。
所有测试的apps都基于LLVM4.1版本，所有的引擎都运行在解释器模式（iOS受限）。
几种基准的介绍:
1m-js_loop执行空循环一百万次。
1m-native_function请求调用一百万次返回undefined的本地函数
1m-js_function跟上面一个相同，只是换成了JavaScript。
fib(30)递归的方式计算Fibonacci(30)。
sudoku-5用这里的算法解决Sudoku问题。
1m-native_functionJavaScriptCore使用可移植的CAPIs实现，当然这不是最有效引入本地函数的方法。
SpiderMonkey在台式电脑上由于高级的JIT追踪方法运行更快，但是在IOS设备上却与之相反。
在大部分的基准上，使用iMonkey比SpiderMonkey更快
很明显的，使用SpiderMonkey将会在iOS上获得更好的表现。ngCore1.10在iOS上加入自定义功能，所以要更优于像SpiderMonkey这样的变体。
Naixjs
翻译于1个月前
0人顶
顶翻译的不错哦!
对于JavaScriptCode的挑战
在我专心于JavaScriptCore之后，我的研究更进了一步：
1.它在运行一百万次native_function和一百万次Math.abs(0)的时间六倍于使用JavaScriptCore.我观察到同样的性能问题出现在通过注入的方式访问对象的属性。
2.利用CAPIs进行设计虽然开发简单，但是缺乏灵活的内存管理机制。缺乏一个高级的内部垃圾回收机制很难解决类似于circularreferences的问题。
3.众多的JavaScriptCore正式版本都是可用的。不过OpenAphid-Engine是更好的一个，它不但速度快，而且相当小。
我抛弃了原来的使用CAPIs方案因此解决了问题1和2.使用的JSC版本来自于iOS4.3.3，因为同样在解析器模式下这个版本相比来自于iOS5的版本更快，执行文件更小。
打杂程序猿
翻译于1个月前
0人顶
顶翻译的不错哦!
在其他产品上使用的JS引擎
在开发OpenAphid-Engine期间，我一直保持对其他引擎的关注，以下这个表格总结了其他JS引擎的使用情况
iOSAndroid
ngCore1.6andaboveUIWebViewV8
ngCore1.7andlaterSpiderMonkeyV8
TitaniumJavaScriptCoreV8orRhino
PhoneGapUIWebViewWebView
Cocos2D-xJavaScriptSpiderMonkeySpiderMonkey
CocoonJSJavaScriptCoreJavaScriptCore
EjectaJavaScriptCoreUnsupported
directCanvasJavaScriptCoreNoclue
接下来的事
我将对照ngCore把我自己的想法放到OpenAphid-Engine.请期待！