4

私は Instrument のメモリ使用量の追跡について多くのことを読んできましたが、Monotouch との組み合わせはほとんど見つかりませんでした。

ここには 3 つの相反する主張があるようです。

  1. InstrumentsのAllocationユーティリティを使用します。「ライブ バイト」の数は、アプリケーションによって使用される物理メモリの量です。
  2. メモリ モニタープラグインを使用します。プロセスのリストからアプリを選択し、[実メモリ] 列を確認します。これは、現在使用中の RAM の量です。
  3. VM トラッカーを使用して、自動スナップショットを作成します。あなたが求めているものなら「ダーティサイズ」。

私が気づいたことから：

  • GC がトリガーされるとすぐに「リアル メモリ」が低下する
  • 「Live Bytes」が約 30MB のままであっても、最終的にはメモリ警告が表示されます
  • 「Live Bytes」が一定の場合、「Real Memory」は大幅に増加し、簡単に 200MB 以上に増加します。
  • QLPreviewController を使用して非常に大きな Word ドキュメント (1000 ページ) を表示しているときに、そのドキュメントをスクロールすると、実際のメモリが狂ったように増加します。メモリ警告が受信された場合、実メモリもライブ バイトもドロップしません。最終的に、アプリはクラッシュします。Monotouch の問題か、Apple の問題か?
  • ときどき、実記憶が増大しているように見え、それを止めることはできません。繰り返しになりますが、GC はその大きなチャンクをクリアしているようです。これには実際のパターンはありません。

それで、正しい答えは何ですか？正確に1つありますか？

編集：2つの画像を添付しました。アプリの寿命の途中の段階でのメモリ使用量と、それ以降の秒数を示すもの。両方の画像は、画面上に 2 つのコントローラーしかない UI の同じポイントでのメモリ使用量を反映しています。たぶん、誰かがそれらの番号から読み取れるもの、特に魔法の「メモリータグ70」についてコメントできるかもしれません.

ここに画像の説明を入力 ここに画像の説明を入力

4

1 に答える 1

3

楽器はややブラックボックスですが、これが私がどう思うかです：

ここには3つの反対の主張があるようです
。1。Instrumentsの*Allocation*sユーティリティを使用します。「ライブバイト」の数は、アプリケーションによって使用される物理メモリの量です。

「LiveBytes」とは正確にはわかりませんが、アプリケーションで使用される物理メモリの量ではありません。これは、すべてのObjectiveCオブジェクトで使用される物理メモリの量だと思います（この理論が正しければ、「Live Bytes」には、マネージコードで使用されるメモリも、ObjectiveCオブジェクト（画像データなど）で間接的に使用されるメモリも含まれません。本当のようです）。「LiveBytes」は、リークされたオブジェクトを追跡する場合に非常に役立ちますが、実際に使用されているメモリの量を示す良い指標ではありません（必然的に）。

2。メモリモニタープラグインを使用します。プロセスのリストからアプリを選択し、[リアルメモリ]列を確認します。これは、現在使用されているRAMの量です。

これはもう少し近いです。「RealMem」は、他のアプリと共有されていない、アプリが使用している物理メモリの量です。アプリが使用している物理メモリの合計量は「VirtualMem」ですが、「Virtual Mem」の大きなチャンクはアプリ間で共有されます（つまり、共有ライブラリは、メモリに読み込まれるときにもちろんメモリを使用しますが、不変であるため、すべてのプロセスに対して1回だけロードされます。ただし、各プロセスの「仮想メモリ」に追加されるため、すべてのプロセスで使用される「仮想メモリ」を合計すると、デバイスにある実際の物理メモリをはるかに超えます）。

3。VM Trackerを使用して、自動スナップショットを作成します。あなたが求めているものなら「ダーティサイズ」。

正しい。「ダーティサイズ」はあなたが求めているものです。ただし、これは「Real Mem」と密接に関連しています。これは、「Real Mem」をカテゴリに分割しているため、メモリの使用状況を簡単に確認できます。

画像のリークが原因で大量のメモリを使用する一般的なケースの場合、プロセスは次のようになり
ます。1.アプリに実際にメモリの問題があることをメモリモニターで確認します。
2. VMトラッカー/「ダーティサイズ」で、画像データによって大量のメモリが使用されていることを確認します（これが魔法の「メモリタグ70」です）。
3.割り当てを使用して、CGImageが作成された場所を見つけ、対応するスタックトレースを確認し、それらのイメージが解放されない理由を追跡します。

ただし、アプリはそれぞれ異なるため、すべての場合に機能する短いレシピを思いつくことはできません。

  • GCがトリガーされるとすぐに「リアルメモリ」がドロップします
  • 「ライブバイト」が約30MBのままであっても、最終的にはメモリの警告が表示されます
  • 一定の「ライブバイト」を使用すると、「リアルメモリ」は大幅に増加し、200MB以上に簡単に拡張できます。

これらはすべて上で説明されています。

  • QLPreviewControllerを使用し、非常に大きなWordドキュメント（1000ページ）を表示しているときに、そのドキュメントをスクロールすると、実際のメモリが狂ったように大きくなります。メモリ警告を受信した場合、実際のメモリもライブバイトもまったくドロップしません。最終的に、アプリはクラッシュします。モノタッチの問題ですか、それともアップルの問題ですか？

それもあなたの問題かもしれません:)メモリがどこに行くのかを実際に知らずに言うことは不可能です。

  • 時々、本当の記憶は成長しているように見え、何もそれを止めることはできません。繰り返しになりますが、GCはその大きな塊をクリアしているようです。これには実際のパターンはありません。

アプリがまったく何もしていないときに、実際のメモリが増加するのを見ているということですか？アプリで実際に何かをしている場合、これは完全に正常です。

于 2012-05-02T10:44:12.917 に答える