0

そのため、アプリはスタック トレースや例外なしでクラッシュし、毎回このクラッシュを再現できました。私が最初に考えたのは、これは 2 回のリリースでなければならないということでした。ゾンビを 10 分間実行した後、アプリをクラッシュさせることは一度もありませんでした。

Allocations を見た後、メソッドが呼び出されると、割り当てられたオブジェクトのサイズが大幅に増加することに気付きました。そのため、for ループ内に @autoreleasePool を配置することになりました。この自動解放プールはクラッシュを修正しました。しかし、これが本当にメモリ不足の問題であることを確認するにはどうすればよいですか? (didRecieveMemoryWarning はクラッシュ前に呼び出されませんでした)

autoreleasePool が問題を解決するのはなぜですか?

didRecieveMemoryWarning が呼び出されないのはなぜですか? 現在の実行ループの最後に到達する前に、アプリケーションがメモリを使い果たしたためでしょうか?

- (void)doSomething
{

   for (Item *item in self.items)
   {
      @autoreleasepool
      {
         // A bunch of initializations here that take a lot of memory
      }
   }

}
4

3 に答える 3

4

Instruments を使用して割り当てを監視し、自動解放プールなしで増加するかどうかを確認します。

クラッシュが特に速く発生した場合、またはメモリ通知が発生するキューをブロックしている場合、通知は表示されません。

初期化の一部として作成された自動解放されたオブジェクトが大量にあるため、自動解放が問題を修正している可能性が最も高いです。ループが終了するまで、プールは排出されません。

于 2012-08-20T19:43:19.920 に答える
0

didRecieveMemoryWarning は非同期的に呼び出されません。メイン スレッドは、didRecieveMemoryWarning の呼び出しである可能性がある次のイベントを取得するために NSRunLoop に戻る必要があります。さらに、自動解放プール上のすべてのオブジェクトをクリーンアップすることはできなかったとしても、問題が多くの自動解放プールのものである場合、多くのことを行うことができるとは思えません。

于 2012-08-21T04:19:35.957 に答える
-1

これは UIApplicationMain の同じスレッドで実行されていますか? for スコープは alloc/init で多くのオブジェクトを割り当てますか? ARC は有効になっていますか?

@autorelease プールは、/ [NSString stringWithFormat:"%@",format] / [[[NSObject alloc] init] autorelease] / [[[NSObject alloc] init] autorelease] / [NSString stringWithFormat:"%@",format] / [NSString stringWithFormat:"%@",format] /のように、init への明示的な呼び出しなしで割り当てられたオブジェクトを担当するヒープの一部です。.

ループの最後に到達するたびに、[プールのドレイン] が実行され、そのスコープ内で静的に割り当てられたオブジェクトが解放されるため、問題は解消されたはずです。別のスレッドを作成してこの割り当てを実行し、その間にメイン スレッドを一時停止することをお勧めします (おそらく UIAlertView を使用しますか?)。別の autoreleasepool 内に autoreleasepool を作成すると、2 番目が最初のプールにスタックする可能性があり、アプリケーションの最後にのみ解放されます。それが役に立てば幸い。

于 2012-08-20T19:55:01.473 に答える