情報を広範囲にわたって調べ、決定的なリストを見つけていません。観察を追加してください。きっと重宝することでしょう。
Nitro Javascriptエンジンはありません。これにより、Safariと比較して、UIWebViewでのJavaScriptの実行がはるかに遅くなります。
http://www.tuaw.com/2011/03/18/Apple-confirms-some-webkit-optimizations-unavailable-to-ios-apps/
http://ariya.ofilabs.com/2012/06/nitro-javascriptcore-and-jit.html
私が見つけた1つのことは、一時的な悲しみに対して、JSを介してスタイル値を設定するときのUIWebView
の方が少し厳しいということです。モバイルサファリで言う
element.style.width = 300;
正常に動作しますが、UIWebView
では値を次のように設定する必要があります
element.style.width = 300 + "px";
私がゆっくりと発見している他の違いがあります。私はこれを更新します。
UIWebViewがそのコンテンツをスクロールすると、スクロールが終了するまですべてのJavaScriptイベントがフリーズします。だからあなたは絶対に できない この一般的な方法のように、プログラムでスクロールプロセスを監視または制御します。
window.onscroll = function() {
var scrolled = window.pageYOffset || document.documentElement.scrollTop;
// do something
}
変数 'scrolled'は、スクロールが完全に終了した後に1回だけ更新されるためです。
Mobile SafariのHTML5 SQLの初期最大サイズを50MBに設定できますが、UIWebViewは5MBに制限されているようです。それ以上は拒否します。
私が遭遇した2つの明らかなものは、認証とフレーム付きページです。
認証の場合、UIWebViewは認証チャレンジを自動的に処理しません。それらを処理するのは開発者の責任です。
フレームセットを含むページの場合、UIWebViewはフレーム内のページ遷移の閲覧履歴を追跡しません。これは望ましい機能です。これを達成するには少し手を加える必要があります。
パフォーマンスに関しては、これはあなたが見つけそうな最良の要約です: http://www.guypo.com/mobile/ios-browsers-speed-bakeoff/