Ответ 1

Вы никогда не должны использовать -retainCount, потому что он никогда не говорит вам ничего полезного. Внедрение фондов и инфраструктур AppKit/UIKit непрозрачно; вы не знаете, что сохранилось, почему оно сохранилось, кто его сохранил, когда он был сохранен и т.д.

Например:

• Вы думаете, что [NSNumber numberWithInt:1] будет иметь retainCount of 1. Это не так. Это 2.
• Вы думаете, что @"Foo" будет иметь retainCount of 1. Это не так. Это 1152921504606846975.
• Вы думаете, что [NSString stringWithString:@"Foo"] будет иметь retainCount of 1. Это не так. Опять же, это 1152921504606846975.

В принципе, поскольку все может сохранить объект (и, следовательно, изменить его retainCount), и поскольку у вас нет источника для большей части кода, запускающего приложение, объект retainCount не имеет смысла.

Если вы пытаетесь отследить, почему объект не освобождается, используйте инструмент "Утечки" в "Инструменты". Если вы пытаетесь отследить, почему объект был освобожден слишком рано, используйте инструмент "Зомби" в "Инструменты".

Но не используйте -retainCount. Это действительно бесполезный метод.

изменить

Пожалуйста, переходите к http://bugreport.apple.com и просите, чтобы -retainCount устарел. Чем больше людей просят об этом, тем лучше.

изменить # 2

Как обновление, [NSNumber numberWithInt:1] теперь имеет retainCount от 9223372036854775807. Если ваш код ожидал, что он будет равен 2, ваш код теперь сломан.

Ответ 2

никогда!

Серьезно. Просто не делай этого.

Просто следуйте Руководствам по управлению памятью и выпустите только то, что вы alloc, new или copy (или все, что вы назвали retain по умолчанию).

@bbum сказал, что он лучше здесь, на SO, и еще более подробно на его блог.

Ответ 3

Автореализованные объекты - это один случай, когда check -retainCount неинформативен и потенциально вводит в заблуждение. Счет удержания ничего не говорит о том, сколько раз было вызвано -autorelease на объект, и поэтому сколько раз он будет выпущен, когда текущий пул авторезистов будет истощен.

Ответ 4

I do найти saveCounts очень полезно при проверке с помощью "Инструменты".

Используя инструмент "allocations", убедитесь, что "Record reference counts" включен, и вы можете перейти к любому объекту и просмотреть его историю keepCount.

Путем спаривания выделов и выпусков вы можете получить хорошее представление о том, что происходит, и часто решать те сложные случаи, когда что-то не выпускается.

Это никогда не подводило меня - включая поиск ошибок в ранних бета-версиях iOS.

Ответ 5

Взгляните на документацию Apple на NSObject, это в значительной степени охватывает ваш вопрос: NSObject saveCount

Короче говоря, preserveCount, вероятно, бесполезен для вас, если вы не внедрили свою собственную систему подсчета ссылок (и я почти гарантирую, что у вас ее не будет).

В собственных словах Apple keepCount "обычно не имеет значения при отладке проблем управления памятью".

Ответ 6

Какие проблемы вы можете получить от использования? Все, что он делает, это вернуть счетчик удержания объекта. Я никогда не называл это и не мог думать ни о какой причине. Я переопределил его в одиночных играх, чтобы удостовериться, что они не освобождены, хотя.

Ответ 7

Вам не следует беспокоиться о утечке памяти, пока ваше приложение не будет запущено и не сделает что-то полезное.

Как только это произойдет, запустите Инструменты и используйте приложение и посмотрите, действительно ли происходит утечка памяти. В большинстве случаев вы сами создали объект (таким образом, вы его владеете) и забыли освободить его после того, как вы закончили.

Не пытайтесь оптимизировать свой код во время его написания, ваши догадки о том, что может вытечь память или занять слишком много времени, часто ошибочны, когда вы фактически используете приложение в обычном режиме.

Попробуйте написать правильный код, например. если вы создаете объект с использованием alloc и т.д., убедитесь, что вы отпустите его правильно.

Ответ 8

Конечно, вы никогда не должны использовать метод keepCount в своем коде, поскольку значение его значения зависит от того, сколько автореализаций было применено к объекту, и это то, чего вы не можете предсказать. Однако это очень полезно для отладки - особенно когда вы пытаетесь устранить утечки памяти в коде, который вызывает методы объектов Appkit вне основного цикла событий, и его нельзя устареть.

В ваших усилиях, чтобы сделать вашу мысль, вы серьезно завысили непостижимый характер ценности. Это правда, что это не всегда число ссылок. Существуют некоторые специальные значения, которые используются для флагов, например, чтобы указать, что объект никогда не должен быть освобожден. Число, подобное 1152921504606846975, выглядит очень загадочным, пока вы не напишете его в шестнадцатеричном виде и не получите 0xfffffffffffffffff. А 9223372036854775807 - это 0x7fffffffffffffffff в шестнадцатеричном формате. И действительно неудивительно, что кто-то предпочел бы использовать такие значения, как эти, как флагов, учитывая, что потребуется около 3000 лет, чтобы получить значение keepCount выше, чем большее число, при условии, что вы увеличили значение keepCount 100 000 000 раз в секунду.

Ответ 9

Вы никогда не должны использовать его в своем коде, но это может определенно помочь при отладке

Ответ 10

Никогда не используйте -retainCount в коде. Однако, если вы используете, вы никогда не увидите, что он возвращает ноль. Подумайте о том, почему.: -)

Ответ 11

Примерами, используемыми в столбце Dave, являются NSNumber и NSStrings... поэтому, если вы используете некоторые другие классы, такие как UIViews, я уверен, что вы получите правильный ответ (счет сохранения зависит от реализации, и это предсказуемы).