Как я могу отследить пики памяти? (Это пики с ap, а не l.)
У меня есть киоск-приложение, которое, по сути, показывает кучу слайдов с различной информацией на них. Первоначально я начал кодировать это более года назад, когда я начинал с Objective-C и разработки для iOS. Я считаю, что мой стиль кода стал намного чище, чем был раньше, и у меня гораздо больше опыта, поэтому я решил переписать его с нуля.
Я запустил свое приложение с помощью инструмента Allocations, чтобы узнать, каково было использование памяти. Учитывая, что это киоск-приложение, все должно работать бесперебойно, без утечек. (Конечно, все приложения должны работать без утечек, но киоск-приложение делает это еще более важной целью.) Я увидел некоторые интересные результаты, поэтому я также запустил старую версию кода.
Запуск старой версии код, я вижу, в значительной степени даже работает при использовании памяти около 1,15 мегабайта. Кажется, что все распределяется и освобождается по мере необходимости. Однако в моей новой реализации я вижу кое-что другое. Использование памяти продолжает скакать на небольших «плато», а затем, кажется, достигает пика примерно до 1,47 мегабайт. Вот как выглядит новый отчет о распределении после более чем 10 часов работы:
Меня беспокоит несколько причин.
- Странная картина в начале запуска.
- Распределение кажется пиком в 1,47 мегабайта, но запуск его в течение ночи показывает, что на самом деле он будет постепенно использовать все больше и больше памяти с течением времени. Это не может быть хорошо.
Есть несколько заметных различий между старым проектом и новым.
Более старый использует Plists в качестве резервного хранилища (я вручную читаю и записываю в файл plist.) Новый проект использует Core Data.
Новый проект реализует библиотеку, которая вызывается на каждом «слайде», который старого проекта не было. Меня больше беспокоит эта библиотека, за исключением того, что я написал ее и прошел через нее, чтобы убедиться, что я выпускаю все и только автоматически, если выпуск вручную невозможен.
Оба класса используют фабричный класс для создания слайдов. В старом проекте фабричный класс был одноэлементным. Я думал, что превращение его в обычный класс поможет с проблемами памяти, поскольку синглтон так и не был выпущен. (Следовательно, это свойства не были выпущены. В новом проекте выпускается фабричный класс, поэтому я не уверен, почему он все еще занимает всю эту память (если это является причиной проблемы.
] В старом проекте строковые константы используются в разных местах. Новый код использует массивное перечисление для того же самого. (В новом коде обычно используется больше констант.)
Что я могу сделать, чтобы отследить пики памяти? память очищается приложением, когда оно отбрасывает все, что использует, но, похоже, оно не отбрасывает вещи, пока приложение не завершает работу.
Буду признателен, если кто-нибудь поможет указать мне в правильном направлении.
Редактировать:
Похоже, , что пик вызван обращениями к библиотеке KosherCocoa . Если кто-нибудь не возражает взглянуть на нее и сказать мне, что я » m делает что-то не так, что касается управления памятью, я был бы очень признателен.