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

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

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

Производительность и многопоточное выполнение

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

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

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

Производительность и уровни абстракции API-интерфейсов