怎么在iOS和Android上選擇JavaScript引擎進行應用開發(fā)

這篇文章主要介紹“怎么在iOS和Android上選擇JavaScript引擎進行應用開發(fā)”，在日常操作中，相信很多人在怎么在iOS和Android上選擇JavaScript引擎進行應用開發(fā)問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”怎么在iOS和Android上選擇JavaScript引擎進行應用開發(fā)”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！

怎樣在IOS/Android上使用JavaScript

主要有兩種方法。一種是使用系統(tǒng)的瀏覽器組件（IOS中的UIWebView和Android中的WebView），另一方法就是使用整合好的JavaScript引擎。

使用系統(tǒng)的瀏覽器組件比較容易實現(xiàn)但是更復雜，效率也低。 WebView提供了 addJavascriptInterface 把Java
classes注入到JavaScript文本的方法。但是它只支持最原始的幾種數(shù)據(jù)類型，因此也局限了API設計。并且在Android 2.3模擬器上不穩(wěn)定，在真機上也會遇到 issue
#12987的問題。在IOS上更糟 UIWebView沒有公共的APIs支持JavaScript到Objective-C的交互(你必須使用似有的APIs才能達到與addJavascriptInterface相同的功能)。

PhoneGap 是基于 UIWebView and WebView的比較出名的項目。開發(fā)者被迫使用回調函數(shù)從JavaScript
APIs得到返回值。這在游戲上效率極低，也更為復雜。

早期的ngCore同樣依賴UIWebView來支持iOS。但是這個機制由于其糟糕的表現(xiàn)被取代。

為了獲得更好的表現(xiàn)、靈活性、兼容性，嵌入全功能的JavaScript引擎變得更為有效。

據(jù)我所知，iOS 或 android 上能夠運行的JavaScript 引擎有4個： JavaScriptCore, SpiderMonkey, V8 and Rhino.下面這個表格展示各個引擎在iOS
和 Android 的兼容性 

當我設計 OpenAphid-Engine 成為一個合適的Javascript的引擎的時候，我主要考量以下指標： 

• 兼容性：同時支持iOS 和 Android 在x86 和 ARM 平臺上的 模擬器和 設備。

• 穩(wěn)定性. 穩(wěn)定的運行在對應的平臺和CPU的架構上。

• 擴展性. 能夠很方便的利用本地特性進行擴展。例如OpenAphid-Engine 通過一個橋接層，實現(xiàn)了通過Javascript 進行OpenGL
  ES 的使用。

• 性能好：一個快速的Javascript 引擎主要歸結為兩個因素：有效的綁定機制和進行較低的開銷。. OpenAphid-Engine 在渲染一幀頁面的時候通過JavaScript觸發(fā)數(shù)百個OpenGL
  ES調用來進行渲染。這點是非常有意義的，如果只是把開銷放到單純的執(zhí)行JavaScript上進行將會導致渲染很慢，。
  

• 體積小.：在內存的占用上和自身的執(zhí)行文件上都要比較小。

Rhino和 V8出現(xiàn)的最早，但是不支持iOS。我非常希望可以使用 V8開發(fā) OpenAphid-Engine ，在初次使用時就發(fā)現(xiàn)它擁有優(yōu)雅的代碼結構，良好的表現(xiàn)，但是我非常失望，因為 V8只能在JIT模式下使用，而IOS不支持。除非你使用jailbroken設備。（詳情請參考 issue
#1312)

我在JavaScriptCore和SpiderMonkey間糾結了很久。在成功部署了Android和IOS項目后，我通過實驗找到更好的一個。

SpiderMonkey 容易得到開發(fā)權限，但是在與JavaScriptCore比較時甘拜下風。SpiderMonkey產生了大量的二進制文件
(在ARMv7上大約1.3MB)；JavaScript執(zhí)行得更慢，在JavaScript和C++的橋接表現(xiàn)更為重要。另外一個讓我遠離SpiderMonkey的原因是在iOS模擬器上出現(xiàn)隨機崩潰現(xiàn)象。

JavaScript引擎會受很多東西影響，比如交叉編譯器的版本、引擎的版本和操作系統(tǒng)的種類等。下表列舉了幾種運行在iPod Touch 4上引擎的運行時間。（有興趣請于Google
Doc查看精確的時間）

• JavaScriptCore 大比分領先。

• 我沒有找到SpiderMonkey，所以就使用了下面的三種自定義搭建Cocos2d-iPhone-2.1-beta4， Cocos2d-x-2.1-beta3和iMonkey。

• 所有測試的apps都基于LLVM 4.1版本，所有的引擎都運行在解釋器模式（iOS受限）。

• 幾種基準的介紹:

• 1m-js_loop執(zhí)行空循環(huán)一百萬次。

• 1m-native_function請求調用一百萬次返回undefined的本地函數(shù)

• 1m-js_function跟上面一個相同，只是換成了JavaScript。

• fib(30)遞歸的方式計算Fibonacci(30)。

• sudoku-5用這里的算法解決Sudoku問題。

• 1m-native_function JavaScriptCore使用可移植的C
  APIs實現(xiàn)，當然這不是最有效引入本地函數(shù)的方法。

• SpiderMonkey 在臺式電腦上由于高級的JIT追蹤方法運行更快，但是在IOS設備上卻與之相反。

• 在大部分的基準上，使用iMonkey比SpiderMonkey更快

• 很明顯的，使用SpiderMonkey將會在iOS上獲得更好的表現(xiàn)。ngCore 1.10在iOS上加入自定義功能，所以要更優(yōu)于像SpiderMonkey這樣的變體。

對于JavaScript Code 的挑戰(zhàn)

在我專心于 JavaScriptCore之后，我的研究更進了一步：

1. 它在運行 一百萬 次 native_function和 一百萬次Math.abs(0)  的時間六倍于 使用 JavaScriptCore.我觀察到同樣的性能問題出現(xiàn)在通過注入的方式訪問對象的屬性。

2. 利用 C
APIs 進行設計雖然開發(fā)簡單，但是缺乏靈活的內存管理機制。缺乏一個高級的內部垃圾回收機制很難解決類似于 circular
references 的問題。 

3. 眾多的 JavaScriptCore 正式版本都是可用的
。 不過 OpenAphid-Engine 是更好的一個，它不但速度快，而且相當小。 

我拋棄了原來的使用 C
APIs 方案因此解決了 問題 1 和 2.  使用的JSC 版本來自于iOS4.3.3，因為同樣在解析器模式下這個版本相比來自于iOS 5 的版本更快，執(zhí)行文件更小。 

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

在開發(fā)OpenAphid-Engine期間，我一直保持對其他引擎的關注，以下這個表格總結了其他JS引擎的使用情況

到此，關于“怎么在iOS和Android上選擇JavaScript引擎進行應用開發(fā)”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續(xù)學習更多相關知識，請繼續(xù)關注億速云網站，小編會繼續(xù)努力為大家?guī)砀鄬嵱玫奈恼拢?/p>