iOSのメモリリークはまったく受け入れられますか？

Question

私はObjective-C（Javaから来たもの）が新しく、メモリ管理についてよく理解していると思います。 しかし、私のアプリケーションが読み込まれると、私は非常に小さなメモリリークを取得します。これは、ゲームがロードされているときにのみ発生します（約32〜約512バイト）。

リークするとランダムですが、リークを引き起こすのはユーザーのようではありません。 通常、約20秒〜1分後に検出されます。

私がデバッガから得た情報は決して同じではありません。時にはUIApplication thats "responsible frame"、時には[UIWindow makeKeyAndVisible]であり、時には[UNibDecoder]です。

これは「受け入れられる」制限の下にあるのですか、またはアプリがALLでリークしないようにする必要がありますか？ これは私の最初の「大きな」アプリです。私はマイナーなflipsideviewアプリをやったことがあります。どこに漏れがないのか。

一方、リークを特定する最も良い方法は何ですか？

Answer 1

これは素晴らしいことではありませんが、レビューアの前でクラッシュを引き起こさない限り、アプリが拒否されることはありません。サイズは発生頻度よりも重要ではありません。アプリが実行されるたびに1回しか発生しない場合、大きな問題ではありません。ユーザーが何かをするたびにそれが起こると、それはもっと問題になります。

LLVMのスタティックアナライザは、これらの問題のいくつかを見つけることができます。ビルドをきれいにして、BuildメニューからBuild and Analyzeを選択します。 InstrumentsにはLeaksテンプレートもあります。

Objective Cのメモリ管理はJavaに比べてかなり異なるため、これらのバグを追跡して修正することをお勧めします。小さなもので試してみるとよいでしょう。期限が迫っている巨大な問題をデバッグする。

Answer 2

ライブメモリの使用量が多すぎると、アプリがクラッシュしたり拒否されたりすることがあります。ループ内または繰り返しメソッド内でメモリがリークした場合、リークが最終的に加算され、アプリケーションがクラッシュします。

しかし、ループや繰り返しプロセスではなく、合計量がアプリの一般的なメモリ使用量よりも少ない場合、それは無意味であり、魅力的ではないかもしれませんが、実際には、運用上の欠点はほとんどありません。

アプリの起動時に数メガバイトを故意に "漏らし"、アプリケーションが正常に実行されていることを確認して、アプリをストレステストすることがよくあります。これらのアプリの中には、まだ誤って有効になっているこの漏れテストコードを使ってApp Storeの配布を承認しているものがあります（mia culpa！）。しかし、これは数MBのリークがあっても、アプリの承認に問題がないことを示しています（ただし、メモリ不足のテスト中にアプリがクラッシュすることがない限り）。