iPhone OS: стратегии для работы с изображениями высокой плотности

Question

У меня есть проект, который готовится этим летом, и который, возможно, будет включать в себя чрезвычайно большой объем данных изображений для отображения. Мы говорим о сотнях изображений размером 640x480 дюймов в заданном сеансе приложения (масштабированных до меньшего разрешения при отображении) и нескольких очень больших (1280x1024 или выше) изображений за раз.

Я уже проделал некоторую предварительную работу и обнаружил, что типичное изображение размером 640x480 пикселей - это просто тень размером менее 1 МБ в памяти при помещении в UIImageView и отображении ... но очень большие изображения могут быть колоссальными 5+ МБ в некоторых случаях.

Этот проект на самом деле нацелен на iPad, который, по моим тестам на инструментах, имеет примерно 80-100 МБ адресуемой физической памяти.

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

Я, вероятно, на высшем уровне промежуточного уровня в Objective-C ... поэтому я ищу некоторые твердые статьи и советы по следующим вопросам:

1) Ответственное управление UIImage и UIImageView во имя сохранения физической ОЗУ 2) Преимущества использования CGImage поверх UIImage, особенно для огромных изображений, и если будет какое-либо повышение производительности 3) Все, что связано с подкачкой памяти, особенно в отношении изображений

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

Answer 1

CATiledLayer - это, вероятно, путь. Единственная причина для создания UIImageView для каждого изображения, если вам нужна интерактивность, управляемая для вас. CATiledLayer позволит вам загружать и рисовать изображения асинхронно из фоновых потоков по мере необходимости. Просто используйте CGImage, так как это то, что вы все равно будете рисовать на слое.

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

Answer 2

Это довольно большой вопрос, поэтому я укажу вам на проект с открытым исходным кодом.Возможно, вы сможете повторно использовать этот проект оптом, добавив свой сервер в качестве источника данных (если это имеет смысл в формате lng / lat, что может иметь смысл), или вы можете воспользоваться некоторыми шаблонами проектирования и напрямую реализовать свои требования.

http://code.google.com/p/route-me/source/browse/trunk#trunk/MapView/Map

Тот факт, что ваши изображения имеют размер 1 или 5 МБ, не является проблемой, поскольку вы должны отображать только 1 или 4 изображения одновременно.Затем асинхронный загрузчик кеша, который заполняет и стареет ваш кеш изображений, основываясь на том, что пользователь может посмотреть дальше.Затем, когда пользователь взаимодействует, возьмите изображение из кеша (или счетчик при промахе кеша) и добавьте его в CALayer и вставьте его в иерархию CALayer.около.Я бы связался с кем-то из вышеупомянутого проекта или просто следовал их примеру.На основании того, что я знаю о проекте, это означает один UIView для родительского контейнера, который передает события, и использование CALayers для всех листов.CGImageRefs используются в CALayers, поэтому придерживайтесь их тоже.

Надеюсь, это поможет.

Answer 3

Изображения обычно содержат много повторяющихся данных и являются хорошими объектами для сжатия. это зависит от того, какой формат вы используете для своих изображений и имеет ли он встроенную компрессию. Моя первая мысль - придерживаться формата png, потому что он встроен в iPhone, и каким-то образом использовать архив сжатия для большей части ваших изображений. Что-то вроде .zip или .rar.

Если вы можете определить пакеты изображений, с которыми может столкнуться пользователь, вы можете разархивировать их и представить их пользователю. Использование подмножества архива миниатюр также может быть полезным.

Я не уверен, что все это сжатие и распаковка будет влиять на ваше время отклика, но идея сохранить ваш объем памяти меньше.