Происходят утечки памяти (и ресурсов). Как вы уверены, что они этого не делают?
Какие советы и методы вы предложите, чтобы избежать утечки памяти на первом месте?
Как только у вас есть приложение, которое протекает, как вы отслеживаете источник утечек?
(О, пожалуйста, избегайте ответа "просто использовать GC". Пока iPhone не поддерживает GC, это не правильный ответ, и даже тогда - возможно утечка ресурсов и памяти на GC)
В XCode 4.5 используйте встроенный Статический анализатор.
В версиях XCode до 3.3 вам может потребоваться загрузить статический анализатор. Эти ссылки показывают вам, как:
Чтобы избежать создания утечек памяти в первую очередь, используйте Clang Static Analyzer - неудивительно - проанализируйте свои C и Objective-C код (еще не С++) в Mac OS X 10.5. Это тривиально для установки и использования:
cd в каталог проекта.scan-build -k -V xcodebuild.(Есть некоторые дополнительные ограничения и т.д., в частности, вы должны проанализировать проект в его конфигурации "Отладка" - см. http://clang.llvm.org/StaticAnalysisUsage.html для деталей - но это более или менее то, к чему оно сводится.)
Затем анализатор создает набор веб-страниц для вас, который показывает вероятное управление памятью и другие основные проблемы, которые компилятор не может обнаружить.
Если ваш проект не предназначен для настольных компьютеров Mac OS X, есть еще несколько деталей:
(Это в основном тот же ответ, что и этот вопрос.)
По какой-то причине многие разработчики (особенно на ранних этапах) делают управление памятью более сложным для себя, чем когда-либо, часто переосмысливая проблему или представляя ее более сложной, чем она есть.
основные правила очень просты. Вы должны сосредоточиться только после этого. Не беспокойтесь о том, что могут сделать другие объекты, или о том, что счетчик удержания вашего объекта. Доверяйте, что все остальные соблюдают один и тот же контракт, и все это будет просто работать.
В частности, я повторю, что не стоит беспокоиться о сохранении количества ваших объектов. Сам счет удержания может вводить в заблуждение по разным причинам. Если вы обнаружите, что регистрируете счетчик хранения объекта, вы почти наверняка идете по неверному пути. Вернитесь назад и спросите себя, следуете ли вы основным правилам?
Вы делаете жизнь намного проще для себя, если вы всегда используете методы доступа для назначения значений переменным экземпляра (кроме методов init* и dealloc). Помимо обеспечения того, что любые побочные эффекты (такие как уведомления об изменениях KVO) должным образом запускаются, это значительно снижает вероятность того, что вы будете страдать копирование и вставка или некоторая другая логическая ошибка, чем если вы покроете свой код с помощью retain и release s.
При объявлении аксессуаров вы всегда должны использовать функцию Objective-C 2 свойства. Объявления свойств делают семантику управления памятью ячеек доступа. Они также обеспечивают простой способ перекрестной проверки с помощью метода dealloc, чтобы убедиться, что вы выпустили все свойства, которые вы объявили как retain или copy.
Инструмент "Утечки инструментов" довольно хорош в поиске определенного класса утечек памяти. Просто используйте пункт "Начать с Performance Tool" / "Leaks", чтобы автоматически запускать приложение через этот инструмент. Работает для Mac OS X и iPhone (симулятор или устройство).
Инструмент "Утечки" помогает найти источники утечек, но не помогает отслеживать, где сохраняется утечка памяти.
Следуйте правилам сохранения и освобождения (или используйте Сбор мусора). Они приведены здесь.
Используйте инструменты для отслеживания утечек. Вы можете запустить приложение в разделе "Инструменты", используя "Сборкa > Начать с Performance Tool" в Xcode.
Я помню, что с помощью инструмента Omni некоторое время назад, когда я пытался отследить некоторые утечки памяти, которые отображали бы все вызовы сохранения/выпуска/автообновления объекта. Я думаю, что он показал трассировку стека для выделения, а также все сохраняет и освобождает объект.
Прежде всего, жизненно важно, чтобы ваше использование [] и {} скобок и фигурных скобок соответствовало универсальному стандарту. Хорошо, просто kiddin '.
Если вы посмотрите на утечки, вы можете предположить, что утечка связана с проблемой вашего кода, но это не 100% ошибки. В некоторых случаях может произойти что-то в коде Apple (gasp!), Который виноват. И это может быть трудно найти, потому что оно не отображается как cocoa выделенные объекты. В прошлом я сообщал об ошибках утечки в Apple.
Иногда трудно найти утечки, потому что подсказки, которые вы обнаружите (например, сотни строк, просочились) могут произойти не потому, что те объекты, которые непосредственно несут ответственность за строки, протекают, а потому что что-то утечка этого объекта. Часто вам приходится рыть через листья и ветки утечки "дерева", чтобы найти "корень" проблемы.
Предотвращение: Одно из моих основных правил - действительно, действительно, действительно избегать распределения объекта без простое его восстановление прямо на месте. В любом месте, которое вы назначаете/начинаете объект, а затем выпускаете его позже в блоке кода, вы можете сделать ошибку. Либо вы забудете выпустить его, либо выбросите исключение, чтобы выпуск никогда не вызывался, или вы добавляете оператор "return" для раннего выхода где-то в методе (что-то я также избегаю).
Вы можете построить бета-порт Valgrind здесь: http://www.sealiesoftware.com/valgrind/
Это гораздо более полезно, чем любой статический анализ, но пока не имеет специальной поддержки Cocoa, о которой я знаю.
Очевидно, вам нужно понять основные концепции управления памятью для начала. Но в плане преследования утечек я настоятельно рекомендую прочитать это руководство по использованию режима утечек в Инструментах.