У меня есть приложение, чтобы его часть отображала сетку изображений. Каждый ImageView составляет 200x150, но сами изображения 1024x768. Если я попытаюсь просто установить эти изображения, скоро я получу предупреждения о памяти и, возможно, даже погибну.Могу ли я использовать contentScaleFactor для безопасного сохранения памяти?
С другой стороны, если изменение размера этих изображений в коде очень дорого и требует много времени.
Теперь я смотрел в одном из видео сеансов «Apple WWDC», и парень там упомянул contentScaleFactor UIView, который отвечает за количество фактической растровой памяти, выделенной для отображения представления.
В документации они только упоминают случаи масштабного коэффициента больше единицы, но я забочусь о настройке его значение меньше единицы:
// Make sure not to divide by zero
if (image.size.width > 0 && image.size.height > 0)
{
CGFloat widthRatio = self.imageView.frame.size.width/image.size.width;
CGFloat heightRatio = self.imageView.frame.size.height/image.size.height;
CGFloat aspectFitRatio = MAX(widthRatio, heightRatio);
aspectFitRatio = MIN(1, aspectFitRatio);
[self.imageView setContentScaleFactor:aspectFitRatio];
}
Таким образом, мой ImageView выделит гораздо меньше памяти.
Мой вопрос: я прав? действительно ли это спасет память? Является ли даже «законным» установить contentScaleFactor на < 1 значения?
Спасибо!
Объект изображения не такой большой. Это резервный магазин для рендеринга, который ест память. Например, jpg-изображение с размером 1024x768 занимает примерно 300 КБ. Это связано с тем, что формат jpg сжимается. но если вы хотите отобразить это изображение, каждый пиксель должен быть представлен в своем собственном байте (по крайней мере), поэтому память, необходимая для рендеринга этого изображения, будет 1024x768 = 786kb. Поэтому уменьшение объема памяти хранилища резервной копии должно заметно повлиять на общий объем памяти. –
@Avrahamshuk. Большой вопрос (и он считается реализацией _detail_) - это когда изображение распаковывается. Если он распаковывается каждый раз, когда его нужно визуализировать, он потребляет мало памяти, но очень дорого перерисовывает. Если он распаковывается при чтении с диска, то выполняется обратное. Я думаю, что текущая реализация включает в себя ленивую загрузку (декомпрессию изображения, когда она нарисована в первый раз) и сохранение декомпрессированного изображения в ОЗУ для более быстрой перерисовки. Однако я могу ошибаться, и это может измениться в любой версии iOS. – Costique
Ваше предположение имеет смысл. Поэтому, если я могу заверить, что contentScaleFactor установлен до того, как изображение будет сначала нарисовано, я сохраню кучу памяти. Но я все равно не могу принять ваш ответ, хотя ... Теперь я пойду глубже в процесс рисования UIKit. –