jsエンジンはjavascriptCoreかv 8かを判断します.
2387 ワード
故事来歴
純粋な退屈さは、JavaScripptCoreとSpiderMonkeyの情報を検索していますが、iosのUICWebViewでは、js解析エンジンの判断方法を勉強していません.
比較
1,iOSではUICbViewコンポーネントのstrigByEveralual teJavascript String:(NSString*)メソッドにより呼び出します.しかし、この方法にはいくつかの弊害があります. 1)oc呼出jsは戻り値があり、同期呼出に属する.js呼び出しocはiframeを作成してsrc、oc端のUICWebVIewブロック要求を設定してからstrigByEveralateJavascriptStringによってjs端を実行する方法で、jsのパラメータ(序列化されたjson文字列)を取得して、oc端で逆序列化を行い、最後にocの関数を呼び出します. 2)oc端のstrigByEveraluteJavascriptStringはjsコードを実行する時jsエンドコードの実行をブロックします. 3)1)の流れを通して、UICWebViewによって実現されたbridgeメカニズムの性能が心配され、インタラクティブな卵痛が見られます. 4)UICWebViewを通じてjsコードセグメントを実行するには、いくつかの制限があります.UnibViewを通じてjavascriptにアクセスする権限が与えられていないため、たとえtringByEveralateJavascriptStringを通じてエラーを実行するjsコードを与えても、私達はocの端でエラーメッセージを取得できません.しかし、この方式のメリットはメモリ管理には関わっていないことです. 2,現在はocとjsの通信を実現する3つの方式があります.第1の方式は引き続きcordvaの通信機構を使います.第二に、React Nativeの通信機構を採用し、iOS 7に内蔵されているjavascriptCoreエンジンを使用して、js、ocの二階に橋渡し層を構築し、各階に同じ配置表を2つ持っています.各テーブルにはjs、ocから漏れたAPIを記録し、iOSのイベント機構を結合して、ocとjsの相互変調を完成します.第三はやはりiOS 7に内蔵されているjavascriptCoreのフレームワークを採用しています.React Nativeとは違って、jscを使用して提供される通信システムです.このメカニズムは、Android下のWebViewコード方式と似ています.oc端はJSExposeプロトコルを実現するだけで、UICWebViewコントロールでも対応するページに切り替わります.文脈は相変わらずで、単一の例として理解できる. 3つの方案を総合して、一番目の価格は最低で、しかも流れは比較的に完備していて、しかもシステム化されていますが、性能は硬傷です.第二の方法は非常に参考になります.RNの方式はjavascriptCoreだけではなく、他のエンジンにも適用されます.Spider Monkeyのように、しかし、RNの方案を採用するには、より多くの時間がかかります.第三の方法は比較的無害であり、かつ達成困難度が大きいとは言えない方案であり、現在まだ化粧iOSではiOS 7以上の設備しか適応していないので、iOS 6及び以下の設備に対応する必要がない(第三者のjavascriptCoreを導入する).また内蔵のjsエンジンとocを使って通信することで、c／c＋レベルでの効率が大幅に向上する.(UICWebviewと比較して)欠点は、現在採用されているbridge通信方式を見直す必要があり、アーキテクチャを再設計することである.
純粋な退屈さは、JavaScripptCoreとSpiderMonkeyの情報を検索していますが、iosのUICWebViewでは、js解析エンジンの判断方法を勉強していません.
if (window.devicePixelRatio) { //If WebKit browser
var st = escape(navigator.javaEnabled.toString());
if (st === 'function%20javaEnabled%28%29%20%7B%20%5Bnative%20code%5D%20%7D') {
document.write('V8 detected');
} else {
document.write('JSC detected');
}
} else {
document.write("Not a WebKit browser");
}比較
1,iOSではUICbViewコンポーネントのstrigByEveralual teJavascript String:(NSString*)メソッドにより呼び出します.しかし、この方法にはいくつかの弊害があります. 1)oc呼出jsは戻り値があり、同期呼出に属する.js呼び出しocはiframeを作成してsrc、oc端のUICWebVIewブロック要求を設定してからstrigByEveralateJavascriptStringによってjs端を実行する方法で、jsのパラメータ(序列化されたjson文字列)を取得して、oc端で逆序列化を行い、最後にocの関数を呼び出します. 2)oc端のstrigByEveraluteJavascriptStringはjsコードを実行する時jsエンドコードの実行をブロックします. 3)1)の流れを通して、UICWebViewによって実現されたbridgeメカニズムの性能が心配され、インタラクティブな卵痛が見られます. 4)UICWebViewを通じてjsコードセグメントを実行するには、いくつかの制限があります.UnibViewを通じてjavascriptにアクセスする権限が与えられていないため、たとえtringByEveralateJavascriptStringを通じてエラーを実行するjsコードを与えても、私達はocの端でエラーメッセージを取得できません.しかし、この方式のメリットはメモリ管理には関わっていないことです. 2,現在はocとjsの通信を実現する3つの方式があります.第1の方式は引き続きcordvaの通信機構を使います.第二に、React Nativeの通信機構を採用し、iOS 7に内蔵されているjavascriptCoreエンジンを使用して、js、ocの二階に橋渡し層を構築し、各階に同じ配置表を2つ持っています.各テーブルにはjs、ocから漏れたAPIを記録し、iOSのイベント機構を結合して、ocとjsの相互変調を完成します.第三はやはりiOS 7に内蔵されているjavascriptCoreのフレームワークを採用しています.React Nativeとは違って、jscを使用して提供される通信システムです.このメカニズムは、Android下のWebViewコード方式と似ています.oc端はJSExposeプロトコルを実現するだけで、UICWebViewコントロールでも対応するページに切り替わります.文脈は相変わらずで、単一の例として理解できる. 3つの方案を総合して、一番目の価格は最低で、しかも流れは比較的に完備していて、しかもシステム化されていますが、性能は硬傷です.第二の方法は非常に参考になります.RNの方式はjavascriptCoreだけではなく、他のエンジンにも適用されます.Spider Monkeyのように、しかし、RNの方案を採用するには、より多くの時間がかかります.第三の方法は比較的無害であり、かつ達成困難度が大きいとは言えない方案であり、現在まだ化粧iOSではiOS 7以上の設備しか適応していないので、iOS 6及び以下の設備に対応する必要がない(第三者のjavascriptCoreを導入する).また内蔵のjsエンジンとocを使って通信することで、c／c＋レベルでの効率が大幅に向上する.(UICWebviewと比較して)欠点は、現在採用されているbridge通信方式を見直す必要があり、アーキテクチャを再設計することである.