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

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

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

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

  //Если мы находимся в узле AllMyData, то переход возможен

  //в узлы, которые указаны ниже

  case (ReadLocation.inAllMyData): {

   if (nodeName == XMI_USERINFO_TAG) {

    currentReadLocation = ReadLocation.inUserInfo;

   }

   break;

  }

  //Если мы находимся в узле UserInfo, то переход возможен

  //в узлы, которые указаны ниже

  case (ReadLocation.inUserInfo): {

   if (nodeName == XML_USERID_TAG) {

    currentReadLocation = ReadLocation.inUserID;

   } else if (nodeName == XML_NAMEINFO_TAG) {

    currentReadLocation = ReadLocation.inName;

   }

   break;

  }

  //Если мы находимся в узле Name, то переход возможен

  //в узлы, которые указаны ниже

  case (ReadLocation.inName): {

   if (nodeName == XML_FIRSTNAME_TAG) {

    currentReadLocation = ReadLocation.inFirstName;

   } else if (nodeName == XML_LASTNAME_TAG) {

    currentReadLocation = ReadLocation.inLastName;

   }

   break;

  }

  }

 } //Конец функции

} //Конец класса

Повышение производительности приложения перекладыванием работы на другие программы

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

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

Избегайте выполнения сложных преобразований данных на устройстве

Во многих случаях XML-данные удобно преобразовать к другому виду, облегчающему их непосредственный просмотр пользователем. В качестве простого примера можно привести заполнение элементов управления ListBox или ListView данными из XML-документа. Более сложным примером является генерация HTML документов на основе XML-данных. В каждом из этих случаев XML-данные подвергаются определенному преобразованию, позволяющему представить их в удобочитаемом виде. Преобразования часто имеют сложную природу и требуют больших затрат процессорного времени. Старайтесь находить способы, позволяющие выполнять как можно больший объем такой работы на сервере еще до того, как данные попадут на устройство. Чем больший объем трудоемких преобразований будет выполнен на сервере, тем меньшая нагрузка будет возлагаться на устройство

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

Избегайте выполнения сложного поиска данных на устройстве

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

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

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

Когда не стоит перекладывать выполнение работы на сервер

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

Почему в версии 1.1 .NET Compact Framework не поддерживаются XSLT и XPath?

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

XPath – это язык запросов, используемый для проведения поиска в XML-документах. Этот язык предоставляет очень широкие возможности поиска, но отличается сложностью, и для его эффективного использования требуется значительная вычислительная мощность. XSLT – это технология преобразования дерева XML-документа в новый документ в соответствии с определенными правилами; эту технологию часто применяют для преобразования XML-данных в HTML-документы. Для его эффективного функционирования также требуются значительные вычислительные ресурсы.

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

Не исключено, что поддержка этих средств появится в последующих версиях .NET Compact Framework; в частности, существует настоятельная потребность в поддержке XPath. Однако разработчикам следует хорошенько подумать о том, с какими трудностями им придется столкнуться, если они решатся на использование пусть и ценных, но весьма требовательных в отношении необходимых вычислительных ресурсов библиотек. Обычно считается, что встроенные средства среды выполнения должны нормально функционировать при любых обстоятельствах, однако это далеко не так. Вспомните данные ранее в этой главе рекомендации относительно необходимости тщательно взвешивать достоинства и недостатки удобного, но требующего использования обширной информации о состоянии подхода, основанного на модели XML DOM, и более сложного, но менее зависимого от состояния подхода, основанного на однонаправленном доступе к данным с помощью объектов XMLReader и XMLWriter; руководствуйтесь этими же советами и тогда, когда возникает проблема выбора зависящей от состояния или требовательной к ресурсам библиотеки. Вы можете использовать такую библиотеку, но всегда оценивайте, с какими дополнительными расходами это будет сопряжено, и проводите соответствующие измерения.

Резюме

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

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

При работе с XML очень важно учитывать объем обрабатываемых данных и специфику их назначения. В случае небольших ХМL-документов (например, размером 20 Кбайт) часто оказывается удобным подход, основанный на модели XML DOM, в котором предполагается загрузка в память всего XML-дерева. Модель XML DOM обеспечивает произвольный доступ к данным документа и упрощает обратный вывод документа для его записи на накопитель или в поток. Существенным недостатком модели XML DOM является загрузка в память одновременная всех XML-данных, что делает эту модель в высшей степени зависимой от состояния. При работе с крупными документами этот недостаток может иметь критическое значение.

Разумной низкоуровневой альтернативой при работе с крупными XML-документами являются XML-библиотеки функций, предназначенных для однонаправленной обработки данных. В .NET Compact Framework предлагаются классы XMLReader и XMLWRiter, тогда как в других средах выполнения для однонаправленного доступа к XML-данным могут предоставляться средства модели SAX. Указанный подход позволяет добиться максимально возможной производительности, поскольку соответствующие средства зависят от состояния в меньшей степени и поэтому не нуждаются в загрузке в память дерева данных, представляющего документ. В случае сложных документов осложняется и работа с использованием объектов XMLReader; для отслеживания текущей позиции в иерархии документа может оказаться полезным подход, основанный на использовании конечных автоматов. Объекты XMLWriter упрощают вывод XML-данных с целью их записи в файл. При работе с большими объемами XML– данных на мобильных устройствах использование модели однонаправленной обработки данных может оказаться единственно разумным подходом.

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

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

ГЛАВА 11
Производительность графического кода и пользовательского интерфейса

М-р Брэддок: "Скажи-ка мне, ради чего тогда надо было так тяжко трудиться последние четыре года?"

Бенджамин Брэддок: "Ты меня достал…"

"Выпускник" (The Graduate) (1967)

Элен Робинсон: "Я не хочу, чтобы ты брался за что– либо без четко составленного плана".

"Выпускник" (1967)

Введение

Несомненно, "Выпускник" – один из лучших фильмов всех времен и народов, но какое это имеет отношение к разработке пользовательских интерфейсов мобильных приложений?

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

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

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

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

Можно выделить следующие аспекты вашей работы, от которых зависит эффективное функционирование создаваемых вами пользовательских интерфейсов:

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

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

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