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

Автор книги: Иво Салмре

сообщить о нарушении

Текущая страница: 35 (всего у книги 69 страниц)

Выбор подходящих форматов и размеров растровых изображений

С растровыми изображениями приходится иметь дело как при низкоуровневой работе с графикой, так и при высокоуровневом проектировании пользовательского интерфейса. В описаниях большинства каркасов пользовательских интерфейсов упоминается элемент управления PictureBox, способный отображать битовые образы, а низкоуровневые графические библиотеки имеют дело главным образом с операциями на битовом уровне. Растровые изображения используются во многих разновидностях приложений, представляющих значительный интерес; достаточно привести в качестве примера приложения, в которых используются карты городских улиц, изображения медицинского назначения, фотографии объектов недвижимости или изображения игровых полей. В процессе работы с данными растровых изображений важно заботиться как о способах файлового представления изображений, так и об объемах памяти, занимаемых данными изображений. Для хранения и потоковой передачи данных существуют различные файловые форматы, у каждого из которых характеризуется своими достоинствами и недостатками. Независимо от того, файлы какого формата вы используете, в памяти растровые изображения обычно представляются в виде матрицы, соответствующей пиксельным размерам изображения; этот несжатый формат удобен тем, что обеспечивает быстрое использование изображений как графическим оборудованием, так и базовой операционной системой.

Размеры изображения имеют существенное значение

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

Для упрощения расчетов предположим, что мы имеем дело с изображениями в форме квадрата. Тогда 1-мегапиксельному изображению будет соответствовать матрица размером 1000×1000 пикселей. Такое разрешение значительно превышает возможности экранов большинства мобильных устройств, и до недавнего времени было слишком высоким даже для экранов настольных компьютеров (размеры которых обычно составляет 1024×768 = 786432 пикселя). Вместе с тем, даже недорогие современные цифровые камеры позволяют получать фотографии, состоящие из более чем 2-мегапикселей, однако не столь уж большой редкостью являются ныне 4– и 6-мегапиксельные камеры, причем этот пиксельный показатель с каждым годом возрастает.

Физические дисплеи с большим количеством пикселей потребляют больше электроэнергии по сравнению с экранами, обладающими низкой разрешающей способностью, их стоимость выше, они занимают больше места и являются более хрупкими. Кроме того, с увеличением размеров экрана возрастают требования к памяти устройства и его вычислительным возможностям в отношении графики. Несомненно, с течением времени количество пикселей на экранах мобильных устройств будет только расти, но есть все основания полагать, что это будет происходить с запаздыванием по отношению к тем величинам разрешений, которые будут становиться доступными для цифровых камер и настольных дисплеев. Если допустить, что размеры дисплея мобильного устройства составляют 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 пикселей, то использовать следует изображения с такими же размерами.

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

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

Уменьшение размера файла: достижение баланса между степенью сжатия и разрешением изображения

Для уменьшения размеров файлов цифровых изображений используют три способа:

1. Снижение разрешения. Суть этого способа заключается в уменьшении фактического количества пикселей, составляющих изображение. Если в Windows XP войти в программу Paint, выбрать в меню Рисунок пункт Растянуть/наклонить и уменьшить изображение до 50% его первоначальной ширины, то количество пикселей в изображении уменьшится наполовину. Уменьшив далее изображение до 50% его первоначальной высоты, вы еще раз уменьшите его разрешение в два раза. Теперь количество пикселей в полученном изображении будет составлять 25% от первоначального (0,5×0,5 = 0,25). Уменьшение количества пиксельных данных, подлежащих сохранению, означает уменьшение общего размера изображения.

2. Выбор наиболее подходящего формата файлов. Различные разновидности распространенных файловых форматов отличаются друг от друга своей способностью сжимать различные изображения. Одни форматы хорошо подходят для фотографий (множество цветовых оттенков, мало резких границ), другие больше всего пригодны для сохранения компьютерной графики (резкие границы изображений, небольшое количество цветовых оттенков). В некоторых форматах сжатие изображений вообще не применяется. Выбор наиболее подходящего формата позволит обеспечить наилучшее качество изображения при минимальном размере.

