Дилемма управления памятью, цель -C

Question

Я тестировал различные функции Objective -C и достиг темы, которая касается управления памятью. Очевидно, что после прочтения нескольких документов управление памятью является очень строгим для построения хорошо функционирующего приложения.

Теперь, согласно моему пониманию, когда мы выделим память, объект retainCount станет 1 . Однако что-то, что я написал для учебных целей, и это дает мне ненормальное retainCount

Это может быть ненормальное число для меня, но люди, которые знают под капотом, не могли бы вы объяснить, как я получил это retainCount и какой будет лучший способ выпустить его.

Код с ненормальным значением retainCount,

Имя объекта: ...(UISlider *) greenSender...

-(IBAction) changeGreen:(UISlider *)greenSender{
    showHere.textColor = [UIColor colorWithRed:red.value green:greenSender.value blue:blue.value alpha:1.0];
    NSLog(@"retainCount %d",[greenSender retainCount]);
}

Имеет reatainCount, сразу после выполнения моего кода.

Короткое объяснение даст мне подсказку, И внешние ресурсы для чтения будут оценены. Спасибо

Answer 1

Не доверять / полагаться на retainCount. На самом деле.

от Apple:

Важно : Этот метод обычно не имеет значения при отладке проблемы управления памятью. Потому что любое количество объектов каркаса может сохранил объект для хранения ссылок на него, в то время как в в то же время пулы авторелизов могут содержать любое количество отложенных релизы на объекте, очень маловероятно, что вы можете получить полезные информация из этого метода.

Answer 2

Не полагайтесь на счет удержания . Они должны использоваться только как инструмент отладки. Причина в том, что если объект получает retain ed и autorelease d, его эффективный счет сохранения не изменился, но его фактический счет сохранения увеличился на единицу. Это будет release d в какой-то момент в будущем, когда пул авто-релиза истощится. Таким образом, вы не можете полагаться на счет сохранения, чтобы узнать, правильно ли управлялся объект.

Большое количество сохранений, такое как 8, может указывать на программную ошибку (например, слишком частое сохранение), но это также может быть просто признаком того, что он был retain ed и autorelease da большое количество раз , что, хотя любопытно, может быть совершенно справедливо.