Файловая память ImageIO автоматически не очищается iOS

Я создаю приложение, которое является своего рода галереей - оно показывает различный медиа-контент в качестве полноэкранного средства просмотра. Инструмент Распределения показывает, что параметр Live Bytes не увеличивается выше 40 Мб при использовании приложения. Тем временем приложение на 100% уничтожается после того, как я пролистываю страницы 20-30 раз. Я проверил параметр Dirty Memory и обнаружил, что он в 10 раз больше размера Live Bytes. И большая часть этой грязной памяти потребляется Image IO:

РЕДАКТИРОВАТЬ, еще один скриншот:

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

Теперь о дизайне приложений. Экран приложения имеет один вид горизонтальной прокрутки. Представление прокрутки содержит видео или объекты коллажа, которые содержат несколько изображений. Для экономии памяти одновременно создаются только три страницы - текущая страница и страницы слева/справа. Так что страницы всегда создаются и удаляются на лету при скользящем просмотре прокрутки.

Все изображения, которые я загружаю, используют [UIImage imageWithContentOfFile: path]. Объект Collage хранит экземпляры UIImage внутри imagesArray. В методе dealloc атрибут imagesArray очищается.

Итак, вопросы:

Это своего рода системная ошибка в [UIImage imageWithContentOfFile?]
Это Image IO кеш?
Могу ли я это очистить?

Ответ 1

Полагая это здесь слишком большим для комментария, просто некоторые идеи:

1) одним из способов сохранить объекты по ошибке является наличие объектов в представлениях, которые скрываются, но не удаляются из их супервизора (и, таким образом, сохраняются)

2), если вы что-либо делаете с UIImageView и т.д. в любом потоке, а не в главном потоке может произойти плохое (например, это)

3) скопируйте свой проект, чтобы вы могли свободно общаться с ним, и попробуйте кучу вещей:

вместо нескольких изображений, всегда загружайте одно и то же изображение, но оставите остальные части вашего кода такими, какие они есть, - что-то изменилось?
В любых подклассах, которые вы создаете, чтобы удерживать/удерживать изображения, поместите сообщение журнала в dealloc, чтобы узнать, действительно ли эти объекты освобождаются.
подкласс UIImageView, используйте его для изображений и запишите dealloc
подкласс UIImage, используйте его для этих изображений, запишите dealloc

4) У меня с трудом верится, что у imageio есть дефект, который сделает это, но что вы можете сделать, это переключиться на использование imageWithData и загрузить данные самостоятельно. Используйте флаг F_NOCACHE, когда вы действительно читаете данные - на SO есть другой код о том, как это сделать, вы можете его искать (я ответил на вопрос).

Если вы можете создать демонстрационный проект с этим дефектом, было бы намного легче отладить его, чем просто угадать, что делать. Вход в класс, который получает dealloc'd, проходит долгий путь, так как вы сразу увидите, что не освобождается, а затем лучше сосредоточиться на проблеме.

Ответ 2

В дополнение к ответу Дэвида Х я рекомендую всем, кто испытывает эту проблему, также проверять, UIDocument ли деинициализатор вашего View Controller, Model, UIDocument (если вы его используете) , когда он не нужен.

Если вы не освободите должным образом эти классы, и они содержат данные об изображении /VDO/содержимом, на которые ссылается UIKit, то это может привести к такому сценарию, где вы видите, VM: ImageIO использование памяти VM: ImageIO всегда увеличивается, и все же вы не видите утечки памяти когда вы используете инструменты, так как это содержимое теперь хранится внутри UIKit.

Я тоже дважды сталкивался с этой проблемой, и в моем случае оказалось, что мой деинициализатор модели никогда не вызывался из-за не связанных с этим проблем. Исправив эти несвязанные проблемы и убедившись, что моя Модель освобождена, непрерывный рост VM: ImageIO исчез.