メモリ (およびリソース) リークが発生します。彼らがそうしないことをどのように確認しますか？
そもそもメモリリークの発生を避けるために、どのようなヒントとテクニックを提案しますか?
リークしているアプリケーションを入手したら、リークの原因をどのように突き止めますか?
（ああ、「GCを使用するだけ」の回答は避けてください。iPhoneがGCをサポートするまで、これは有効な回答ではありません。それでも、GCでリソースとメモリをリークする可能性があります）
10866 次
9 に答える
21
XCode 4.5では、組み込みのStaticAnalyzerを使用します。
3.3より前のバージョンのXCodeでは、静的アナライザーをダウンロードする必要がある場合があります。これらのリンクは、その方法を示しています。
LLVM/Clang静的アナライザーを使用する
そもそもメモリリークが発生しないようにするには、Clang Static Analyzerを使用して、当然のことながら、Mac OS X 10.5でCおよびObjective-Cコード（C ++はまだありません）を分析します。インストールして使用するのは簡単です。
- このページから最新バージョンをダウンロードしてください。
- コマンドラインから
cdプロジェクトディレクトリへ。 - 実行し
scan-build -k -V xcodebuildます。
（いくつかの追加の制約などがあります。特に、「デバッグ」構成でプロジェクトを分析する必要があります。詳細については、 http：//clang.llvm.org/StaticAnalysisUsage.htmlを参照してください。ただし、それは多かれ少なかれです。要約すると）
次に、アナライザーは、コンパイラーが検出できない可能性のあるメモリー管理およびその他の基本的な問題を示す一連のWebページを生成します。
プロジェクトがMacOSXデスクトップを対象としていない場合は、他にもいくつかの詳細があります。
- すべての構成のベースSDKをMacOSXデスクトップフレームワークを使用するSDKに設定します...
- デバッグ構成を使用するようにコマンドラインビルドを設定します。
（これは、この質問に対する回答とほぼ同じです。）
于 2008-10-05T16:39:28.153 に答える
16
メモリ管理を考えすぎないでください
何らかの理由で、多くの開発者（特に初期の段階）は、問題を考えすぎたり、問題が実際よりも複雑であると想像したりすることで、メモリ管理を必要以上に困難にしています。
基本的なルールは非常に単純です。あなたはそれらに従うことに集中するべきです。他のオブジェクトが何をする可能性があるか、またはオブジェクトの保持カウントが何であるかについて心配する必要はありません。他のすべての人が同じ契約を順守していると信じてください。そうすれば、すべてがうまくいくでしょう。
特に、オブジェクトの保持数を気にしないことについてのポイントを繰り返します。保持カウント自体は、さまざまな理由で誤解を招く可能性があります。オブジェクトの保持カウントをログに記録していることに気付いた場合は、ほぼ間違いなく間違ったパスを進んでいます。一歩下がって自問してみてください。基本的なルールに従っていますか？
于 2008-10-05T17:16:29.670 に答える
10
常にアクセサメソッドを使用します。プロパティを使用してアクセサを宣言する
常にアクセサメソッドを使用してインスタンス変数に値を割り当てると、作業がはるかに簡単になります（inメソッドinit*とdeallocメソッドを除く）。副作用（KVO変更通知retainなど）が適切にトリガーされるようにすることは別として、コードにsとを振りかける場合よりも、コピーアンドペーストやその他の論理エラーが発生する可能性がはるかに低くなります。releases。
アクセサを宣言するときは、常にObjective-C2プロパティ機能を使用する必要があります。プロパティ宣言により、アクセサのメモリ管理セマンティクスが明示的になります。また、メソッドとクロスチェックして、またはdeallocとして宣言したすべてのプロパティがリリースされていることを確認する簡単な方法も提供します。retaincopy
于 2008-10-05T16:52:42.247 に答える
8
Instruments Leaks ツールは、特定のクラスのメモリ リークを見つけるのに非常に優れています。「Start with Performance Tool」/「Leaks」メニュー項目を使用するだけで、このツールを介してアプリケーションを自動的に実行できます。Mac OS X および iPhone (シミュレーターまたはデバイス) で動作します。
Leaks ツールは、リークの原因を見つけるのに役立ちますが、リークしたメモリが保持されている場所を追跡するのにはあまり役立ちません。
于 2008-10-05T15:18:03.997 に答える
6
保持と解放のルールに従います (またはガベージ コレクションを使用します)。それらはここにまとめられています。
機器を使用して漏れを追跡します。Xcode で Build > Start With Performance Tool を使用して、Instruments の下でアプリケーションを実行できます。
于 2008-10-05T15:17:55.430 に答える
2
オブジェクトに対するすべての保持/解放/自動解放呼び出しを表示するメモリリークを追跡しようとしていたときに、Omniのツールを使用したことを覚えています。オブジェクトのすべての保持と解放だけでなく、割り当てのスタックトレースも表示されたと思います。
于 2008-10-05T16:20:01.953 に答える
1
まず第一に、[ ] と { } のブラケットとブレースの使用が世界標準に一致していることが非常に重要です。OK、冗談です。
リークを見ると、リークの原因がコードの問題であると推測できますが、それが 100% の障害ではありません。場合によっては、Apple の (あえぎ!) コードで何か問題が発生している可能性があります。また、割り当てられているココア オブジェクトとして表示されないため、見つけにくいものかもしれません。過去にリークバグをAppleに報告しました。
リークを見つけるのが難しい場合があります。これは、見つけた手がかり (数百の文字列のリークなど) が、文字列の直接の原因であるオブジェクトがリークしているからではなく、何かがそのオブジェクトをリークしているために発生する場合があるためです。多くの場合、問題の「根」を見つけるために、漏れのある「ツリー」の葉や枝を掘り下げる必要があります。
防止: 私の主なルールの 1 つは、オブジェクトをその場で自動解放するだけでなく、オブジェクトの割り当てを絶対に避けることです。オブジェクトを割り当て/初期化し、コード ブロック内で後で解放する場所はどこでも、間違いを犯す可能性があります。リリースするのを忘れるか、リリースが呼び出されないように例外をスローするか、メソッドのどこかに早期終了用の「return」ステートメントを配置します (これも避けようとしています)。
于 2008-10-06T17:39:33.740 に答える
1
ここから Valgrind のベータ版ポートをビルドできます: http://www.sealiesoftware.com/valgrind/
これはどの静的分析よりもはるかに便利ですが、私が知っている特別な Cocoa サポートはまだありません。
于 2008-12-25T20:04:39.403 に答える
0
明らかに、最初に基本的なメモリ管理の概念を理解する必要があります。ただし、リークを追跡するという観点から、Instrumentsでのリークモードの使用に関するこのチュートリアルを読むことを強くお勧めします。
于 2012-03-22T14:32:28.877 に答える