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

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

■ Используйте курсор ожидания и обеспечивайте обратную связь с пользователями для любой задачи, выполнение которой длится более одного мгновения. Если выполнение любой задачи занимает более половины секунды, следует использовать курсор ожидания. Если выполнение задачи длится более двух секунд или может занять неопределенное время, пользователь должен получать регулярно обновляемую информацию о состоянии ее выполнения. 

■ В процессе разработки и тестирования, приложения используйте реальные размеры данных и модели сетевых соединений. Важно тестировать мобильное приложение в условиях программной среды, близких к тем, с которыми будут сталкиваться конечные пользователи в процессе работы. Это касается как вероятных объемов данных, с которыми будут работать конечные пользователи, так и параметров подключения к сети (например, скорость передачи данных и длительности задержки) в реальных условиях. Если ваше приложение характеризуется определенными пороговыми значениями некоторых параметров состояния, при превышении которых приложение начинает работать значительно хуже, предусмотрите явные запреты, препятствующие переходу приложения в такие состояния; разрешая приложению переходить в состояния, в которых нормальное функционирование приложения нарушается, вы оказываете конечным пользователям "медвежью услугу". 

■ Осмотрительно выбирайте размеры применяемых вами растровых изображений. В наши дни размеры обычных цифровых изображений значительно превышают те, которые еще допустимы при выводе изображений на экраны мобильных устройств. При больших размерах изображений вы будете напрасно терять время на их пересылку по сети, место, необходимое для их хранения на устройстве, и память, занимаемую ими при загрузке. Лишние 0,5 Мбайт данных изображения, загруженных в память, эквивалентны сотням или даже тысячам других удерживаемых в памяти элементов, не являющихся изображениями; 500 Кбайт пикселей по занимаемому объему равносильны 500000 целочисленных элементов данных. При любом удобном случае прежде, чем загружать изображение, уменьшайте его размеры, сообразуясь с возможностями экрана целевого устройства. Если это сделать невозможно или в память должны загружаться изображения с высоким разрешением, подумайте, нельзя ли сразу же создать в памяти копии этих изображений с низким разрешением, после чего уничтожить их объемистый в отношении используемой памяти оригинал, чтобы за приложением не было закреплено большое количество лишней памяти. 

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

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

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

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

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

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

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

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