XCode 5 Debug Navigator Memory не согласен с инструментами

Question

Я работаю над своим первым проектом ARC & Core Data, основывая этот этап на шаблоне Xcode (Universal) Master-Detail. Я отмечаю, что Xcode5 имеет отображение памяти в отладочном навигаторе, но при его использовании обнаруживается, что на его графике мало общего с использованием mem, отображаемым в инструментах при выполнении трассировки утечек и распределений. Я провел трассировку инструментов с помощью симулятора (имитирующего как iPhone, так и iPad - на случай, если "разгрузка" детализации View с последним имеет значение) и на iPad2 и iPodTouch. Результаты в целом одинаковы:

iPhone 6.1 симулятор

1. Поколение А --------1,13 МБ
2. Поколение B--------397,70 КБ
3. Поколение C--------76,96 КБ
4. Поколение D--------11,70 КБ
5. Поколение E--------1,56 КБ
6. Поколение F--------3,48 КБ

общий рост c30%

где Поколение A показывает рост загрузки главной таблицы, а каждое последующее Поколение - рост после просмотра и взаимодействия с подробным представлением (что влечет за собой выборку NSManagedObjects и создание NSObjects, соответственно). Тенденция к росту с другими устройствами была в целом схожей (при росте Поколения А было iPad sim:1,42; iPad2:1,57; iPodTouch:0,94, но схожим образом).

Однако, в соответствии с Debug Navigator, общее использование в каждой точке составляет:

отладка iPhone 6.1

1. Поколение А -------- 4,2 МБ
2. Поколение B -------- 6,9 МБ - рост 2,7
3. Поколение C -------- 7,1 МБ - рост 0,2
4. Поколение D -------- 7,8 МБ - рост 0,7
5. Поколение E -------- 8,0 МБ - рост 0,2
6. Поколение F -------- 8,4 МБ - рост 0,4
   общий рост 100%!

Что касается других подобных вопросов, у меня не включены зомби. Видели ли другие такие расхождения? Прав ли я в том, что склонен доверять Инструментам, а не сводным данным Навигатора отладки?

PS. Сводная фигура Debug Navigator, по-видимому, недоступна при работе с реальными устройствами (обе в версиях iOS5). Это нормально?

Answer 1

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

Навигатор отладки показывает то же самое, что и инструмент "Монитор активности". Он не показывает текущую выделенную память вашим приложением, он показывает текущую память, разрешенную вашему приложению операционной системой.

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

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

Опять же, это мой вывод, основанный на том, когда мне было интересно то же, что и вы. Надеюсь, это немного поможет.