Программирование мобильных устройств на платформе .NET Compact Framework
Шрифт:
Как и в случае пользовательских интерфейсов, существует два возможных способа управления данными — явный и неявный. Ранее в этой книге уже отмечалось, что во многих настольных приложениях прослеживается небрежное отношение к управлению используемой памятью. Это приводит к напрасному расходу ресурсов, отрицательные последствия которого отчасти компенсируются наличием на настольных компьютерах больших объемов доступной памяти и возможностью использования файлов подкачки большого размера. В случае же мобильных устройств результатом такого подхода является недопустимое снижение производительности, поскольку необходимое для эффективного выполнения приложения пространство памяти оказывается заполненным ненужными объектами. Поэтому в приложениях для мобильных устройств крайне желательно использовать более
В соответствии с вышеизложенным, прежде чем приступать к проектированию модели использования памяти для мобильного приложения, необходимо получить ответы на следующие вопросы:
■ Какой объем данных должен загружаться в каждый момент времени, чтобы пользователь имел возможность работать эффективно?
■ Когда и при каких условиях следует освобождать память от загруженных ранее данных?
■ Какой формат хранения данных в памяти является наиболее подходящим? При небольших объемах данных целесообразно выбирать тот формат, который более всего удобен с точки зрения программирования. С увеличением объема данных, например, при большом количестве строк, извлекаемых из базы данных, обязательным условием становится использование формата данных, оптимизированного в отношении расхода памяти и применяемых вычислительных методов. Кроме того, предусматриваемая модель должна обеспечивать сохранение в памяти недавно использованных данных и очистку памяти от всех остальных данных.
■ Существуют ли данные, которые было бы целесообразно кэшировать в памяти на все время работы? Вовсе не обязательно немедленно выгружать из памяти объекты, как только непосредственная необходимость в них исчезла, если спустя несколько мгновений приложение будет вынуждено вновь загружать их в память или заново воссоздавать. Память — это ресурс, благоразумное использование которого исключает как излишнюю расточительность, так и излишнюю скаредность. Есть ли смысл экономить на памяти, если положительный эффект от этого перекроется проигрышем во времени обработки?
Если вы имеете дело с несколькими различными типами данных или системных ресурсов, то конечный автомат может потребоваться для каждого из них. В рассмотренном выше примере обучающей словарной игры существует несколько типов данных и ресурсов, эффективное управление которыми в памяти необходимо обеспечить:
■ Состав словаря. Используемый для игры словарь может содержать тысячи и даже десятки тысяч слов, каждое из которых должно снабжаться соответствующими определениями и примерами их использования. Мы могли бы попытаться загрузить в память одновременно все эти слова, но это было крайне неэкономно. Что нам необходимо — так это создать у пользователя впечатление, будто в памяти находятся сразу все слова, а на самом деле осуществлять хорошо продуманную подкачку слов в соответствие с развитием игры. Программное обеспечение должно справиться с этой задачей за счет использования гибкого конечного автомата и набора вспомогательных алгоритмов, поддерживающих создание нужной нам иллюзии. Наши алгоритмы управления памятью должны обеспечивать загрузку фиксированного числа случайных слов в память, возможность их использования в течение некоторого времени и последующее освобождение памяти для загрузки новых слов. Кроме того, желательно, чтобы проект был масштабируемым и позволял указывать количество слов, подлежащих загрузке в память, чтобы тем самым регулировать этот параметр по мере того, как мы лучше изучим потребности пользователей и возможности целевого мобильного устройства в отношении хранения этих данных в памяти. Поскольку количество слов, которые мы собираемся одновременно удерживать в памяти вместе с относящимися к ним определениями и другой родственной информацией, может исчисляться сотнями, то имеет смысл подумать о выборе наиболее подходящего способа хранения этих данных в памяти и доступа к ним.
■ Данные панели игры. Поскольку наша игра — графическая, то каждый отображаемый на панели уровень игры должен
■ Глобально доступные кэшированные графические объекты. В нашей графической игре будет повторно выполняться множество самых обычных задач рисования. Вместо того чтобы непрерывно создавать и уничтожать часто используемые перья, кисти и растровые изображения, имеет смысл привлечь модель состояний, обеспечивающую хранение этих ресурсов в памяти на протяжении всего того времени, в течение которого они необходимы для выполнения повторяющихся задач перерисовки экрана. При переключении состояния игры в режим, в котором эти ресурсы не требуются, память может освобождаться от них.
Конечный автомат для фоновых задач
В ваших мобильных приложениях обязательно будут встречаться участки кода, которые либо долго выполняются, либо требуют сетевого доступа; в разряд "длительно выполняющихся" попадают все операции, выполнение которых может занимать более 0,5 секунды. Некоторые возможные примеры таких операций приводятся ниже:
■ Рекурсивные или итеративные вычисления, требующие просмотра многочисленных вариантов. К этой категории относятся поисковые алгоритмы, алгоритмы анализа данных, а также игры, основанные на механизме искусственного интеллекта. Поиск наиболее оптимального хода в шахматной игре может потребовать перебора многих тысяч различных допустимых вариантов шахматных ходов с использованием анализа различной глубины. Выполнение подобных операций может осуществляться в течение очень длительных промежутков времени.
■ Загрузка или сохранение больших объемов данных. Загрузка нескольких сотен порций информации из XML-файла или базы данных может занимать довольно большое время.
■ Сетевые операции. Почти все операции, выполняемые в сети, подвержены риску задержек и других проблем связи.
Операции подобного рода рекомендуется выполнять в асинхронном по отношению к потоку выполнения пользовательского интерфейса режиме. При реализации любой асинхронной операции конечный автомат, с помощью которого поток выполнения пользовательского интерфейса может связываться с фоновым потоком и получать информацию о ходе его выполнения, играет очень большую роль. Поток пользовательского интерфейса должен иметь возможность периодического опроса
состояния выполнения фоновой операции и одновременно предоставлять пользователю возможность в любой момент прекратить выполнение этой операции. В свою очередь, фоновый поток должен иметь возможность информировать поток пользовательского интерфейса о ходе своего выполнения, а также получать от него уведомления о необходимости прекратить свое выполнение в необходимых случаях. Модель выполнения потока под управлением конечного автомата обеспечивает прекрасные возможности для удовлетворения этих требований.
Ниже приводится пример, иллюстрирующий использование конечного автомата для управления фоновыми вычислениями, выполнение которых может занимать много времени. Целью этих вычислений является нахождение ближайшего простого числа (prime), превышающего заданное целое число. Соответствующий код может выполняться либо в синхронном режиме в целях отладки, либо в асинхронном режиме, позволяющем избежать блокирования пользовательского интерфейса на время проведения вычислений. На рис. 5.3 представлена схема простого конечного автомата, при помощи которого фоновый поток выполнения может предоставлять информацию о своем состоянии. Кроме того, этот конечный автомат позволяет потоку пользовательского интерфейса возможность направлять фоновому потоку запросы, требующие прекратить выполнение.