怎么在iOS和Android上選擇JavaScript引擎進行應用開發-創新互聯

這篇文章主要介紹“怎么在iOS和Android上選擇JavaScript引擎進行應用開發”，在日常操作中，相信很多人在怎么在iOS和Android上選擇JavaScript引擎進行應用開發問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”怎么在iOS和Android上選擇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引擎進行應用開發

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