Как я могу отслеживать пики памяти? (Это пики с p, а не l.)

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

Я запустил свое приложение с помощью инструмента распределения, чтобы узнать, каково использование памяти. Учитывая, что это киоск приложение, все должно идти гладко,без утечек. (Конечно, все приложения должны работать без утечек, но приложение киоска делает это еще более важной целью.) Я увидел некоторые интересные результаты, поэтому я также запустил старую версию кода.

запуск старой версии кода, я вижу, что в значительной степени даже работает около 1.15 мегабайт использования памяти. Кажется, все распределяется и освобождается по мере необходимости. Однако в моей новой реализации я вижу что-то немного другое. Использование памяти продолжает прыгать в маленьких "плато", а затем, в конечном итоге, кажется, пик на 1,47 мегабайта использования. Вот как выглядит новый отчет о распределении после запуска в течение 10 часов:

enter image description here

Я обеспокоен по нескольким причинам.

  1. нечетная картина в начале бега.
  2. распределение кажется к пику на 1.47 мегабайтах, но запуск его в одночасье показывает, что он на самом деле будет медленно использовать все больше и больше памяти с течением времени. Это не может быть хорошо.

есть несколько заметных различий между старым проектом и новым.

  • более старый использует Plists в качестве резервного хранилища (я вручную читаю и пишу в файл plist.) В новом проекте используются основные данные.

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

  • оба класса используют класс factory для создания слайдов. В старом проекте фабричный класс был одиночкой. Я думал, что превращение его в обычный класс поможет с проблемами памяти, так как синглтон никогда не был выпущен. (Отсюда это свойства не были освобождены.В новом проект, класс factory выпускается, поэтому я не уверен, почему он все еще занимает всю эту память (если это то, что вызывает проблему.

  • старый проект использует строковые константы в разных местах. Новый код использует массивное перечисление для того же самого. (Новый код, как правило, использует больше констант.)

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

Я был бы благодарен, если бы кто-нибудь помочь мне точку в правильном направлении.

Edit:

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

1 ответов


что я могу сделать, чтобы отслеживать пики памяти? Память все время очищается приложением, когда оно отбрасывает все, что оно использует, но, похоже, это не отбрасывание вещей.

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

чтобы исправить это, вам нужно убедиться, что ваш график объектов обрезается соответствующим образом по мере запуска вашего приложения. Кэши обычно должны использовать алгоритм обрезки [LRU], который используется в последнее время и ограничивает размер кэша. Если ключ кэша когда-либо становится недействительным, эти данные должны быть сокращены, тоже.

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

используйте анализ Heapshot -- он был создан, чтобы помочь отследить именно эти проблемы.

Я написал подробное руководство" как";когда утечка не утечка?