Тестирование управления памятью в Objective-C (iOS) - PullRequest
3 голосов
/ 31 января 2011

Я несколько новичок в Objective-C и, хотя я думаю, что у меня есть приличное представление об управлении памятью, я хотел бы ознакомиться с лучшими способами проверить это (если это возможно).

Мне известны два варианта: 1) Сборка и анализ (изнутри XCode) и 2) Инструменты.

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

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

Спасибо за любые идеи.

Ответы [ 5 ]

3 голосов
/ 31 января 2011

Я вижу, что многие люди заявляют, что «Инструменты могут отследить утечки [в контексте управления памятью]», и оставляют это на этом.

Так далеко от истины; анализ утечек полезен, но едва раскрывает потрясающие возможности оптимизации, которые он может выявить.

  • Может использоваться для обнаружения зомби; то есть, чтобы отследить чрезмерное высвобождение объекта, которое вызывает сбой

  • Может контролировать выделение полосы пропускания; количество объектов, которые ваше приложение создает / освобождает со временем. Сокращение, которое является очень эффективным средством оптимизации приложения.

  • Может проверять точный набор объектов в реальном времени и в памяти в любое время; рабочий набор.

  • Использование Анализ хэпшотов может точно показать, как ваше приложение постоянно растет со временем.

  • Может точно сказать, где любой данный объект удерживается и / или освобождается, включая обратные следы.

2 голосов
/ 31 января 2011

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

Приборы будут искатьутечка объектов во время выполнения.Таким образом, он может найти только проблемы, которые на самом деле возникают.Так что в принципе вам нужно пройти через все возможные пути использования в вашей программе, чтобы поймать все.Это имеет тенденцию быть действительно полезным на практике.И это не так сложно в использовании.Просто запустите инструмент утечки, запустите немного, вы получите график того, как просочилась память, и вы можете узнать, какие объекты просачиваются.Затем вы можете попросить показать, где в источнике был создан объект.Имейте в виду, что вы получите некоторые вторичные утечки (в том случае, если один объект утечет, тогда все объекты, которые он сохранил, также будут протекать).

На рабочем столе также доступен Guard Malloc, хотя я так думаюеще не на iOS.Это приводит к тому, что ваша программа работает намного медленнее, но сразу же происходит сбой при любой ошибке доступа к памяти.Так что это действительно полезно, потому что обычно такие вещи, как запись после конца массивов C или доступ к освобожденным объектам, могут вызывать ошибку, но не обязательно делают это, иногда вызывая ошибки в какой-либо части кода, что приводит к повреждению структур, используемых другими частями кода.и вызвать сбой в коде, который полностью действителен.

1 голос
/ 31 января 2011

Я довольно новичок в Objective-C (из опыта Java), но мне удалось обойтись с двумя функциями, которые вы упомянули (Build / Analyze) и Instruments. Я думаю, что это сработало, потому что я получил одобрение моего приложения от Apple, и до сих пор не было жалоб от клиентов, так что по крайней мере это что-то.

В любом случае, я обнаружил, что Analyze гораздо менее полезен, чем я мог подумать. В основном я обнаружил проблемы с использованием инструментов распределения и утечки.

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

Инструмент утечки был очень полезен, но убедитесь, что вы пропустили ваше приложение во время его работы. Просто нажимайте на все виды вещей, заходите и выходите из экрана много раз, нажимайте на вещи, которые люди никогда бы не делали, и т. Д. Вы найдете утечки. Тогда раздави их. Очень сытно.

1 голос
/ 31 января 2011

Да, лучшее, что вы можете сделать, это узнать больше об управлении памятью http://developer.apple.com/library/mac/#documentation/cocoa/conceptual/MemoryMgmt/MemoryMgmt.html

Build and Analyze отлично работает для определения некоторых вещей, например, если что-то никогда не будет выпущено.Это поможет вам отследить множество проблем, но это ни в коем случае не идеально.

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

Еще один полезный инструмент, который вы можете использовать для отслеживания сбоев из памяти, этонажмите Run-> Stop On Objective C Исключения.Который позволит вам пройти через стек, чтобы увидеть, где происходит сбой вашего приложения, чтобы выяснить, где оно работает не так.

0 голосов
/ 19 марта 2011

Clang с xcode - еще один отличный вариант. http://clang -analyzer.llvm.org / xcode.html

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...