1

私はretainCountに問題があります

NSLog(@"%i", [self.albumReceiver retainCount]);
    self.albumReceiver = [[[FacebookAlbumsDelegateReceiver alloc] init: self] autorelease];

    NSLog(@"%i", [self.albumReceiver retainCount]);

最初の行の保持カウントは 0 ですが、3 行目に到達すると 3 になります。self.albumReceiver のプロパティは保持プロパティです... 1 後で自動解放されたので。

 NSLog(@"%i", [self.albumReceiver retainCount]);
    albumReceiver = [[[FacebookAlbumsDelegateReceiver alloc] init: self];

    NSLog(@"%i", [self.albumReceiver retainCount]);

保持カウントは 0 から始まり、この場合、2 番目の保持カウントは 2 を出力します。

この保持と解放がどのように機能するかについて、誰かが考えを与えることができますか....

「self」キーワードがないと、セッター呼び出しは無視されると思いましたか？しかし、2 番目の例に autorelease を設定すると、エラーが発生します。

4

4 に答える 4

4

まず、保持カウントは実装の詳細であり、あまり気にする必要はありません。あなたは本当に所有権だけを気にするべきです。

そうは言っても、あなたが見ていることの説明は次のとおりです。

最初の行の保持カウントは 0 です

その時点だからself.albumReceiverです。nil実際のオブジェクトでは、(Foundation の現在の実装では) 保持カウントが 0 になることはありません。

3 行目に到達すると 3 になります

通常、retain カウントは 2 であると予想されます。alloc の場合は +1、retain プロパティへの割り当ての場合は +1 です。ただし、init:メソッドによって他のオブジェクトがそれを保持する可能性があるため、プロパティのセッターも保持される可能性があります。プロパティを監視している別のオブジェクトも、オブジェクトを保持することを選択する場合があります。要するに、関連するすべてのメソッドの正確な実装を知っていて、albumReceiver で KVO を使用していないことを確実に知っている場合を除き、保持カウントについて言えることは、そのself所有権を持っていることだけです (注意: 所有権は排他的ではなく、他のこともあるかもしれません)。所有権もあります）。これが、カウントを保持することにあまり注意を払うべきではない理由です。

この保持と解放がどのように機能するかについて誰かが考えを与えることができますか

はい。所有権の観点から考える必要があります。特定のメソッドは、所有するオブジェクトを提供します。これらは、 で始まるalloc任意のメソッド、 で始まる任意のメソッド、またはおよび でnew始まる任意のメソッドです。他の方法でオブジェクトを受け取った場合、あなたはそれを所有していません。これには、メソッドの戻り結果、メソッドの ass パラメーター、メソッドの参照パラメーター、またはグローバル変数または静的変数としてそれらを受け取ることが含まれます。copymutableCopy-retain

オブジェクトを所有している場合は、オブジェクトを解放または自動解放して所有権を放棄する必要があります。そうしないと、オブジェクトがリークします。オブジェクトを所有していない場合は、解放または自動解放してはなりません。

上記の「あなた」は、「オブジェクト参照が宣言されたスコープ」を意味すると考えるのが最善だと思います。

とにかく、決定的な説明については Apple のMemory Management Rulesを読んで、ここでの回答を信用しないことをお勧めします。この回答の元の編集を見ると、最後に読んでからルールが強化されたため、ルールが少し間違っていることがわかります。

于 2012-05-31T09:36:29.977 に答える
2

retainCountフレームワークのどの秘密部分がオブジェクトを保持する必要性を感じているかを知ることは通常不可能であるため、Objective-C のオブジェクトの に注意を払うことは一般的に悪い考えです。

オブジェクトを自動解放プールに追加する場所を引用する場合、自動解放プールはおそらく、プールをフラッシュする時が来るまで (実行ループ中に) オブジェクトを保持します。これはおそらくautorelease、 d オブジェクトの保持カウントが高い理由を説明しています。

上記の段落での「おそらく」および「おそらく」という言葉の使用に注意してください。これが実際に Cocoa/Cocoa Touch フレームワーク内で起こっていることかどうかはわかりません。これは を使用する際の問題でありretainCount、保持カウントがどの時点であるべきかを知る方法がありません。

オブジェクトを作成する (または、 、、またはretainを含むメソッド名で作成する) 場合は、それです。フレームワークはオブジェクトに対しても自由であり、準備ができたらそれを行います。保持カウントがゼロになると、ed になります。 alloccopymutableCopynewreleaseretainreleasedealloc

更新: NSObject および NSAutoreleasePool の GNUStep ソース コードを調べたところ、上記の考えられる説明はおそらく起こっていることではありません。ただし、Apple によるこれら 2 つのオブジェクトの実装を確認できないため、確認する方法がありません。信頼しない、retainCountまたはそれからの推論をしないさらに多くの理由。

于 2012-05-31T09:22:22.690 に答える
2

使用しないでくださいretainCount。(これを使用するのが適切な状況については、この Web サイトを参照してください。) 詳細情報: bbum によるブログ投稿、前の SO スレッド 1、スレッド 2。retainCountまた、最近の SDK では非推奨になっていることに注意してください。非推奨の警告に注意を払うことをお勧めします。すべての警告をエラーに変えることをお勧めします。

于 2012-05-31T09:16:09.577 に答える
0

手動でメモリを管理する環境で実際に存在する唯一のルールは、

alloc、copy、mutableCopy、_new

それを解放。そうでなければ、しないでください。保持カウントは、デバッグには実際には機能しません。こちらをご覧ください

于 2012-05-31T09:14:24.963 に答える