Читаем Программирование мобильных устройств на платформе .NET Compact Framework полностью

Физические дисплеи с большим количеством пикселей потребляют больше электроэнергии по сравнению с экранами, обладающими низкой разрешающей способностью, их стоимость выше, они занимают больше места и являются более хрупкими. Кроме того, с увеличением размеров экрана возрастают требования к памяти устройства и его вычислительным возможностям в отношении графики. Несомненно, с течением времени количество пикселей на экранах мобильных устройств будет только расти, но есть все основания полагать, что это будет происходить с запаздыванием по отношению к тем величинам разрешений, которые будут становиться доступными для цифровых камер и настольных дисплеев. Если допустить, что размеры дисплея мобильного устройства составляют 500×500 пикселей, то экран в состоянии отображать в общей сложности 250000 пикселей. Это составляет всего лишь ¼ объема 1-мегапиксельного изображения и 1/16 объема 4-мегапиксельного. Если подойти к рассмотрению этого вопроса с другой стороны, то можно заметить, что для размещения 4- мегапиксельного изображения на дисплее Pocket PC с размерами 240×320 (76800 пикселей) потребуется отбросить 98% пикселей изображения, не попадающих в область экрана. Аналогичным образом, в случае 2-мегапиксельного изображения для размещения его на том же экране Pocket PC потребуется отбросить 96% пикселей, тогда как в 1-мегапиксельном изображении лишними окажутся 92% пикселей.

Почему мы об этом говорим? На то имеется несколько причин: 

■ Размер загружаемого файла. Если избыточные пиксели вашему приложению не нужны, то имеет ли смысл их загружать? Загрузка большего файла потребует больше времени, да и в деньгах это часто будет стоить дороже. Уменьшенные размеры экранов специально учитываются Web-приложениями для мобильных устройств, которые с этой целью используют изображения с низким разрешением. To же самое имеет смысл делать и в случае мобильных приложений с развитыми функциональными возможностями, развернутых на устройствах. 

■ Объем памяти, необходимый для храпения изображения на устройстве. Если ваше мобильное приложение загружает крупное изображение, то его необходимо где-то хранить. В типичных случаях для этого используется либо виртуальная файловая система в ОЗУ, либо флэш-память. В любом случае для чтения и записи изображений, размеры которых превышают необходимые, требуется дополнительное время, и они зря занимают память, которую иначе можно было бы использовать для хранения большего количества изображений или других данных. Что бы вы выбрали: иметь на своем устройстве только одно 4-мегапиксельное изображение или десяток изображений по размерам экрана? 

■ Внутреннее представление изображения в памяти. Пожалуй, это наиболее значимый из рассматриваемых нами аспектов. Если ваше мобильное приложение загружает в память 4-мегапиксельное изображение, то оно создает в памяти битовый образ, состоящий из 4 миллионов пикселей. Скажите, часто ли вам приходилось объявлять и использовать в своих приложениях целочисленные массивы, содержащие по 4 миллиона элементов? Объем памяти, необходимый для хранения такого массива, настолько огромен, что почти во всех случаях оказывается значительно больше объема загруженного кода и всей остальной памяти, относящейся к приложению. Независимо от эффективности используемого метода сжатия файлов, хранящийся в памяти битовый образ остается битовым образом и представляет собой отображение битов изображения в памяти устройства. Кроме того, если используемый вами файловый формат изображения предполагает привлечение сложных математических алгоритмов, обеспечивающих высокую степень сжатия данных, то эти же алгоритмы должны будут применяться и для распаковки изображений, что довольно-таки ощутимо скажется на производительности вашего приложения. Загрузка крупных растровых изображений в память — это прямая дорога к исчерпанию всей свободной памяти, доступной на устройстве, результатом чего будет либо полное падение производительности вашего приложения, либо его аварийное завершение вследствие нехватки памяти.

Мораль сей басни такова: не имеет никакого смысла использовать изображения с числом пикселей, превышающим размер экрана. Эти изображения будут медленно переноситься на устройство, потребуют использования больших объемов памяти для их загрузки и сохранения, и в любом случае должны будут урезáться до размеров, соответствующих размерам экрана мобильного устройства. Лучше всего согласовываться с размерами экранов доступных устройств и выбирать такие размеры изображений, которые соответствуют размерам рабочего пространства. Если в приложении предусмотрен элемент управления PictureBox, размеры которого должны составлять 120×120 пикселей, то использовать следует изображения с такими же размерами.

Перейти на страницу:

Похожие книги

Программист-прагматик. Путь от подмастерья к мастеру
Программист-прагматик. Путь от подмастерья к мастеру

Находясь на переднем крае программирования, книга "Программист-прагматик. Путь от подмастерья к мастеру" абстрагируется от всевозрастающей специализации и технических тонкостей разработки программ на современном уровне, чтобы исследовать суть процесса – требования к работоспособной и поддерживаемой программе, приводящей пользователей в восторг. Книга охватывает различные темы – от личной ответственности и карьерного роста до архитектурных методик, придающих программам гибкость и простоту в адаптации и повторном использовании.Прочитав эту книгу, вы научитесь:Бороться с недостатками программного обеспечения;Избегать ловушек, связанных с дублированием знания;Создавать гибкие, динамичные и адаптируемые программы;Избегать программирования в расчете на совпадение;Защищать вашу программу при помощи контрактов, утверждений и исключений;Собирать реальные требования;Осуществлять безжалостное и эффективное тестирование;Приводить в восторг ваших пользователей;Формировать команды из программистов-прагматиков и с помощью автоматизации делать ваши разработки более точными.

Эндрю Хант , Дэвид Томас , А. Алексашин

Программирование / Книги по IT
Разработка ядра Linux
Разработка ядра Linux

В книге детально рассмотрены основные подсистемы и функции ядер Linux серии 2.6, включая особенности построения, реализации и соответствующие программны интерфейсы. Рассмотренные вопросы включают: планирование выполнения процессов, управление временем и таймеры ядра, интерфейс системных вызовов, особенности адресации и управления памятью, страничный кэш, подсистему VFS, механизмы синхронизации, проблемы переносимости и особенности отладки. Автор книги является разработчиком основных подсистем ядра Linux. Ядро рассматривается как с теоретической, так и с прикладной точек зрения, что может привлечь читателей различными интересами и потребностями.Книга может быть рекомендована как начинающим, так и опытным разработчикам программного обеспечения, а также в качестве дополнительных учебных материалов.

Роберт Лав

Программирование, программы, базы данных / Программирование / Книги по IT