Некоторые файловые форматы обеспечивают дополнительную возможность выбора глубины цвета сохраняемого изображения. Глубина цвета представляет собой количество битов, используемых для описания изображения. Если можно обойтись меньшим количеством цветов, то выбор меньшей глубины цвета позволит уменьшить размер файла.

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

Чтобы добиться снижения размера файла изображения, начните с разрешения. Уменьшите размер изображения, приведя его в соответствие с размерами экрана вашего устройства; благодаря этому вы сможете избавиться от ненужных данных. Далее, выберите подходящий формат файла, который обеспечивает наилучшее качество изображения при минимально возможном размере файла и минимальной глубине цвета. Наконец, если применяется метод сжатия с потерями, поэкспериментируйте с параметрами сжатия.

Так много файловых форматов и так мало времени…

Существует множество файловых форматов, которые можно использовать для работы с цифровыми изображениями. Каждый из них характеризуется своими преимуществами и недостатками. Ниже приводятся описания наиболее распространенных форматов, которые часто поддерживаются на мобильных устройствах.

Формат JPG/JPEG

В полном соответствии со своим названием файлы JРЕG (Joint Photographic Expert Group – Объединенная группа экспертов в области фотографии) являются непревзойденными при хранении фотографических и реальных изображений. JPEG – это формат сжатия, допускающий регулирование потери качества изображений, что в общем случае позволяет обеспечивать отличное сжатие файлов за счет лишь незначительного ухудшения качества изображения. Во всех JPEG-фотографиях, полученных обычными цифровыми камерами, используется сжатие с потерями. Именно благодаря этому удается сжимать потрясающие 3-мегапиксельные изображения до размера 600 Кбайт. В более сложных программах рисования можно регулировать степень сжатия JPEG-файлов, что позволяет добиваться наилучшего баланса между качеством и размером изображения. При использовании формата JPEG фотографии, адаптированные к разрешению экрана Pocket PC, могут быть сжаты до размера менее 20 Кбайт, но, несмотря на это, будут отлично выглядеть.

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

Формат PNG

Формат PNG (Portable Network Graphics – переносимая сетевая графика) является, можно сказать, новичком среди файловых форматов, однако этот новичок быстро завоевывает признание в качестве превосходного формата файлов, предназначенных для хранения изображений. Попытки создания формата PNG были реакцией на возникновение некоторых проблем, связанных с защитой прав на интеллектуальную собственность в отношении формата GIF. Файлы формата PNG обеспечивают отличное сжатие без потерь в случае цифровых изображений. Если ваша платформа поддерживает изображения PNG и вам необходимо сжатие без потерь, то это именно тот формат, который вам нужен. Формат PNG во многих случаях обеспечивает значительно лучшее сжатие, чем формат GIF, и при доступности обоих форматов предпочтение следует отдавать именно ему.

Формат GIF

Формат GIF (Graphics Interchange Format – формат графического обмена) можно считать предшественником формата PNG. GIF-файлы также предлагают сжатие без потерь, но ограничены использованием 256 цветов. Из-за этого ограничения формат GIF не годится для хранения фотографических изображений. GIF-файлы интенсивно использовались при создании Web-страниц в Internet в первые годы своей популярности и по этой причине продолжают находить широкое применение и в наши дни.

Формат BMP

Битовые образы (bitmaps) хранят несжатые данные изображений. Формат сохраняемых в BMP-файлах данных аналогичен формату хранения битовых образов в памяти. Помимо того, что не требуется выполнять дополнительную работу по распаковке файлов, использование BMP-файлов не имеет никаких преимуществ, если не считать их широкой доступности.

В том, что касается разработки приложений для .NET Compact Framework, JPG– файлы больше всего подходят для фотографических изображений, а PNG-файлы – для битовых образов, требующих максимально достоверной передачи изображений. Ситуации, в которых требуется полная, с точностью до пикселя, достоверность передачи изображений, обычно встречаются тогда, когда некоторое изображение будет использоваться с определением одного цвета пикселей в качестве прозрачного. Области прозрачности могут применяться при создании сложных рисунков, когда одни рисунки "просматриваются" через другие, о чем будет более подробно говориться далее в главе 13.

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

