SafariデスクトップとiOSでメモリをプロファイリングするためのテクニック？
10/21更新：回答（「いいえ」以外）を取得できるように、タイトルと質問を変更しました。
Safariでリークが発生しています（WindowsとMacで確認、iOSで疑われます）。 JavaScript/DOMのメモリ使用量をプロファイルして潜在的なリークを発見できるSafari拡張機能はありますか？さらに良いことに、iOSまたはApple iOSエミュレーターで使用できるツールはありますか？ SafariのJavaScript/DOMでメモリリークを引き起こしている可能性があるものを発見するための推奨テクニックは何ですか？そして、iOSのメモリ情報にアクセスする方法を知っている人はいますか？
背景
単一ページのアプリパラダイムを使用して、数百のフルスクリーン画像をロードするiOS SafariWebアプリケーションを開発しています。画像タグのソースをリセットすることで、通常の6.5MBのiOSSafari画像制限を回避しましたが、iOSSafariのメモリリークであると私が信じている問題に直面しています。 〜250〜300の画像を読み込んだ後、メモリリークが原因で、iOSSafariは画像の読み込みを停止します。 Safari forWindowsとSafarifor Macの両方で同じリークが発生することを考えると、当然のことですが、Windowsでは特にひどいです。新しいフルスクリーンの高解像度画像ごとに、さらに10〜15 MBのメモリが消費されます。低解像度の画像に切り替えると、画像ごとに最大5MBが消費されます。
Windowsでは、ブラウザのビューポートで画像をレンダリングするという単純な行為へのリークを分離しました-画像のカルーセルがあり、DOM操作がゼロの場合でも、ビューポートを介して画像を変換（3d）するだけで、メモリが割り当てられますそして決してリリースされませんでした。 Windowsでは、メモリ消費量が急速に最大1.5 GBに増加する可能性があり、その時点でSafariは単にクラッシュします。 Macの場合はそれほど悪くはありませんが、メモリは最初の100MBから500MB以上に簡単にジャンプします。比較すると、同じページをホストしているChromeタブ/プロセスは約33MBから約120MBに増加し、その後安定します。
試行された回避策
個々の画像タグをリセットするのではなく、削除してプレースホルダー画像に置き換えることを試みましたが、これは問題を軽減するようには見えず、おそらくDOMチャーンが原因でパフォーマンスの問題も引き起こします。興味深いことに、すべての画像の削除/デタッチは機能します-コマンドが実行されるとすぐに、メモリが解放されます。ただし、これには独自の問題が発生し、UI状態の管理、およびカルーセルのバックアップの構築にもかなりの時間がかかります。ページを更新することは別の回避策ですが、それはさらに多くのUXの混乱を引き起こします。
更新04/10：最終的に行ったことの更新：iOS 4.2では、3D変換されたDivを122,900ピクセルでカットオフする制限が導入されました。理由はわかりませんが、以前の静的なフィルムストリップではなく、動的なカルーセルを再構築して使用する必要がありました。
次に、背景画像でdivを使用すると、画像自体よりもうまく機能することがわかりました。これはSafariのさらに別のバグ、またはせいぜい一貫性のない制限の実装のようです。
更新終了
考え？ Safariでリークの疑いがある場合、それらを回避するためのアプローチはどのようなものでしたか？
IOS SDKをインストールすると、Instrumentsという名前のユーティリティもインストールされます。メモリを含むあらゆる種類の使用統計を追跡できます（「リーク」テンプレートもあります）。素晴らしいのは、iPhone/iPadシミュレーターと接続されているiOS開発デバイスの両方を追跡できることです。もちろん、Mac OSのメモリ使用量を監視するためにも使用できるため、Safariでも役立つ場合があります。 Instrumentsは/ Developer/Applicationsにあります。
他に便利なのは、iPad/iPhoneをiTunesと同期するたびに、クラッシュレポートもデバイスからコンピュータに同期することです。それらは〜/ Library/Logs/CrashReporter/MobileDevice/[デバイス名] /にあります。
特にiPad用に開発したときに私たちが見つけた1つのことは、特に私たちのような画像の多いアプリケーションでは、メモリの問題が原因でクラッシュする可能性が非常に高いことでした。私たちが学んだことの1つは、DOM要素を削除しただけでは、その要素がブラウザーによってガベージコレクションされることを意味しないということでした。 DOMから削除する前に、image src（またはdivの場合はbackground-image）を空の文字列に設定すると、非常に役立つことがわかりました。
それが役立つかどうかはわかりませんが、Instrumentsを起動して実行することで、そのすべてのメモリがどこに向かっているのかをよりよく理解できるようになることを願っています。