Текст книги "Программирование мобильных устройств на платформе .NET Compact Framework"
Автор книги: Иво Салмре
Жанр:
Программирование
сообщить о нарушении
Текущая страница: 29 (всего у книги 69 страниц)
Резюме
Фоновые потоки, если только их правильно использовать, могут пригодиться вам для улучшения условий интерактивного взаимодействия конечного пользователя с мобильным приложением за счет повышения способности пользовательского интерфейса к отклику. Фоновые потоки необходимо использовать умеренно, для вполне конкретных целей и лишь в тех случаях, когда они могут помочь вам справиться с реальными трудностями, связанными с обеспечением приемлемых интерактивных свойств приложения, которые не могут быть разрешены при использовании высокоприоритетного потока. Лучше всего проектировать приложение на основе однопоточной модели, привлекая фоновую обработку лишь тогда, когда вы убеждены в ее необходимости.
При написании кода фоновых потоков и проектировании классов, к которым могут иметь доступ одновременно несколько потоков, следует проявлять особую осторожность. Весьма полезно тщательно документировать код приложения, явно указывая, к каким его фрагментам будут пытаться получить доступ одновременно несколько потоков, а к каким, что не менее важно, не будут. Постарайтесь, чтобы количество классов, функций, свойств и переменных-членов, которые должны совместно использоваться несколькими потоками, было как можно меньшим, и уделите повышенное внимание к проектированию, анализу, тестированию и документированию соответствующих фрагментов кода.
Как и в случае других аспектов проектирования, при реализации асинхронной обработки вам могут очень пригодиться конечные автоматы. Конечные автоматы значительно расширяют возможности управления выполнением фоновых задач. Их использование делает возможным предоставление фоновыми потоками информации о состоянии выполнения, а также обращение других потоков с запросами к фоновому потоку на выполнение определенных действий, например, с запросом на прекращение выполнения фоновой работы. Плодотворным методом абстрагирования является инкапсуляция фоновой задачи в отдельном классе, что позволяет рассматривать ее как от дельную логическую единицу, для которой определены входные и выходные данные.
Почти во всех случаях для управления пользовательским интерфейсом целесообразно предусматривать только один поток; этот поток должен быть основным потоком вашего приложения. Поток пользовательского интерфейса может осуществлять периодический опрос фоновых задач с целью получения информации о состоянии их выполнения и передавать эту информацию пользователю. В другом возможном варианте фоновые потоки могут передавать эту информацию пользовательскому интерфейсу посредством межпоточного взаимодействия, например, с помощью механизма Control.Invoke(), предоставляемого .NET Compact Framework.
Потоки являются весьма полезным, но сложным инструментом. Как и в случае любой другой новаторской методики, существует риск чрезмерного использования многопоточного выполнения. Неоправданное применение нескольких потоков снижает общую производительность приложения, а излишняя сложность многопоточных моделей затрудняет сопровождение и отладку кода. Используйте многопоточность лишь в тех случаях, когда в этом действительно существует необходимость, привлекая для этого как можно более простые подходы. Следуя этим простым советам, вы сможете воспользоваться всеми преимуществами многопоточности и при этом избежите множества ловушек, связанных с использованием нескольких потоков выполнения кода.
ГЛАВА 10
Производительность и XML
Введение: работа с XML
XML быстро становится излюбленным текстовым форматом, применяемым для хранения и передачи данных. Причины его повышенной по сравнению с обычными текстовыми файлами популярности имеют два аспекта: 1) иерархичность – данные могут легко сохраняться с использованием отношений "родительский-дочерний" между ними, и 2) полуструктурированность – XML допускает значительную гибкость в управлении структурной информацией, применяемой к данным, обмен которыми осуществляется. XML-данные могут либо жестко привязываться к определенной схеме (сама схема также может задаваться в виде XML-документа), либо передаваться как таковые в свободной форме без каких-либо формальных указаний относительно содержимого документа.
XML имеет много сходства с другим популярным форматом кодирования информации – HTML. HTML – это аббревиатура от HyperText Markup Language – язык гипертекстовой разметки, что, говоря простыми словами, означает использование "текстовых дескрипторов, описывающих то, как выглядит документ". Аналогичным образом, XML – это extensible Markup Language – расширяемый язык разметки документов, что в переводе на обычный язык означает использование "текстовых дескрипторов, описывающих данные". Язык XML является продуктом накопления опыта в процессе эволюции HTML, и оба эти языка происходят от более старого абстрактного формата SGML (Standard Generalized Markup Language – стандартный обобщенный язык разметки). Полуструктурированный иерархический текстовый формат HTML на практике доказал свою большую гибкость по сравнению со многими существующими до этого двоичными форматами. Популярные адаптированные варианты HTML, а затем и XML продемонстрировали, что компактностью двоичных форматов часто имеет смысл пожертвовать ради гибкости, расширяемости и переносимости текстовых форматов. Синтаксис дескрипторов и атрибутов, используемый в HTML для описания внешнего вида и содержимого документов, рассматривался многими разработчиками как мощная, расширяемая модель описания данных. Недостатки HTML обусловлены его быстрой эволюцией; поскольку в течение ряда лет этот формат претерпел естественные эволюционные изменения, в его синтаксисе имеются несоответствия, которые при последовательном подходе к разработке языка считались бы недопустимыми.
В силу эволюционной сложности этого формата браузеры обычно терпимо относятся к документам, "сформированным с отклонениями от строгих правил", то есть они не отказываются от обработки такого документа, а делают все возможное для того, чтобы в любом случае представить документ пользователю. В результате этого синтаксический анализ HTML-документов излишне затруднен. XML заимствует принятый в HTML подход, в котором используется текстовый формат, а также синтаксис дескрипторов и атрибутов, но при этом поддерживает нормализованный синтаксис, пригодный для использования совместно с универсальными механизмами синтаксического разбора. Кроме того, XML-анализаторы обычно требуют, чтобы документы были корректно сформированными и завершенными; строгое следование синтаксическим правилам формирования XML-документов существенно улучшает возможности использования их на различных платформах. Благодаря этому широко доступные XML– анализаторы находят самое разнообразное применение.
Как и HTML, язык XML имел успех постольку, поскольку была достигнута договоренность о его использовании для обмена информацией между различными системами. Важность широкого принятия этой методики невозможно переоценить. После того как формат получает всеобщее одобрение, вступают в силу сетевые эффекты, и популярная технология очень быстро становится доминирующей. На протяжении последних лет сфера применения XML постоянно расширяется, и теперь он используется в качестве базового формата для многих высокоуровневых коммуникационных форматов, включая SOAP (Simple Object Access Protocol – простой протокол доступа к объектам; лежит в основе Web служб), WSDL (Web Service Description Language – язык описания Web служб), XSL (eXtensible Schema Language – расширяемый язык описания схем), RSS (Really Simple Syndication – подлинно простое объединение данных; механизм распространения данных) и многие другие форматы. Некоторые XML-форматы носят универсальный характер, тогда как другие являются специфическими для определенной отрасли или технологии, принятой в компании. В настоящее время при проектировании новых форматов хранения и обмена данными вопрос часто заключается не в том, следует ли использовать XML, а в том, какой уровень абстракции поверх XML следует использовать. Вероятнее всего, установленные на вашем мобильном устройстве приложения, взаимодействующие с сетью, используют для нужд связи, хранения и обмена данными именно XML. Вы можете использовать данные в XML– форматах других систем, но вам также может потребоваться разработка собственных XML-форматов, которые должны будут использовать другие люди. Существуют различные подходы к организации работы с XML-документами, соответствующие различным уровням абстракции. Каждый из них характеризуется своими достоинствами и недостатками. По этим причинам очень важно твердо знать, как работать с XML, чтобы это наилучшим образом отвечало вашим запросам.
Как бы полезен ни был XML, важно понимать, что он не является панацеей, позволяющей удовлетворить все нужды обмена данными. XML предлагает гибкость, но это достигается за счет высокой степени детализации описания данных. Всегда следует рассматривать возможность использования как XML, так и двоичных форматов для обмена данными, и выбор между ними должен основываться на объеме данных, подлежащих обмену, и природе коммуникационных сетей, которые использует ваше мобильное приложение. Если удается использовать XML, то он обеспечит вам значительную гибкость, и его следует рассматривать в качестве предпочтительного варианта. Однако XML не годится для обмена большими объемами данных по линиям связи с небольшой пропускной способностью. Об этом очень важно не забывать при проектировании коммуникационной модели приложения.
В случае же если проблемы больших объемов и длительности передачи данных могут быть успешно решены, XML обеспечивает замечательные возможности для обмена данными между мобильными устройствами, между мобильным устройством и настольным компьютером или между мобильными устройствами и серверами. Выбор XML в качестве способа хранения и передачи данных является лишь первым в ряду решений. Не меньшее значение имеет выбор внутренних механизмов того, как ваше приложение будет осуществлять чтение и запись XML-данных. Как и в отношении многих других технических аспектов программирования, универсального рецепта здесь не существует, и приходится идти на различные компромиссы, учитывающие интересы разработчиков, удобство сопровождения кода и необходимость создания комфортных условий работы с программой для пользователя. В данной главе дается общий обзор такого рода базовых проектных решений.
XML или не XML?
При всех тех возможностях, которые кроются в XML, легко предположить, что этот язык должен был бы привлекаться всегда, когда требуется осуществлять обмен данными или их хранение. Тем не менее, это не так. Гибкость XML придает ему мощь, но это дается за счет увеличения размера документов. Если требуется осуществить обмен данными сравнительно небольшого объема, то XML великолепно подходит для этой цели. Так, при загрузке 20 строк форматированных записей базы данных размер XML-файла может достигать 20 Кбайт, тогда как при использовании для передачи данных двоичного формата они могут быть сжаты до 2 Кбайт или менее.
Разницей в длительности загрузки 20 Кбайт и 2 Кбайт данных обычно можно пренебречь по сравнению с тем временем, которое затрачивается на установление соединения с сервером, обмен необходимыми подтверждениями и другие операции по настройке соединения. В обоих случаях абсолютное время ожидания пользователем завершения передачи данных сравнительно невелико, поэтому различия в объеме сохраняемых данных не имеют превалирующего значения при выборе проектного решения в отношении формата хранения данных.
Для сравнительно небольших объемов данных использование XML является вполне оправданным, поскольку это позволяет вам воспользоваться при обмене данными всеми преимуществами этого гибкого формата. Однако, что если объем данных увеличится в 10 раз и для выбора варианта проектного решения вам придется отвечать на вопрос: что лучше использовать – 200 Кбайт данных XML или 20 Кбайт двоичных данных? Начиная с таких объемов данных, длительность ожидания пользователем завершения процесса передачи данных между устройством и сервером становится все более заметной, и для принятия взвешенного решения требуется выполнить объективные измерения для каждого варианта реализации.
Важным фактором, который обязательно должен учитываться, является скорость передачи данных в сетях, используемых вашим мобильным устройством. Для некоторых данных при работе в сетях Wi-Fi проблемы длительности процесса обмена данными вообще не существует, тогда как в случае сетей мобильных телефонов, использующих протокол GRPS, может потребоваться тщательный анализ временных и стоимостных факторов. Если бы объем передаваемых данных был еще на порядок больше и вам пришлось бы выбирать между 2 Мбайт XML-данных и 200 Кбайт двоичных данных, то от вашего решения, какой формат данных использовать, зависело бы еще больше, поскольку теперь уже, скорее всего, задержки на установку соединения будут пренебрежимо малы по сравнению с длительностью фактической передачи данных. И при всем этом нельзя сбрасывать со счетов тот факт, что синтаксический анализ XML-данных потребует, как правило, большего времени по сравнению с анализом двоичных данных, специально оптимизированных под многократные загрузки.
При небольших объемах данных использование XML обычно не должно вызывать никаких сомнений. С ростом же объема данных необходимо уделять все большее внимание выбору проектного решения, а также измерению объективных временных показателей и тестированию, которые помогут выяснить, перекрывают ли преимущества, обеспечиваемые использованием XML, те дополнительные накладные расходы, которые это за собой влечет. Как и в случае других детализированных форматов, перед передачей XML-документов их можно сжимать, чтобы уменьшить объем передаваемых данных, а после передачи – распаковывать, но это означает дополнительную обработку данных и привязывает сервер и клиента к использованию общего формата сжатия; разумеется, это вполне осуществимо, но не может использоваться в качестве универсального рецепта. Очень важно, чтобы решение принималось вами со знанием дела, на основании тщательно установленных фактов и оценки последствий с точки зрения конечного пользователя. Каждая ситуация имеет свои особенности и определяется запросами пользователей, природой используемых коммуникационных сетей и сравнительной стоимостью передачи двоичных и XML-данных по сетям. Экспериментируйте, почаще измеряйте объективные показатели и принимайте продуманные решения.
Сравнение XML с другими текстовыми форматами
Существует огромное количество литературы, посвященной описанию XML, и полное рассмотрение этой темы выходит далеко за рамки данной книги. Тем не менее, имеет смысл представить краткий сравнительный обзор того, как XML соотносится с другими текстовыми форматами. Ниже это будет показано на конкретных примерах.
Различные способы хранения данных в виде текстаПредположим, что в нашем приложении требуется сохранять некоторые пользовательские данные. Эти данные состоят из трех элементов: идентификационного номера ID, имени и адреса. Приложению требуется сохранять эти данные для собственных нужд, но оно также может передавать их другому приложению. Тремя наиболее распространенными способами хранения таких данных в виде текста являются XML, значения с запятыми в качестве разделителей и значения в виде INI-файлов.
Сохранение данных в виде XML
Как и в случае HTML, в XML данные сохраняются в виде текста, заключенного между дескрипторами, которые дополняют передаваемые данные контекстом:
Следует отметить, что в XML те же данные можно сохранить с использованием атрибутов, например:
При необходимости можно использовать сочетания дескрипторов и атрибутов. Какой формат XML окажется самым подходящим, зависит от конкретной ситуации. Атрибуты проще использовать, но дескрипторы обладают большей гибкостью, поскольку они могут иметь атрибуты и вложенные дескрипторы.
Сохранение данных в текстовых файлах с разделителями-запятыми
Ранее для сохранения данных рассматриваемого типа часто применялись файлы, в которых для разделения элементов данных используются запятые:
12, Bob, "SomePlace, Somewhere"
Сохранение данных в INI-файлах
В прошлом популярным способом сохранения данных были INI-файлы. В INI-файлах данные сохраняются в виде пар "имя-значение":
[UserInfo]
UserID=12 UserName=Bob
UserAddress=Someplace, Somewhere
Существуют и другие распространенные форматы, например PropertyBag, которые по своим структурным свойствам и гибкости занимают промежуточное положение между XML и INI-файлами и были популярными среди разработчиков на Visual Basic 5 и 6. Что выделяет XML и ставит его выше многих предыдущих форматов – так это дополнительное структурирование данных. Эта структура делает возможным создание иерархических данных без расположения их в определенном порядке. Такой формат оказывается несколько более детализированным, чем многие другие текстовые форматы, но зато и гораздо более гибким. Эта гибкость значительно облегчает учет различий в версиях данных, а также сопровождение и передачу данных между различными системами.
Иерархическая структура XML-данныхОчень важно хорошо понимать иерархическую структуру XML. Представляйте себе XML-документ в виде дерева объектов, у каждого из которых могут иметься дополнительные дочерние объекты. Для демонстрации этого изменим приведенный выше пример таким образом, чтобы внести в него дополнительную иерархию:
Здесь мы сделали узлы Name и Address подузлами UserInfo.
Другие возможности XMLВ XML имеется гораздо больше возможностей, чем те, о которых было рассказано выше, включая стандартизованные схемы, типизированные данные и средства проверки действительности документов. В приведенных выше примерах были представлены лишь самые тривиальные образцы фрагментов XML. Хорошее описание всех тонкостей XML вы найдете как в документации .NET Framework, так и, как обычно, в Web. Данная книга и приводимые в ней примеры фокусируют внимание на практических аспектах использования XML на мобильных устройствах и ни в коей мере не могут рассматриваться в качестве исчерпывающего источника информации обо всех возможных сферах применениях XML.
Что касается практического использования, то в большинстве случаем XML-данные, участвующие в обмене, попадают в промежуток между двумя крайними категориями: строго структурированными данными и данными свободной формы. Какой уровень строгости следует применять к форматам данных, решают совместно как отправитель, так и получатель данных. Вычислительный узел, генерирующий XML-документы, может придерживаться строго определенной схемы или же просто может выбирать ту форму XML-кодирования, которая является для него наиболее удобной. Аналогичным образом, вычислительный узел, получающий XML-документы, может либо выполнять проверку их содержимого на предмет соответствия предполагаемой схеме, либо предполагать, что данные форматированы корректно, и сразу же пытаться осуществить синтаксический анализ результатов. Поскольку такие операции, как верификация схемы, могут быть трудоемкими в вычислительном отношении, то в тех случаях, когда такая проверка нужна, лучше, чтобы она осуществлялась на сервере до передачи данных устройству.
Различные способы работы с XML
Широкая применимость и всеобщее признание языка XML способствовали его быстрому развитию. Параллельно со становлением языка возникли модели, которые значительно упрощают работу с XML. Как правило, если существуют специализированные API-интерфейсы, ориентированные на XML, то при работе с XML следует избегать использования API-интерфейсов обычного файлового ввода вывода. Достоинством высокоуровневых АРI-интерфейсов является то, что они значительно повышают производительность труда разработчика, перекладывая бремя проектирования и тестирования соответствующих средств на специалистов, чьей единственной задачей было создание высокоэффективных XML-анализаторов. Если вы возьметесь за написание собственного анализатора, то потратите массу времени на решение задачи, которая уже давно решена на множестве самых различных платформ; лучше приложите свои усилия в тех областях, где вы сможете предложить что-то новое.
Несмотря на существование надежно протестированных высокопроизводительных API-интерфейсов, вам все равно придется принять несколько важных проектных решений, относительно использования XML. Самое важное из них касается того, API-интерфейс какого уровня абстракции следует использовать. Вы должны определиться, будете ли вы работать с низкоуровневым API-интерфейсом XML, допускающим только однонаправленную обработку документов, или с API-интерфейсом XML более высокого уровня, который обеспечивает возможности произвольного доступа с представлением XML-документа в виде дерева в памяти устройства. При работе с XML-данными вы можете использовать один из трех основных подходов:
1. Создать собственный "оптимизированный" анализатор с нуля. При наличии ранее разработанных и протестированных методик это почти никогда не стоит делать. Причина, по которой применять такой подход категорически не рекомендуется, заключается в том, что получаемые при этом преимущества лишь в редких случаях окупают усилия, затрачиваемые на разработку и последующее сопровождение соответствующих программ.
2. Использовать высокоуровневые универсальные методы синтаксического анализа с произвольным доступом, основанные на модели XML DOM. DOM (Document Object Model – объектная модель документов) обеспечивает возможность работы с XML-данными, хранящимися в памяти в виде иерархического дерева объектов. В результате использования высокоуровневого API-интерфейса для работы с XML вы получаете в высшей степени надежный код, удобный в сопровождении. Такой подход является оптимальным для небольших XML-документов, а также документов, при работе с которыми требуется постоянный произвольный доступ ко всем частям дерева XML документа, или документов, которые должны быть заново целиком сохранены в файле на диске.
3. Использовать низкоуровневый API-интерфейс XML, обеспечивающий выполнение лишь однонаправленных операций чтения-записи данных. Применение низкоуровневых API-интерфейсов позволяет максимально повысить производительность, но возлагает дополнительную нагрузку на программистов. Эти API-интерфейсы поддерживают выполнение операций чтения записи данных только в прямом направлении и позволяют считывать или записывать данные XML-дерева в виде потока XML-элементов без сохранения всего документа в памяти. В случае мобильных устройств, для которых память всегда является дефицитным ресурсом, и особенно при работе с большими объемами данных или данными, предназначенными только для чтения, только такой подход и обеспечивает достижение приемлемой производительности. Он представляет собой хорошую основу, являющуюся промежуточной между использованием высокоуровневых АРI-интерфейсов и развертыванием собственной методики. Такой путь является разумным, если привлечение высокоуровневых API-интерфейсов для удовлетворения ваших нужд требует интенсивных дополнительных вычислений и приводит к чрезмерному расходу памяти.
Первый из упомянутых подходов применять не рекомендуется, поскольку он снижает производительность труда разработчиков и затрудняет последующее сопровождение программного обеспечения. Сравнительный анализ остальных двух подходов представлен ниже.
