これまでどのような状況で-retainCount
を使用し、最終的にはそれを使用して発生する可能性のある問題を知りたいと思います。
ありがとう。
-retainCount
を使用しないでください。何も有用な情報が表示されないためです。 FoundationおよびAppKit/UIKitフレームワークの実装は不透明です。何が保持されているのか、なぜ保持されているのか、誰が保持しているのか、いつ保持されているのかなどがわかりません。
例えば:
[NSNumber numberWithInt:1]
はretainCount
が1になると思うでしょう。そうではありません。 2です。@"Foo"
はretainCount
が1になると思うでしょう。そうではありません。 1152921504606846975です。[NSString stringWithString:@"Foo"]
はretainCount
が1になると思うでしょう。そうではありません。繰り返しますが、1152921504606846975です。基本的に、何でもオブジェクトを保持できるため(したがって、そのretainCount
を変更できます)、アプリケーションを実行するほとんどのコードのソースがないため、オブジェクトのretainCount
は無意味です。 。
オブジェクトの割り当てが解除されない理由を追跡する場合は、Instrumentsのリークツールを使用します。オブジェクトの割り当てがすぐに解除された理由を追跡する場合は、Instrumentsのゾンビツールを使用します。
ただし、-retainCount
は使用しないでください。それは本当に価値のない方法です。
編集
みんな http://bugreport.Apple.com にアクセスして、-retainCount
の廃止をリクエストしてください。それを求める人が多いほど良い。
#2を編集
更新として、[NSNumber numberWithInt:1]
のretainCount
は9223372036854775807になりました。コードが2であると予想していた場合、コードは壊れています。
自動解放されたオブジェクトは、-retainCountのチェックが情報価値がなく、誤解を招く可能性がある1つのケースです。保持カウントは、オブジェクトに対して-autoreleaseが何回呼び出されたか、つまり現在の自動解放プールが空になったときに解放される回数については何も伝えません。
I do「Instruments」を使用してチェックすると、retainCountsが非常に便利です。
「割り当て」ツールを使用して、「参照カウントの記録」がオンになっていることを確認します。任意のオブジェクトに移動して、そのretainCount履歴を確認できます。
Allocとreleaseをペアにすることで、何が起こっているのかをよく把握でき、何かがリリースされないという困難なケースをしばしば解決できます。
これは私を決して失望させませんでした-iOSの初期のベータリリースでバグを見つけることを含みます。
NSObjectに関するAppleのドキュメントをご覧ください。ほとんどの質問をカバーしています: NSObject retainCount
要するに、独自の参照カウントシステムを実装していない限り、retainCountはおそらく役に立たないでしょう(そして、私はあなたが持っていないことをほぼ保証できます)。
Apple自身の言葉では、retainCountは「通常、メモリ管理の問題をデバッグするのに価値がありません」。
もちろん、コードでretainCountメソッドを使用しないでください。その値の意味は、オブジェクトに適用された自動リリースの数に依存し、予測できないためです。ただし、デバッグには非常に便利です(特に、メインイベントループ外でAppkitオブジェクトのメソッドを呼び出すコードでメモリリークを追跡する場合)。これは非推奨ではありません。
あなたの主張をする努力の中で、価値の不可解な性質を真剣に誇張しました。常に参照カウントとは限らないのは事実です。フラグに使用される特別な値がいくつかあります。たとえば、オブジェクトの割り当てを解除してはならないことを示すためです。 1152921504606846975のような数値は、16進数で記述して0xfffffffffffffffを取得するまで非常に不思議に見えます。また、9223372036854775807は16進数で0x7fffffffffffffffです。また、retainCountを1秒間に100,000,000回インクリメントしたと仮定すると、retainCountを大きい数値とするのにほぼ3000年かかるため、誰かがこのような値をフラグとして使用することを選択するのはそれほど驚くことではありません。
アプリが起動して実行され、有用なことを実行するまで、メモリリークについて心配する必要はありません。
それができたら、Instrumentsを起動してアプリを使用し、メモリリークが実際に発生するかどうかを確認します。ほとんどの場合、オブジェクトを自分で作成し(所有しているため)、完了後にリリースするのを忘れていました。
コードを書いているときにコードを最適化しようとしないでください。実際にアプリを実際に使用するときに、メモリリークや時間がかかりすぎる可能性についての推測が間違っていることがよくあります。
正しいコードを書いてみてください。 allocなどを使用してオブジェクトを作成する場合は、必ず適切に解放してください。
あなたはそれを使用することからどんな問題を得ることができますか?オブジェクトの保持カウントを返すだけです。私はそれを一度も呼んだことがないし、私がそうするどんな理由も考えられない。ただし、割り当てが解除されないように、シングルトンでオーバーライドしました。
コードでは絶対に使用しないでくださいが、デバッグ時に間違いなく役立ちます
コードで-retainCountを使用しないでください。ただし、使用すると、ゼロが返されることはありません。理由を考えてください。 :-)
Daveの投稿で使用されている例はNSNumberとNSStringsです...したがって、UIViewsなどの他のクラスを使用すると、正しい答えが得られるはずです(保持カウントは実装によって異なり、予測可能です)。