35

OpenGL ES を使用して 2D の iPhone ゲームを作成していますが、24 MB のメモリ制限に達し続けています。アプリケーションがエラー コード 101 でクラッシュし続けています。私が期待するよりも大きい。

Memory Monitor、Object Alloc、Leaks、および OpenGL ES インストゥルメントを使用してアプリケーションを実行しました。アプリケーションが読み込まれると、空き物理メモリが 37 MB から 23 MB に減少し、オブジェクトの割り当ては約 7 MB で落ち着き、リークはサイズが数バイトの 2 つまたは 3 つのリークを示し、Gart オブジェクト サイズは約 5 MB であり、メモリ モニターは、アプリケーションは、約 14 MB の実メモリーを占有します。メモリがどこに行ったのか当惑しています。オブジェクトの割り当てを掘り下げると、ほとんどのメモリは予想どおりテクスチャにあります。しかし、私自身のテクスチャ割り当てカウンターと Gart Object Size の両方が、テクスチャが約 5 MB を占めるはずであることに同意しています。

言及する価値のあるものを他に割り当てていることは認識しておらず、Object Alloc も同意しています。記憶はどこへ行く?(これで十分でない場合は、詳細を提供していただければ幸いです。)


更新:私は本当に多くのメモリを割り当てることができる場所を見つけようとしましたが、結果はありませんでした. 私を夢中にさせるのは、オブジェクトの割り当て (~7 MB) とメモリ モニター (~14 MB) で示される実際のメモリ使用量の違いです。私が忘れている巨大なリークや巨大なメモリのチャンクがあったとしても、それは Object Allocationsに表示されるはずですよね?

私はすでに通常の 容疑者を試しました。キャッシングを使用しましたUIImageが、それは役に立ちませんでした。各ステートメントがメモリ使用量に与える影響を監視しながら、メモリ使用量を「デバッガー スタイル」で 1 行ずつ追跡する方法はありますか?


私がこれまでに見つけたもの:

  1. は本当に多くのメモリを使用しています。実際のメモリ消費量を測定するのは簡単ではありませんが、たくさん数えてみると、メモリ消費量は本当に多いと思います。私のせいです。

  2. 使用されたメモリを測定する簡単な方法が見つかりませんでした。メモリ モニタの数値は正確ですが (これらは実際に重要な数値です)、メモリ モニタはメモリがどこにあるのか正確にはわかりません。Object Alloc ツールは、実際のメモリ使用量の追跡にはほとんど役に立ちません。テクスチャを作成すると、割り当てられたメモリ カウンタがしばらく上昇し (テクスチャをメモリに読み込む)、その後低下します (テクスチャ データを OpenGL に渡し、解放します)。これは問題ありませんが、常に発生するとは限りません。テクスチャが OpenGL に渡され、「自分の」メモリから解放された後でも、メモリ使用量が高いままになることがあります。これは、Object Alloc ツールで表示されるように割り当てられたメモリの合計量が、実際の合計メモリ消費量よりも少なく、実際の消費量からテクスチャを差し引いたものよりも大きいことを意味します ( real – textures < object alloc < real)。図に行きます。

  3. プログラミング ガイドを読み間違えました。24 MB のメモリ制限は、アプリケーション全体ではなく、テクスチャとサーフェスに適用されます。実際の赤い線はもう少し先にありますが、明確な数字は見つかりませんでした。コンセンサスは、25 ~ 30 MB が上限であるということです。

  4. システムがメモリ不足になると、メモリ警告の送信を開始します。解放するものはほとんどありませんが、他のアプリケーション、特に Safari (Web サイトをキャッシュしているようです) がメモリを解放してシステムに戻します。メモリ モニタに表示される空きメモリがゼロになると、システムは強制終了を開始します。

弾丸をかじり、コードの一部を書き直して、メモリをより効率的に使用する必要がありましたが、おそらくまだそれを推し進めています。私が別のゲームをデザインするとしたら、リソースのページングを思いつくでしょう。現在のゲームでは、別のスレッドで実行されたとしても、物が常に動いていて、テクスチャのロードが邪魔になるため、非常に困難です。他の人がこの問題をどのように解決するかに非常に興味があります。

