В случае мобильных устройств крупными пулами памяти и файлами подкачки жертвуют ради уменьшения их размеров и снижения энергопотребления. Приложение, выполняющееся на мобильном устройстве, обитает уже не в роскошном особняке, а просто в хорошей городской квартире. Вместо спортивного автомобиля, используемого приложениями настольных компьютеров для быстрого объезда окрестностей, теперь имеется только мотоцикл. Считать, что ваше мобильное приложение "обитает" в условиях намного более ограниченного пространства — неплохая аналогия, которую полезно постоянно держать в голове в процессе проектирования моделей данных и памяти.
Рис. 4.3. Проектирование моделей данных и памяти, ориентированное на достижение высокой производительности
Те, кто программирует приложения для настольных компьютеров, исключая приложения, требующие огромных ресурсов памяти (например, сложные программы рисования часто обрабатывают числовые матрицы очень больших размерностей), в своем большинстве обычно даже не задумываются о том, какую модель памяти лучше использовать. Поэтому систематическое и заблаговременное освобождение памяти от хранящихся в ней ресурсов, необходимость в которых отпала, как правило, не производится. Любые необходимые данные сразу же загружаются в память без предварительной ее очистки от ненужных данных. Непрерывная загрузка данных и ресурсов в память продолжается либо из-за беспечности программиста, либо исходя из того, что они еще могут понадобиться пользователю. Если уж приложение позаботилось о загрузке некоторых данных или изображений из сетевого ресурса, то почему бы не подержать их в памяти подольше, чтобы сразу же предоставить их пользователю, если ему захочется вновь обратиться к этому же ресурсу? В случае приложений, предназначенных для настольных компьютеров, такой подход является в значительной степени оправданным; находящиеся в памяти неиспользуемые данные, в конечном счете, сбрасываются на жесткий диск, а вызов необходимой нужной страницы данных в память выполняется гораздо быстрее, чем повторное подключение к сети и посылка запроса. В распоряжении у приложения имеется целый дом, и неиспользуемые вещи можно просто-напросто разместить где-то на чердаке.
Как нами ранее уже обсуждалось, в случае мобильных устройств наблюдается совершенно иная ситуация. Учитывая ограниченность объема доступной памяти и отсутствие вспомогательных накопителей, которые можно было бы использовать для временного хранения страниц памяти, разработчики обязаны использовать память и ресурсы весьма расчетливо. Разработчик мобильного приложения обязан целенаправленно выбрать модель данных, в соответствии с которой будет осуществляться управление хранением данных в памяти и сборкой мусора. В случае устройств правильная стратегия часто заключается в освобождении памяти от данных или явном их перемещении на карту флэш памяти и повторном вызове данных в память, когда они вновь потребуются.
Удачная модель данных означает высокую производительность и гибкость дизайна(неудачная модель — заведомо низкую производительность)
Если согласиться с тем, что существует искусство создания замечательных приложений, то важнейшей его составляющей является умение выбирать наиболее подходящие модели данных. Рациональное управление памятью и ресурсами подразумевает следующее: 1) приобретение навыков экономного расходования памяти и хранения в ней только тех объектов, в которых действительно существует острая необходимость и которые будут немедленно использоваться, 2) использование кэширования важных данных на устройстве, но вне активной памяти и 3) перемещение остальных данных на накопитель, находящийся за пределами устройства. Научившись этим трем вещам, вы пройдете значительную часть дистанции, отделяющей вас от создания великолепно функционирующих приложений, работа с которыми будет доставлять удовольствие пользователям.
Шаг 4: выберите подходящую модель коммуникации и модель ввода-вывода
Выбор коммуникационной модели, а также модели ввода-вывода определяет, каким образом ваше приложение будет связываться с ресурсами, хранящимися вне текущего процесса. В качестве таковых могут выступать либо локальные ресурсы устройства, например, хранящиеся на нем файлы и базы данных, либо ресурсы, являющиеся внешними по отношению к физическому устройству, например такие, доступ к которым осуществляется посредством связи через сокеты, или же такие, как файлы на серверах, Web-службы и удаленные базы данных. Выбор способов, используемых приложением для связи как с локальными, так и с удаленными ресурсами оказывает большое влияние на восприятие приложения пользователями, и поэтому занимает одно из ведущих мест в списке всего того, что должно быть включено в вашу методологию разработки.
Работа с локальными ресурсами устройстваПочти все приложения, способные предоставлять пользователю информацию, хранящуюся в течение длительного времени, обеспечивают эту возможность путем локального сохранения и извлечения информации на устройстве.
Рис. 4.4. Проектирование коммуникационной модели, ориентированное на достижение высокой производительности
Наиболее важными факторами, оказывающими влияние на работу с локальными данными устройства, являются формат данных и уровень абстракции программной модели, используемой для работы с этими данными.
Формат данных
Вообще говоря, формат, в котором хранятся данные, выбирается на основе компромисса между требованиями эффективности и удобства использования. Любые конкретные данные могут храниться в виде двоичных файлов, простых текстовых файлов, текстовых XML-файлов или в виде структурированных таблиц локальных баз данных. Требования эффективности означают минимизацию размера данных и обеспечение максимально возможной производительности приложения. К числу требований удобства использования относятся максимально возможное повышение производительности труда разработчика, улучшение условий сопровождения кода, минимизация объема необходимого тестирования, обеспечение возможности обмена данными между приложениями и гибкость формата, обеспечивающая возможность его последующего расширения.
Двоичные форматы хранения данных предлагают самые широкие возможности как в отношении снижения размера данных, так и в отношении повышения производительности приложения. По этой причине данные, характеризующиеся большой плотностью информации, например, изображения, чаще всего сохраняются в двоичных форматах. Потребности в сохранении данных изображения настолько специфичны, что для этого имеется целый ряд популярных форматов, каждый из которых предлагает свой вариант достижения компромисса между размером данных, производительностью и точностью передачи изображения. Каждый из двоичных форматов изображения отвечает определенным запросам. Двоичный формат может использоваться для хранения не только изображений, но и данных произвольной природы. Однако работать с двоичными данными труднее; если вы создаете собственные двоичные форматы, то у вас появятся заботы, связанные с необходимостью учета различий в версиях данных и обеспечением возможности использования этих данных другими приложениями.
Хранение данных в текстовых форматах значительно облегчает их использование и расширяет возможности их переноса в другие приложения, так как декодировать их легче. Однако размеры текстовых файлов больше по сравнению с их двоичными аналогами. Размеры XML-файлов оказываются еще большими, чем размеры обычных текстовых файлов, поскольку текстовые данные в них дополняются информацией о схеме данных. Эти дополнительные метаданные схемы значительно повышают гибкость данных в отношении учета их версий и переносимости в другие приложения, но требуют использования дополнительного пространства. Кроме того, при чтении и записи XML файлов их необходимо дополнительно пропускать через синтаксические анализаторы, что усложняет их обработку по сравнению с обычными текстовыми файлами, в которых для разделения данных используются запятые или символы табуляции. Отмеченная гибкость достается за счет дополнительных накладных расходов. Эти дополнительные расходы можно снизить, используя разумные стратегии реализации, но полностью избавиться от них невозможно.
Базы данных предлагают наивысшую степень организации данных, однако привносят с собой дополнительные накладные расходы, связанные с выполнением процессора базы данных.
Различные уровни абстракции программной модели
Обычно программные модели, предназначенные для работы с сохраненными данными, имеют несколько уровней. Так, для работы с файлами в .NET Compact Framework предлагаются следующие уровни абстракции, перечисленные в порядке их повышения:
