Программирование мобильных устройств на платформе .NET Compact Framework
Шрифт:
Повышение производительности приложения перекладыванием работы на другие программы
Разработчики уделяют огромное внимание поиску реализаций алгоритма, которые позволяют добиться максимального быстродействия. А вот о том, стоит ли вообще выполнять данную работу на мобильном устройстве, они чаще всего не задумываются. Во многих случаях некоторая работа может быть выполнена еще до того, как данные поступят на устройство, или переложена на сервер и выполнена в ответ на запрос. Располагая большими объемами доступной
Лучше всего обрабатывать XML-данные на сервере еще до того, как они поступят на устройство. Если приложение ориентировано на использование данных, прошедших предварительную сортировку, фильтрацию и преобразования, то выполнение этой работы на сервере, прежде чем данные попадут на устройство, может принести вам реальные дивиденды в плане производительности. Эта задача заслуживает того, чтобы вы направили на нее часть своей творческой энергии.
Избегайте выполнения сложных преобразований данных на устройстве
Во многих случаях XML-данные удобно преобразовать к другому виду, облегчающему их непосредственный просмотр пользователем. В качестве простого примера можно привести заполнение элементов управления ListBox или ListView данными из XML-документа. Более сложным примером является генерация HTML документов на основе XML-данных. В каждом из этих случаев XML-данные подвергаются определенному преобразованию, позволяющему представить их в удобочитаемом виде. Преобразования часто имеют сложную природу и требуют больших затрат процессорного времени. Старайтесь находить способы, позволяющие выполнять как можно больший объем такой работы на сервере еще до того, как данные попадут на устройство. Чем больший объем трудоемких преобразований будет выполнен на сервере, тем меньшая нагрузка будет возлагаться на устройство
Если данные, считываемые из базы данных, нуждаются в тех или иных преобразованиях, рассмотрите возможность использования промежуточной Web-службы, развернутой на сервере, в задачи которой будет входить преобразование данных до отправки их на устройство.
Избегайте выполнения сложного поиска данных на устройстве
Другой типичной задачей, которую часто приходится решать в приложениях, является поиск данных в ответ на запрос определенной информации. С задачами поиска, фильтрации и сортировки данных приходится иметь дело в большинстве приложений, работающих с данными. Возможные варианты поиска укладываются в диапазон, охватывающий как самые простые схемы поиска, так и сложнейшие методы просмотра данных. Точно так же, как и в случае преобразования данных, предварительное выполнение поиска, организация и фильтрация данных с целью придания им более удобных для доступа форм будут способствовать значительному улучшению производительности приложения. Если вы собираетесь загружать с сервера XML-документы, в которых будет производиться поиск определенной информации, рассмотрите возможность заблаговременного проведения поиска на сервере с тем, чтобы загружать лишь результаты этого поиска; благодаря этому вы сможете сократить длительность обработки данных на устройстве и уменьшить объем данных, подлежащих загрузке.
Рассмотрите возможность исключения необязательной информации перед отправкой данных на устройство
Пересылка необязательной информации на устройство занимает дополнительное время как при передаче данных, так и при выполнении синтаксического анализа данных на устройстве. Если вы имеете дело с XML-документами, содержащими большое количество информации, которая на устройстве использоваться не будет, то стоит рассмотреть возможность обработки документа на сервере с целью исключения из него избыточной информации. Это позволит серверу отделить зерна от плевел и пересылать на устройство лишь действительно полезную информацию
Когда не стоит перекладывать выполнение работы на сервер
Очень важно, чтобы вы понимали, в каких случаях выполнение некоторой работы лучше переложить на сервер, но не менее важно, чтобы вы умели различать и случаи, когда так поступать не стоит. В настоящее время ведется очень много разговоров о распределенных вычислениях, которые предполагают выталкивание работы любого рода на другие устройства в сети. Сама по себе эта идея весьма привлекательна, но практическая ее реализация сопряжена с большими трудностями. Как правило, выталкивать работу с устройства на сервер для немедленного выполнения не стоит. Если только подлежащие обработке данные не отличаются высокой плотностью и не требуют выполнения трудоемкого анализа, вам не удастся избежать связанных с этим лишних затрат времени, неудобств, необходимости заботиться о надежности соединений, а также возможных дополнительных расходов на двусторонний обмен данными через сеть. Выталкивание данных с устройства на сервер для немедленной обработки может быть оправданным, например, в случае анализа сложных изображений, когда такие данные, как результаты аэрофотосъемки или медицинские снимки, полученные с использованием камеры высокого разрешения, требуют проведения трудоемкого с вычислительной точки зрения алгоритмического анализа. В подобных ситуациях обмен данными между сервером и устройством оказывает на производительность приложения пренебрежимо малое влияние по сравнению с необходимой обработкой; в этом случае задержки, обусловленные пересылкой данных, компенсируются выигрышем в скорости обработки данных на более мощном оборудовании. При этом длительность обработки данных на устройстве должна сравниваться с суммарным временем задержки, связанной с пересылкой данных на сервер, и длительностью их обработки на сервере с учетом того, что сервер не всегда будет доступным
При проектировании .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-данных, что делает эту модель в высшей степени зависимой от состояния. При работе с крупными документами этот недостаток может иметь критическое значение.