この質問をすると反対票が出るかもしれませんが、満足のいかない調査を行った後、リスクを冒してより経験豊富な人に尋ねることにしました...
ここには、XCode Analayzer Tool に関連する特定の問題に関する多くの質問があります。それは非常に役立つ解決策のようです。しかし、iOS の世界の初心者として、このツールではどのようなメモリ管理に気付かないのかお聞きしたいと思います。
言い換えれば、iOS の初心者が考えるべき一般的なメモリ管理の側面はありますか。
たとえば、ここで見つけたのは、なぜ XCode 静的アナライザーがリリースされていない保持されたプロパティを検出できないのですか? それ：
(...)アナライザーは、メソッド/ライブラリの境界を越えて保持/解放の問題を確実に検出できません(...)
考慮すべき良いヒントのように聞こえますが、他の一般的な問題について知っているかもしれません...
アナライザーは、非 ARC コードを作成する新しいプログラマーを悩ませるルーチン リーク ( の呼び出しreleaseの失敗、間違った保持カウントのオブジェクトを返すなど) を見つけるのに非常に優れています。
私の経験では、検出されないメモリの問題にはいくつかの種類があります。
通常、強力な参照サイクル(別名保持サイクル) を識別できません。たとえばNSTimer、タイマーがView Controllerへの強力な参照を維持していることに気付かずにView Controllerに繰り返しを追加し、タイマーを使用しない場合invalidate（またはメソッドなどの間違った場所で使用するdealloc場合）、ビューコントローラーもタイマーも解放されません。
循環論理エラーを見つけることができません。たとえば、View Controller A が View Controller B を提示する循環参照がある場合、View Controller B は A の新しいコピーを提示します (破棄/ポップして A に戻るのではなく)。
多くの非参照カウント メモリの問題は見つかりません。Core Foundation 関数の処理は改善されていますが、手動でメモリ割り当てを行うコード ( や などmalloc)freeがある場合、静的アナライザーの使用は制限される可能性があります。非参照カウント コードを使用している場合 (たとえば、SQLite を使用sqlite3_prepare_v2していて の呼び出しに失敗した場合sqlite3_finalize) は常に同じことが当てはまります。
見つからないものの完全なリストではないことは確かですが、これらは静的アナライザーが限られた助けになる Stack Overflow でよくある質問です。しかし、アナライザーは依然として優れたツールであり (メモリの問題以外の問題も検出します)、ARC を使用していない個人にとっては非常に貴重です。
そうは言っても、静的アナライザーは過小評価されている防御の最前線ですが、Instruments を使用してリークを見つける必要があります。Instrumentsユーザーガイドの「アプリ内のメモリ問題の特定」を参照してください。これが漏れを特定する最良の方法です。