[解決済み] メモリ圧迫によるiOSのクラッシュをデバッグする方法

質問

ARCを使用していますが、received memory warningと表示されてアプリがクラッシュしてしまいます。 デバイス（iOS 7.0.2のiPhone 4）上で直接アプリケーションをテストし、iOS 6 SDKを使用してXCode 5でコンパイルしています。 Apple Instrumentsを使用し、20MBのLiveBytesを割り当てています。

4-5分後、私のアプリのメモリは30mbになりました。

コンパイルしてデバイス上でアプリをテストした後、数分後にメモリの警告メッセージの直後にクラッシュすることがわかります。なぜ楽器を使うとクラッシュしないのでしょうか？ しかし、私は1ヶ月間、この問題をクリアしようとしている、物事を正しく取得することはできませんし、私は本当に助けを必要としています。 私は任意のリークを持っていないように見えますが、私は間違っている場所を見つけることができません。 どんなアドバイスでも事前にありがとうございます。

解決方法は？

問題を解決しました。私の場合、メモリの圧迫は、実行ループサイクルによって常にメモリが使用されていることが原因でした。このループは1秒ごとに実行され、解析してビューに表示する必要のあるデータで動作します。もうひとつ、プロジェクトは当初ARCを使用していませんでした。ARCへの変換プロジェクトの後、問題が発生しました。

プロジェクトをARCに変換する前は、ループの最後に、リソースの解放を直接呼び出していました。ARCではもちろんこれは自動的に行われますし、問題はまさにそれです。そこで、ループを実行するクラスのために、私は非ARCバージョンに戻り、私は使用したリソースを解放するために手動で作るためにトリックを使用しました。

自動解放プールブロックは、オブジェクトの所有権を放棄することができますが、（メソッドからオブジェクトを返すときなど）すぐに解放される可能性を回避するためのメカニズムです。通常、自分でオートリリースプールブロックを作成する必要はありませんが、作成しなければならない、あるいは作成した方が有益な状況もあります。

@autoreleasepool {
    // Code that creates autoreleased objects.
}

autorelease pool ブロックの終了時に、ブロック内で autorelease メッセージを受信したオブジェクトは、release メッセージを送信します。

autoreleasepoolブロックはコードの任意のセクションを囲むことができますが、私があなたがやっていると思うようなことは本当にやってはいけません。

オートリリースは、ARCがあなたのためにretainとreleaseの呼び出しを追加するよりもはるかに効率的ではありませんし、潜在的に安全ではありません。Autoreleaseはあなたのオブジェクトをすべてquot;pool"に置き、あなたがスコープ外にいるときやプールをダンプすることを決めたときはいつでも、プールをdrain"してオブジェクトの保持カウントを1だけデクリメントしています。

簡単に言うと Appleのドキュメントやテンプレートに書かれていない限り、@autoreleaseブロックは完全に除外してください（例えば、main.mには@autoreleasepoolがあります）。

つまり、オブジェクトが本当にリリースされる前にリリースされてしまう可能性があるのです。autoreleasepoolブロックは、大量のオブジェクトをインスタンス化して廃棄するような、非常にタイトなループのコードを持っている場合に便利です。例えば、巨大なデータベースを処理し、文字列オブジェクトを割り当て、それらの文字列オブジェクトを使用して、作成したクラスのインスタンスのプロパティを埋めるためのforループです。この場合、ARCはforループの内部でそれらのオブジェクトを確実に解放しない可能性があり、自動解放プールを作成する必要があるかもしれません。

しかし、ARCがタイトなループの中で正しいことをしないのは、あまり一般的ではありません。NSAutoreleasePoolを使用して、それを手動で排出するという、ARC以外の概念に近いものです。

https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/MemoryMgmt/Articles/mmAutoreleasePools.html#//apple_ref/doc/uid/20000047-CJBFBEDI

同じ悩みを持つ方のお役に立てたのなら幸いです。