Многие современные мобильные телефоны выпускаются с установленными в них цифровыми камерами, позволяющими получать фотографии. При этом размеры некоторых изображений могут превышать 1 мегапиксель (1000×1000 пикселей), и можно не сомневаться, что эта тенденция будет только усиливаться. Как и фотографии, получаемые с помощью цифровых фотокамер, разрешение таких изображений значительно превосходит те пределы, выше которых нормальный вывод изображений на экраны устройств становится невозможным; эти изображения предназначены для просмотра на экранах с большими размерами (настольные компьютеры) или для вывода на печать. Загружать и удерживать в памяти битовые образы таких размеров слишком расточительно, однако из-за проблем задержек и устойчивости связи бессмысленно пытаться отсылать картинку на сервер для ее уменьшения, чтобы получить ее обратно на устройстве в уменьшенном виде. Решение, которое позволяет работать с изображениями, характеризующимися высоким разрешением, и вместе с тем сохраняет возможность эффективного управления памятью устройства, состоит в следующем:

1. Загрузите изображение с высоким разрешением в память. Примечание. Если изображение достаточно велико, то такая загрузка на деле может оказаться невозможной; в этом случае должно быть каким-то образом получено изображение с более низким разрешением, причем это может делаться даже на стадии получения самого изображения. Изображение с более низким разрешением может храниться вместе с полномасштабным изображением.

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

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

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

Различные подходы к реализации пользовательских интерфейсов в управляемых средах выполнения

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

.NET Compact Framework, выполняющаяся на устройствах, использующих операционные системы Windows СЕ, Pocket PC и Smartphone, предоставляет визуализацию большинства своих элементов управления пользовательского интерфейса и управление ими операционной системе. Под этим подразумевается что элементу управления Window платформы .NET Compact Framework соответствует элемент управления Window операционной системы Windows СЕ, элементу управления ListView платформы .NET Compact Framework – элемент управления ListView операционной системы Windows СЕ, элементу управления Button платформы .NET Compact Framework – элемент управления Button операционной системы Windows СЕ и так далее. Преимущества такого подхода обусловлены несколькими причинами:

1 Производительность. Специалисты по разработке операционных систем затратили много времени на проектирование и настройку элементов управления своих пользовательских интерфейсов. Добиться аналогичной производительности при перерисовке всех окон и элементов управления и обеспечить надлежащее управление их взаимодействием с пользователем путем самостоятельной реализации этих возможностей очень трудно.

2. Внешний вид и нюансы поведения. Элементы управления .NET Compact Framework обладают теми же поведенческими характеристиками, что и элементы управления базовой системы Windows. Реализация пользовательского интерфейса сопряжена с необходимостью принятия множества мелких решений наподобие: "Как именно должны прорисовываться пиксели при визуализации элемента управления? Что должно происходить, если выделить блок текста и нажать клавишу забоя, ввести букву, выполнить двойной щелчок на слове?" Добиться точного воспроизведения внешнего вида и нюансов поведения пользовательского интерфейса очень трудно, а вместе с тем люди очень чувствительны к малейшим отклонениям от того, к чему они привыкли.

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

Несмотря на то что в .NET Compact Framework, выполняющейся на устройствах с операционными системами Pocket PC, Smartphone или Windows СЕ, реализация большинства элементов пользовательского интерфейса делегируется операционной системе, это вовсе не означает, что вы не имеете возможности создать совершенно новый элемент управления средствами каркаса приложения. В .NET Compact Framework можно создать графический элемент управления с нуля, и это делается в тех случаях, когда в базовой операционной системе аналогичный элемент управления отсутствует. Эту работу может выполнить конечный разработчик, но для таких элементов управления, как GridControl, она была выполнена и в .NET Compact Framework.

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

Если .NET Compact Framework переносится на другую платформу (в процессе ее проектирования такая возможность заранее предполагалась), то она должна будет либо использовать возможности пользовательского интерфейса базовой операционной системы, либо предоставить свою реализацию этих элементов управления в виде библиотек на основе собственного или управляемого кода. По своим возможностям встроенной поддержки элементов управления пользовательского интерфейса операционные системы различных устройств существенно отличаются друг от друга, так что объем работы, которую при этом придется выполнить, и выбор стратегии проектирования оказываются в высшей степени зависящими от характеристик конкретной целевой операционной системы.