При тестировании приложения iPhone достаточно ли использовать инструмент "Утечки"?

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

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

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

Ответ 1

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

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

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

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

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

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

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

Ответ 2

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

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

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

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

Ответ 3

Инструмент "Утечки" улавливает многие возможные утечки, но не все. Соблюдайте общее распределение памяти и убедитесь, что он отклоняется, когда он должен. Прочтите описание случая кучного демпфирования 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.

Ответ 4

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

Ответ 6

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