Программирование мобильных устройств на платформе .NET Compact Framework
Шрифт:
Распространенной ошибкой разработчиков является простой перенос на мобильные устройства моделей доступа к данным, которые применяются на настольных компьютерах и серверах, в неизменном виде, без тщательного анализа того, как это повлияет на использование памяти. Тот факт, что с подобной ошибкой приходится сталкиваться часто, вполне объясним, поскольку с точки зрения синтаксиса все программные модели аналогичны друг другу, и во многих случаях код, выполняющийся на настольных компьютерах и серверах, легко переносится на устройства. В то же время, простой перенос стратегий доступа к данным с настольных компьютеров и серверов на мобильные устройства позволяет получить удовлетворительные результаты лишь в редких случаях. Причину этого можно описать двумя словами — "состояние памяти". Более высокая степень абстрагирования часто достигается за счет создания объектов на дополнительных уровнях абстракции. Как создание, так и уничтожение этих объектов приводят к более жестким условиям использования памяти и занимают процессорное время.
Для мобильных приложений вопрос о выборе модели доступа к данным оказывается непосредственно связанным с вопросом о выборе модели управления памятью в гораздо большей степени, чем в случае приложений для настольных компьютеров. Если памяти, необходимой для обслуживания потребностей обеих моделей, едва хватает, то это может серьезно сказаться на производительности приложения. Аналогично средствам для работы с XML-данными, существуют низкоуровневые API-интерфейсы, не использующие состояния, и высокоуровневые программные модели доступа к памяти, предлагающие более развитые возможности, но кумулятивно изменяющие состояние в процессе выполнения. Использование высокоуровневых моделей доступа к данным позволяет
Впервые приступая к реализации стратегий доступа к данным на мобильных устройствах, разработчики, профессиональная деятельность которых была до этого связана с настольными компьютерами и серверами, обычно делают вывод, что мобильные устройства просто не в состоянии обеспечить тот уровень производительности, который требуется. На самом деле это почти всегда не соответствует действительности. Что необходимо сделать — так это тщательно проанализировать требования к доступу данных, предъявляемые мобильным приложением, и спроектировать такую модель данных, которая наилучшим образом соответствовала бы этим требованиям. Например, если данные в основном только считываются, то можно добиться выигрыша в эффективности, сохраняя данные в памяти с использованием нестандартного формата, оптимизированного для уменьшения суммарного объема данных и увеличения скорости проведения поиска, а не для обновления данных; в случае настольных компьютеров эта мера может привести лишь к незначительному увеличению производительности приложения, тогда как в случае мобильных устройств достигаемое при этом улучшение результатов может быть разительным.
Выбор подходящих абстракций для хранения данных в памяти
Чтобы данные, возвращенные в результате запроса к базе данных или считанные из файла, можно было просматривать и манипулировать ими, они должны храниться в памяти. Существует два основных способа работы с такими данными, находящимися в памяти:
1. Применение универсальной абстрактной модели. Для работы с данными, извлекаемыми из баз данных, во многих программных каркасах предлагаются абстрактные модели. В .NET Compact Framework такой моделью является ADO.NET, использование которой описывается далее в этой главе; другие каркасы поддерживают другие модели. Достоинством абстрактных моделей является их гибкость. Данные, извлеченные из баз данных, хранятся в обобщенных таблицах и строках объектов. В каждой строке содержатся поля, соответствующие определенным столбцам. Таблицу образует сетка, состоящая из строк и столбцов. Таблицы можно группировать в наборы, причем для описания отношений между столбцами различных таблиц применяются дополнительные таблицы. Если выполняется обобщенный запрос к базе данных и заранее не известно, какого рода данные будут получены в ответ на этот запрос, то сохранение их в подобного рода обобщенном формате является необходимостью. Современные развитые модели доступа к данным могут также отслеживать внесение локальных изменений. Впоследствии эти изменения могут быть отвергнуты, приняты или иным образом приведены в соответствие с данными, хранящимися в базе данных. Кроме того, различные программные каркасы для доступа к данным поддерживают выполнение транзакций и локальное создание гибких представлений данных. Существуют также обобщенные модели связывания данных, которые обеспечивают связывание табличных данных с элементами пользовательского интерфейса. Эти универсальные модели программирования доступа к данным обладают высокой гибкостью, устойчивы к изменению формата базы данных и обеспечивают абстракции, предназначенные для просмотра типов данных, с которыми приходится работать, во время выполнения. Подобная гибкость дается за счет введения дополнительных объектов. Эти объекты содержат метаданные (метаданные — суть информация об информации), хранят отношения между различными элементами данных и отслеживают вносимые изменения. При использовании таких высокоуровневых технологий доступа к данным, хранимым в памяти, ваше приложение фактически создает в памяти базу данных; обладая значительными возможностями, этот подход предъявляет высокие требования к вычислительным ресурсам и памяти
2. Применение пользовательской модели, приспособленной для работы с вашими данными. Противоположностью абстрактной модели для работы с данными является "подход для бедных", основанный на создании пользовательской реализации, которая содержит лишь то, что требуется для хранения и использования данных. При применении пользовательской стратегии доступа к данным ваше мобильное приложение самостоятельно распоряжается абстракциями, предлагаемыми встроенной в память базой данных обобщенных строк, столбцов, таблиц и отношений, и выбирает способ хранения данных в формате, который больше всего подходит для решаемой задачи. Обычно для этой цели применяется массив простых типов, которые содержат данные. Эта пользовательская модель во многом лишена гибкости универсального подхода и вынуждена брать на себя заботу об обновлении данных и управлении отношениями между ними. Его преимущество состоит в том, что за счет использования исключительно тех объектов, без которых нельзя обойтись, у приложения появляется возможность значительно снизить объем памяти, занимаемой информацией о состоянии. Если данные, с которыми ведется работа, можно легко представить в виде единственной таблицы, а отношения между ними не отличаются сложностью, то приспособленный для конкретных целей пользовательский формат является отличным решением.
Выбор наиболее подходящей модели определяется объемом и сложностью используемых данных. Было бы непозволительной ошибкой строить собственную модель данных, если они связаны между собой сложной системой отношений, которая нуждается в управлении и в представлениях в памяти мобильного приложения. Вместе с тем, если ваши данные состоят из нескольких простых полей в единственной таблице базы данных, а данные предназначены только для чтения, то было бы глупо останавливать свой выбор на сложной модели данных с поддержкой состояния, если простой массив данных позволяет отлично справиться с задачей. Вполне вероятно, что потребности в данных вашего приложения занимают промежуточное положение между этими двумя крайними случаями, и вам придется испытать несколько различных моделей, чтобы, в конечном счете, выбрать ту из них, которая в наибольшей степени соответствует вашим запросам. Как ранее обсуждалось, этот выбор аналогичен принятию разработчиками мобильных приложений решения о том, какую технологию следует применить при работе с XML-данными. Разработчик должен выбирать между потенциальной простотой проектирования и реализации и эффективностью выполнения приложения.
Выбор подходящей модели данных, требующих долговременного хранения
Модель долговременного хранения данных описывает, куда направляется информация после того, как приложение завершает работу. Даже мобильные устройства, которые включены постоянно и выполняют приложения на фоне, нуждаются в безопасном и структурированном хранилище долговременных данных. Типичным примером такого приложения в случае мобильных телефонов является электронная записная книжка (Personal Information Manager — PIM). Пользователь, разместивший в телефоне свою адресную книгу, рассчитывает на возможность доступа к этим данным вне зависимости
от того, в каком состоянии находится телефон. Если это только вообще возможно, для таких данных должна автоматически создаваться резервная копия на сервере или настольном компьютере, чтобы их можно было быстро восстановить в случае сбоя долговременного запоминающего устройства телефона. Выбирая модель долговременного хранения данных мобильного приложения, вы должны ответить на два основных вопроса:1. Должны ли данные храниться в файле или в базе данных? Если объем подлежащих хранению данных небольшой, то для этого, вероятно, лучше всего воспользоваться текстовым файлом. Если необходимо обеспечить максимально благоприятные условия для переноса файла с одного устройства на другое, то отличным выбором будет XML. В то же время, если ваше приложение работает с большими объемами данных, к которым требуется произвольный доступ, если необходимо обеспечить безопасность данных или если вы хотите использовать расширенные запросы, транзакции и синхронизацию данных, то наилучшим решением будет база данных. Основной недостаток использования баз данных состоит в том, что это влечет за собой дополнительные накладные расходы, а также необходимость дополнительной настройки, которая может потребоваться для развертывания приложения.
2. Точно так же как и в случае настольных приложений, можно либо обращаться непосредственно к базам данных, выполняющимся на сервере, либо хранить базы данных локально. Преимуществом баз данных, размещаемых на устройстве, является их доступность; вы можете обратиться к такой базе данных в любой момент, независимо от наличия соединения с сервером. Если необходимо получать доступ к большим объемам данных, то использование локальной базы данных может оказаться гораздо более эффективным, нежели пересылка результатов запросов на устройство через сравнительно медленное беспроводное соединение. К недостаткам локальных баз данных относятся дополнительная сложность развертывания приложения и необходимость в дополнительном объеме памяти для базы данных. Важно также знать, что различные мобильные устройства обладают различными возможностями поддержки локальных баз данных. Так, на момент написания данной книги база данных SQL СЕ поддерживалась на Pocket PC, но не поддерживалась на смартфонах. Если ваше приложение не может рассчитывать на использование базы данных на локальном устройстве, то вам, вероятнее всего, придется предусмотреть пользовательский механизм локального кэширования данных, которые являются для вас наиболее важными, к которым чаще всего производится обращение или доступ к которым стоит слишком дорого.
Для долговременного хранения информации на мобильных устройствах обычно используется одна из двух стратегий: флэш-память или файл в системном ОЗУ. Флэш-память — это память, в которой данные могут храниться в течение длительного времени, не требуя постоянного подвода питания. Конструктивно флэш-память может выполняться либо в виде съемной карты (например, Secure Digital, Compact Flash), либо в виде встроенного элемента устройства. В настоящее время флэш-память большой емкости встречается довольно часто; карты емкостью 512 Кбайт уже не являются диковинкой, причем их емкость продолжает расти. Кроме того, флэш-память потребляет меньше электроэнергии по сравнению с ОЗУ, поскольку не должна непрерывно выполнять электрическое обновление. В то же время, доступ к флэш-памяти осуществляется медленнее, чем к энергозависимой памяти; особенно это касается записи данных. Кроме того, биты информации, которые хранятся во флэш-памяти, из-за процессов старения обычно могут обновляться лишь ограниченное число раз; в типичных случаях значение этого показателя составляет несколько сотен тысяч записей, и хотя это число очень большое, оно, однако, не является бесконечным. Несмотря на то что в отношении повышения гибкости флэш-памяти достигнут существенный прогресс, она уступает в этом ОЗУ. В настоящее время флэш-память можно использовать вместо жесткого диска, но не вместо энергозависимого программного ОЗУ.
Следует отметить, что SIM-карты в мобильных телефонах для GSM-связи также имеют флэш-память, предусмотренную для хранения ограниченного объема данных. Это пространство традиционно использовалось для хранения адресной книги мобильного телефона, но в современных телефонах большая часть этих данных хранится в памяти телефона, которая обеспечивает более быстрый и гибкий доступ. SIM-карты по-прежнему оказываются полезными в качестве памяти для хранения такой специфической "секретной" информации, как криптографические сертификаты и ключи, однако, в силу доступности других разновидностей универсальной флэш-памяти, для хранения информации общего назначения они используются все реже и реже.
Флэш-память можно считать аналогичной жесткому диску, в котором отсутствуют подвижные элементы. Ключи памяти USB, которые можете вставлять в ПК, также представляют собой флэш-память. Как и для жестких дисков, для флэш-памяти обычно также предусматривается построенная поверх нее файловая система, что обеспечивает быстрый структурированный доступ к данным.
Другой распространенный способ долговременного хранения информации на устройствах предусматривает использование файловых систем на основе ОЗУ. В отличие от файловых систем, основанных на флэш-памяти, файловые системы ОЗУ используют часть доступной памяти устройства. Хранилища в ОЗУ характеризуются меньшим временем доступа как при чтении, так и при записи данных, но потребляют значительно больше электроэнергии по сравнению с флэш-памятью. Файловые системы, хранимые в ОЗУ, требуют питания даже тогда, когда устройство выключено; если извлечь батарею или она разрядится, то содержимое файловой системы будет утеряно. Это делает файловые системы в ОЗУ более уязвимыми по сравнению с флэш-системами. На многих устройствах, включая системы Windows CE/Pocket PC, файлы, как правило, сохраняются в файловых системах ОЗУ с использованием алгоритмов сжатия. Тем самым эффективно увеличивается емкость файловой системы, но увеличивается время обработки, поскольку чтение и запись потоков данных должны сопровождаться работой алгоритма сжатия. Файловые системы ОЗУ работают быстро — значительно быстрее, чем флэш-память, но все же медленнее, чем осуществляется обработка данных, хранящихся непосредственно в памяти.
Устройства могут поддерживать файловые системы одновременно и во флэш-памяти, и в ОЗУ точно так же, как настольные системы могут поддерживать несколько жестких дисков. Используемые модели долговременного хранения данных могут существенно различаться между собой даже для близких по типу мобильных устройств. Так, на Pocket PC и смартфонах используются разные модели долговременных хранилищ. По умолчанию на Pocket PC используется файловая система на основе ОЗУ; именно по этой причине на устройствах Pocket PC устанавливаются значительно более мощные батареи, чем на смартфонах. На смартфонах главным образом используются файловые системы на основе флэш-памяти. Как Pocket PC, так и смартфоны поддерживают динамическую вставку карт флэш-памяти в процессе работы; благодаря этому устройства имеют возможность доступа к музыкальным файлам, рисункам и любым другим данным, хранящимся на картах
Емкость и эффективность организации хранения файлов на устройствах различных классов является еще одной причиной того, что стратегии, в основе которых лежит принцип "пишется однажды — выполняется везде", в случае мобильных устройств редко когда приводят к удовлетворительным результатам. Насколько эффективно осуществляется обмен данными с памятью, зависит от характеристик используемой на устройстве запоминающей среды и ее емкости. Очень важно знать, какие форматы хранения данных поддерживаются целевым устройством, и тщательно анализировать, каким образом приложение использует эти возможности. Знание этих факторов позволяет оптимизировать доступ к данным, хранящимся на устройстве, и стратегию их хранения исходя из требований производительности и устойчивости работы приложения. Кроме того, ясное понимание механизмов долговременного хранения данных облегчает перенос мобильного приложения с одного устройства на другое.
Специфика .NET Compact Framework: ADO.NET
ADO.NET — мощная многоуровневая программная модель, предназначенная для работы с реляционными данными любого вида. ADO.NET доступна на настольных компьютерах и серверах как часть .NET Framework, а на устройствах — как часть .NET Compact Framework. Поддержка ADO.NET в .NET Compact Framework основана на подмножестве программной модели, предназначенной для настольных компьютеров и серверов.
Ключевым новшеством в модели данных ADO.NET для серверов, настольных компьютеров и устройств является полное отделение объекта ADO.NET DataSet от источника данных. Как только данные попали в ADO.NET DataSet, их можно сериализовать в виде XML-данных и сохранить в локальном файле или передать по сети на сервер, настольный компьютер или мобильное устройство.