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

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

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

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

Выбор подходящих абстракций для хранения данных в памяти

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

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

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

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