Web ページを開くために UIWebView を使用するブラウザ アプリケーションに取り組んでいます。私はメモリ モニターで Instruments ツールを実行します。Instruments で使用されている用語と、それらが重要である理由に完全に混乱しています。私の質問のいくつかを適切な理由とともに説明してください:
Live Bytes は、メモリの最適化やメモリ消費のチェックに重要ですか? なんで ？
解放されたオブジェクトも含まれている場合、全体のバイト数/実メモリを気にする必要があるのはなぜですか?
これらの用語 (ライブ バイト/全体のバイト/実メモリ) はいつ、どのような理由で使用されますか?
ありがとう
「Live Bytes」とは、「割り当てられているがまだ割り当て解除されていないメモリ」を意味します。これは、「アプリが使用しているメモリ量」を最も簡単に把握できる指標であるため、重要です。
「全体のバイト数」は、「割り当て解除されたメモリを含む、これまでに割り当てられたすべてのメモリ」を意味します。これはあまり役に立ちませんが、「ヒープ チャーン」についてのアイデアを得ることができます。チャーンは断片化につながり、ヒープの断片化は問題になる可能性があります (最近ではかなりあいまいなものですが)。
「Real Memory」は、(有効なアドレス空間のバイト数とは対照的に) 使用中の物理 RAM の量を区別しようとする試みです。これは「Live Bytes」とは異なります。「Live Bytes」には、現在物理 RAM にページングされていないメモリ マップ ファイル (または共有メモリ、ウィンドウ バッキング ストアなど) に対応するメモリの範囲が含まれる可能性があるためです。メモリ マップト ファイルやその他のエキゾチックな VM 割り当て方法を使用しない場合でも、システム フレームワークが使用するため、この区別はすべてのプロセスにとって常に重要です。
編集: UIWebViewを使用することで発生するメモリ使用量について明らかに懸念しているので、それを明らかにできるかどうか見てみましょう:
UIWebView をまったく使用するには、特定のメモリ「価格」があります (つまり、グローバル キャッシュなど)。これらには、さまざまなグローバル フォント キャッシュ、JavaScript JIT キャッシュなどが含まれます。これらのほとんどはシングルトンのように動作します。最初に使用するときに割り当てられ (UIWebView を使用して間接的に)、プロセスが終了するまで割り当てが解除されることはありません。いくつかの可変サイズのグローバル キャッシュ (Web 応答をキャッシュするものなど。通常は CFURL がこれらを管理します) もありますが、それらはシステムによって管理されることが期待されます。これまで見てきたように、UIWebView に関するこれらの要素の集合的な「重み」は重要です。
私は UIKit や WebKit の内部についての知識はありませんが、「UIWebView を使用するとメモリが大量に消費されるのはなぜですか?」という質問に対して、実際に使用したことがある人と話し合った場合の回答を期待します。最初のプロングは、「これは UIWebView を使用するための入場料です。基本的には、プロセス内で Web ブラウザー全体を実行するようなものです。」2番目のプロングは、「システムフレームワークキャッシュはシステムによって自動的に管理される」であり、たとえば、CFURLキャッシュ（UIWebViewを使用して作成されるものの1つ）がシステムによって管理されることを意味します。そのため、メモリの警告が発生した場合、システム フレームワークはそれらのキャッシュから何かを削除して、それらが消費するメモリを削減する責任があります。あなたはそれらを制御することはできません。システム フレームワークが必要なことを実行してくれることを信頼する必要があります。(これは、システム キャッシュ マネージャーが何をしても十分に攻撃的でない場合には役に立ちませんが、それらをこれ以上制御することはできないため、別の角度から問題に取り組む必要があります。 UIWebView の割り当てを解除してもメモリ使用量が下がらない理由を知りたい場合は、これが答えです。舞台裏では、制御できないことがたくさんあります。UIWebView の割り当てを解除してもメモリ使用量が下がらない理由を知りたい場合は、これが答えです。舞台裏では、制御できないことがたくさんあります。UIWebView の割り当てを解除してもメモリ使用量が下がらない理由を知りたい場合は、これが答えです。舞台裏では、制御できないことがたくさんあります。
UIWebView の割り当て、使用、および割り当て解除が正味ゼロの操作であるという期待は、いくつかの重要で固有の避けられない副作用を無視します。このような副作用の存在は、(それ自体で) UIWebView のバグを示すものではありません。このような副作用があちこちにあります。実行ループの 1 回のスピン後に起動して終了するだけの単純なアプリケーションを作成し、 にブレークポイントを設定しexit()、割り当てられたが解放されなかったメモリを調べた場合、何千もの割り当てが存在することになります。 . これは、システム フレームワーク全体およびほぼすべてのアプリケーションで使用される非常に一般的なパターンです。
これはあなたにとって何を意味しますか？これは、実質的に 2 つの選択肢があることを意味します。UIWebView を使用してメモリ消費の「入場料」を支払うか、UIWebView を使用しないかです。