Чтение онлайн

На рис 12.4 представлен наиболее оптимальный вариант расходования памяти.

Рис. 12.2. Промежуточный случай: эффективно организованное состояние приложения, неэкономичные алгоритмы

Рис. 12.3. Промежуточный случай: чрезмерное потребление памяти состоянием приложения, экономичные алгоритмы

Рис. 12.4. Наиболее оптимальный случай: эффективное состояние приложения, и экономичные алгоритмы

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

Создавая свои мобильные приложения, вы должны стремиться к реализации модели использования памяти, которую отражает рис. 12.4. Приложение должно поддерживать информацию о состоянии, обеспечивающую все то, что требуется пользовательским данным, но реализовываться это должно по возможности наиболее эффективным способом. Кроме того, приложение должно сохранять в памяти те ресурсы, которые обычно требуется создавать и уничтожать в процессе устойчивого выполнения вашего приложения.

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

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

В то же время для использования фоновых потоков в приложениях существуют веские причины. Наиболее привлекательной областью применения потоков является сохранение способности вашего мобильного приложения к интерактивному взаимодействию с пользователем в тех случаях, когда выполнение задачи занимает длительное время или же о длительности ее выполнения заранее ничего сказать невозможно. Длительное выполнение характерно для тех задач, которые связаны с интенсивными вычислениями или интенсивной алгоритмической обработкой. Задачи, время выполнения которых является неопределенным, требуют доступа к ресурсам, которыми вы непосредственно управлять не можете. (Так, спрогнозировать длительность задержек в случае доступа к информации через сеть практически невозможно.) Для такого рода операций отличные возможности предоставляет работа в асинхронном режиме.

Суть простейшей и наиболее эффективной модели многопоточного выполнения состоит в том, чтобы иметь один основной поток, взаимодействующий с пользователем, и ряд фоновых потоков, предназначенных для выполнения асинхронных задач. Основной высокоприоритетный поток может производить периодический опрос с целью выяснения того, не завершилось ли выполнение фоновых задач или не поступила ли промежуточная информация о состоянии выполнения той или иной задачи, которую следует довести до ведома пользователя. Такие потоки фоновой обработки могут либо создаваться по требованию, либо существовать в виде пула потоков, ожидающих появления работы, которую необходимо выполнить. Создание потоков по требованию концептуально проще создания диспетчера пула потоков. Если готовой инфраструктуры, которая позволяла бы управлять фоновым выполнением, не существует, то в случае мобильных приложений я порекомендовал бы создавать для этой цели потоки по требованию. В состав каркасов приложений могут входить встроенные средства, позволяющие выполнять задачи в асинхронном режиме, и эту возможность необходимо всегда проверять, прежде чем браться за создание собственной модели многопоточного выполнения; какой смысл заново изобретать колесо, если оно давным-давно существует.

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

Весьма показательным примером может служить работа с XML. Теоретически, разработчик может добиться абсолютного максимума производительности, выполняя синтаксический анализ необходимых данных путем непосредственного использования файловых потоков ввода-вывода. Однако такой подход будет крайне неразумным, чреватым ошибками и ничем не оправданным, если существуют хорошо спроектированные и проверенные высокоуровневые API-интерфейсы, которые позволяют выполнить данную задачу без заметного ущерба для производительности.

Идеальнее всего, если разработчику для загрузки и сохранения своих данных в виде XML-дерева удается использовать объектную модель документов (Document Object Model — DOM). Эта модель прекрасно подходит для работы с XML-данными среднего объема. Однако разработчики не должны забывать о том, что XML DOM в значительной мере основана на использовании состояний; при загрузке XML-данных в память они в действительности сохраняются в памяти в виде дерева объектов, представляющих XML-документ. В случае крупных документов создание такого дерева может приводить к дефициту памяти. В противоположность этому сама модель XML DOM строится поверх классов XMLReader и XMLWriter, которые не имеют состояния и осуществляют лишь однонаправленный доступ к данным; эти классы осуществляют синтаксический анализ или генерируют XML-данные, основываясь на состоянии лишь в самой минимальной степени. Эти классы удерживают в памяти ровно столько информации, сколько необходимо для того, чтобы иметь возможность осуществлять разбор XML-данных или записывать их в поток; они и не генерируют, и не используют хранящиеся в памяти деревья данных.

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