ImageIO грязная память автоматически не очищается iOS

Question

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

Screenshot http://i40.tinypic.com/25ge51i.jpg

EDIT, еще один скриншот:

Screenshot http://i40.tinypic.com/9t1mh5.png

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

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

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

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

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

Answer 1

Сведя здесь слишком большой для комментариев, лишь некоторые идеи:

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

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

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

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

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

• подкласс UIImageView, использовать его для изображений и протоколирования, dealloc

• подкласса UIImage, использовать его для этих изображений, войдите в dealloc

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

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

Answer 2

В дополнении к ответу Дэвида H, я рекомендовал бы любой, кто испытывает эту проблему также проверить, если ваш взгляд контроллера, модель, UIDocument «s (если вы его используете) deinitializers называется, когда не требуется.

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

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