При тестировании приложения для iPhone достаточно ли просто использовать инструмент Leaks? - PullRequest
10 голосов
/ 09 декабря 2010

Я собираюсь закончить свое первое приложение для iPhone, и мне интересно, есть ли набор шагов, которые используются для проверки приложения на утечки памяти, производительность и т. Д .?

Достаточно ли проверки с помощью прибора для определения утечек?

Есть ли серии тестов, которые нужно запустить? Ребята, можете ли вы указать мне учебник / документ?

Ответы [ 6 ]

4 голосов
/ 09 декабря 2010

Бег с "Утечками" важен.Я не знаю учебник / контрольный список для окончательного тестирования, хотя что-то подобное было бы удобно.Несколько вещей, которые я бы добавил:

1) Обязательно проведите тестирование на реальном оборудовании, а не только на симуляторе, чтобы убедиться, что производительность на ВСЕМ оборудовании, которое вы собираетесь поддерживать, является приемлемой.По моему опыту, симулятор не дает точного представления о производительности устройства, и могут быть значительные различия между старым и новым оборудованием (крайний пример - iPhone 4 против Gen1 iPhone).Например, в одном из моих приложений я создаю одностраничный отчет в формате PDF.На iPhone 4 и даже iPad это занимает около 1 секунды.На iPhone Gen1 этот код занимает около 8 секунд.Я не мог ничего сделать, чтобы ускорить его, но было ясно, что мне нужно было добавить индикатор прогресса, чтобы пользователь знал, что приложение не было заморожено.Это то, чего я бы не заметил, работая только с симулятором и / или новейшим оборудованием.

2) Возможно, вы захотите потратить немного времени на работу с NSZombieEnabled.Это может обнаружить проблемы с памятью, которые могут скрываться за кулисами, даже если в настоящее время нет видимых признаков проблем.Дополнительная информация:

http://www.cocoadev.com/index.pl?NSZombieEnabled

3 голосов
/ 11 декабря 2010

Тестирование с использованием инструмента Leaks должно быть частью вашей стратегии, но не всем. Вам захочется протестировать ваше приложение под разными углами.

Моя стратегия, направленная на тестирование, направлена ​​в первую очередь на функциональное тестирование, затем тесты производительности, а затем последний раунд функциональных тестов. В настройке производительности нет особого смысла, если в вашем коде есть ошибка, вызывающая сбой, за исключением случаев, когда сбой вызван исчерпанием ресурсов.

Забейте приложение, чтобы оно сломалось, выполнив каждую опцию при всех возможных условиях. Если это проходит, я обычно использую свой тест «сумасшедшая обезьяна на трещину», где я нажимаю случайные кнопки и области на экране так быстро, как могу, чтобы увидеть, выставляю ли я дальнейшие аварии.

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

Как только вы разберетесь с горячими точками и очевидными накоплениями, вы можете перейти к более детальному исследованию памяти. Я на самом деле предпочитаю использовать инструмент Object Allocations с его новой возможностью анализа heapshot инструменту Leaks для обнаружения незначительных накоплений памяти и утечек. Инструмент Leaks имеет тенденцию быть консервативным и может пропустить некоторые наращивания. Натаниэль указывает на превосходную запись Билла Бумгарнера на эту тему.

Инструмент «Распределение объектов» и его кучи особенно эффективны в сочетании с инструментом автоматизации пользовательского интерфейса, где вы можете проводить сотни или тысячи циклов тестирования внутри частей вашего приложения, чтобы выделить даже малейшее накопление памяти. Я начал делать больше такого рода тестов сейчас.

Я думаю, что лучше всего увидеть это в действии, чем описать в тексте, поэтому я рекомендую посмотреть видео для моих классов "Тестирование" и "Настройка производительности" в рамках моего продвинутого курса iOS по iTunes в iTunes U . Я демонстрирую каждый из этих инструментов и то, как я использую их при тестировании своих собственных приложений перед отправкой в ​​App Store. Мои примечания к курсу (в формате VoodooPad ) также описывают это подробно.

2 голосов
/ 11 декабря 2010

Прибор Leaks обнаруживает множество возможных утечек, но не все.Наблюдайте за своим общим распределением памяти и убедитесь, что он уменьшается, когда он должен.Прочитайте пример исследования bbum для анализа кучи:

http://www.friday.com/bbum/2010/10/17/when-is-a-leak-not-a-leak-using-heapshot-analysis-to-find-undesirable-memory-growth/

И запустите статический анализатор Clang с помощью команды Build and Analyze, если вы не делали этого из getgo.*

1 голос
/ 09 декабря 2010

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

0 голосов
/ 09 декабря 2010

Прежде всего создайте свое приложение, но не создавайте его, теперь нажмите «Выполнить» в верхней строке меню XCode, затем нажмите «Запустить с помощью Performance Tool» и выберите «Утечки». Вы увидите новое окно, в котором вы сможете увидеть живые байты, используемые вашим приложением, и место, где просачивается память. Утечки памяти будут отмечены красной меткой. Если при этом возникнут какие-либо проблемы, не стесняйтесь спрашивать.

0 голосов
/ 09 декабря 2010

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

Проверьте эту ссылку, чтобы узнать об инструментах.

http://developer.apple.com/library/mac/#documentation/DeveloperTools/Conceptual/InstrumentsUserGuide/Introduction/Introduction.html

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