これらは私の見解であり、それほど正確である必要はないことに注意してください。このトピックについて何か言いたいことがあれば、質問を更新します。問題を理解している誰かが答えたいと思う場合に備えて、質問を開いたままにします。これらはすべて、他の何よりも回避策と推測であるためです。

4

5 に答える 5

11

これが Instruments のバグであるとは思えません。

まず、openGL テクスチャに関する Jeff Lamarche のブログ投稿をお読みください。

  • リークを引き起こさずにテクスチャをロードする方法の簡単な例があります
  • 「小さい」画像、openGL にロードされた後の取得、実際に「大量の」メモリを使用する方法を理解できます。

抜粋:

テクスチャは、圧縮された画像から作成されたものであっても、使用するにはメモリ内で展開する必要があるため、アプリケーションのメモリ ヒープを大量に使用します。各ピクセルは 4 バイトを使用するため、テクスチャ イメージ データの解放を忘れると、メモリがすぐに食い尽くされる可能性があります。

次に、Instruments を使用してテクスチャ メモリをデバッグできます。OpenGL ES AnalyzerOpenGL ES Driverの 2 つのプロファイリング構成があります。シミュレーターは OpenGL を使用しないため、これらをデバイスで実行する必要があります。XCode から Product->Profile を選択し、Instruments が起動したらこれらのプロファイルを探すだけです。


その知識を武器に、これが私がすることです:

  • メモリ リークが発生していないことを確認してください。これにより、明らかにこの問題が発生します。
  • クラッシュの一般的な原因である、自動解放されたメモリにアクセスしていないことを確認してください。
  • 別のテスト アプリを作成し、テクスチャを個別に (または組み合わせて) 読み込んで再生し、どのテクスチャ (またはそれらの組み合わせ) が問題を引き起こしているかを調べます。

更新:あなたの質問について考えた後、私はApple の OpenGL ES Programming Guideを読みましたが、非常に良い情報が含まれています。強くお勧めします!

于 2010-03-19T08:28:08.780 に答える
3

1 つの方法は、コードをコメントアウトして、バグがまだ発生するかどうかを確認することです。はい、それは退屈で初歩的ですが、バグがどこにあるかを知っていれば役立つかもしれません.

クラッシュしている場所は、クラッシュしている理由などです。

于 2008-12-16T01:15:02.767 に答える
2

うーん、それは多くの詳細ではありませんが、リークがリークの場所を示していない場合は、2つの重要なオプションがあります。

[i]リークがリークを見逃した[ii]メモリが実際にリークされていない

[i]を修正するのは非常に難しいですが、Eric Albertが言ったように、Appleにバグレポートを提出することは役に立ちます。[ii]は、使用しているメモリがまだどこかでアクセス可能であることを意味しますが、おそらくそれを忘れているでしょう。古いエントリを破棄せずにリストが増えていますか?たくさんrealloc()されているバッファはありますか?

于 2008-12-13T23:41:53.890 に答える
2

2012年以降にこれを見る人のために:

デバイスの物理メモリに実際にロードされるメモリは、VM Tracker Instrument の常駐メモリです。

Allocation Instrument は、malloc/[NSObject alloc] と一部のフレームワーク バッファによって作成されたメモリのみをマークします。

WWDC 2012 Session 242 iOS App Performance: Memory を視聴して、Apple から情報を入手してください。

于 2013-08-22T01:56:03.723 に答える
0

これは特に役に立ちませんが、メモリ ツールが必要なすべてのデータを提供しないことに気付いた場合は、bugreport.apple.com でバグを報告してください。アプリのコピーと、ツールがどのように分析を下回っているかの説明を添付してください。Apple は、ツールを改善できるかどうかを確認します。ありがとう!

于 2008-12-12T19:56:41.010 に答える