Алан Цайчик (Alan Zeichick)

Я не мобильный пользователь. Мой основной компьютер – двухпроцессорная настольная система с большим 23-дюймовым монитором. У меня есть портативный ПК, но обычно я пользуюсь им раз в месяц, когда еду по делам на восточное побережье. Мой сотовый не поддерживает Java* или BREW*, у меня нет Blackberry* или пейджера, а КПК пылится в шкафу. Я не агент по продажам, не агент по услугам и вообще не агент.

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

Пока я писал о принципах разработки приложений для мобильных устройств (см. "Как мобильность влияет на разработку приложений " и "Четыре проблемы разработчиков ПО для мобильных устройств"), они в большей степени не подходили мне в отношении тех приложений, которые я использую каждый день.

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

Например, возьмем электронную почту. Я использую почтовый клиент Eudora* 6.1 для Windows* компании Qualcomm. Обычно он работает у меня на настольном ПК или на подключенном к локальной сети ноутбуке, когда я нахожусь в офисе в Нью-Йорке. Но иногда я пользуюсь им по WiFi в кофейне, в номере отеля или самолете с выключенными сетевыми интерфейсами. (Международные перелеты идеально подходят для разбора почтового ящика и подготовки писем старым друзьям.) А иногда кабельный модем у меня в офисе отключается.

Похоже, у Eudora есть несколько специальных функций для мобильных пользователей, но они не разрекламированы должным образом. (Подобные возможности есть и у других почтовых программ.) Например, все исходящие сообщения ставятся в очередь. Приложение автоматически подстраивается под состояние соединения: если подключение к сети установлено, то Eudora отправит письма, а если нет, то они сохраняются в папке "исходящие". То есть, я могу писать и отравлять сообщения на высоте 10 километров точно также, как я делаю это в офисе.

У Eudorа есть другие функции, которые пригодятся как мобильным, так и обычным пользователям. Можно настроить проверку почты только при работе от сети, а не от батарей, чтобы продлить время автономной работы (я эту опцию не использую). Еще можно загружать только заголовки сообщений, размер которых превышает заданный пользователем лимит, чтобы не загружать многомегабайтное приложение к письму при модемном соединении на 28,8 Кбит/с (эту возможность я использую в отелях без высокоскоростного подключения, но только в этом случае).

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

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

Итак, Eudora получает приз за волю к победе. Многие приложения хуже справляются с подобными задачами. Например, Windows Update пытается загружать обновления независимо от скорости соединения. Я настроил Windows Update на автоматическую загрузку обновлений, но установку только с моего согласия. Но меня очень раздражает, когда при подключении по коммутируемой линии в номере отеля (в моей любимой гостинице в Нью-Йорке еще нет широкополосного доступа в интернет) начинает загружаться заплатка для системы безопасности или новый драйвер видеокарты. Ведь с этим можно подождать до завтра, когда я буду в офисе! Тоже самое касается и программы Acrobat*, которая проверяет наличие обновлений при запуске. Не сейчас! Позже! Иногда лишний килобайт в секунду приходится очень кстати.

Почему же приложения не учитывают скорости соединения? Почему они не создают очередей сетевых операций, как это делает Eudora для исходящей почты?

Другими словами, почему они не учитывают особенностей работы на мобильных устройствах?

Еще один пример приложения, которое можно было бы адаптировать для мобильных сред, но этого не происходит. Я управляю несколькими интернет-сайтами с помощью различных утилит, над частью из них я работаю в Microsoft FrontPage* 2002. Когда в дороге я заканчиваю разбираться с почтой, то переключаюсь на интернет-сайты: подчищаю содержимое, изменяю страницы. Один из сайтов посвящен моей семье, и в поездках я добавляю туда новые фотографии.

Но, конечно, я не могу опубликовать эти изменения ни на высоте 10 километров, ни на скорости 28.8 Кбит/с в отеле. Поэтому в списке задач я пишу: "Опубликовать такие-то в офисе". Для этого нужно будет запустить FrontPage, загрузить сайт и нажать кнопку "опубликовать". Почему я не могу нажать кнопку публикации в самолете, чтобы FrontPage поставил операцию в очередь и автоматически выполнил обновление при наличии высокоскоростного подключения (желательно после доставки почты)? К сожалению, такая функция не предусмотрена.

Уверен, что люди, которые готовят материалы для блогов и новостных лент, оценили бы идею создания очереди сетевых операций.

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

Есть множество примеров сетевых приложений, которые могут работать автономно и при наличии соединения. И снова Eudora может послужить хорошим примером: Когда я отключен, я все равно могу читать уже загруженные письма, а также писать новые. Эта часть приложения полностью игнорирует сетевую составляющую. Единственная часть, зависящая от сети – связь с серверами POP3 (IMAP4) и SMTP.

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

Например, хотите ли вы предварительно загружать из сети часто используемые данные? Даже для пользователей с подключением по локальной сети предварительная загрузка увеличивает скорость работы, поскольку чтение с локального диска происходит быстрее, чем по сети или с интернет-сервера. То же самое относится к выгрузке новых данных. Можно ли поставить эту операцию в очередь, а затем запустить отдельным процессом? Хороший пример – отправка на печать: есть локальная очередь печати Windows. Когда я прихожу домой и подключаюсь к локальной сети, моему принтеру приходится нелегко. Именно так и должно быть. Вы можете использовать этот принцип?

Еще один момент работы в онлайн и автономно – автоматически подключаться после отключения. Например, AOL Instant Messenger* иногда успешно подключается после разрыва соединения, но иногда нет, и мне приходится подключать его вручную. (Не знаю как у вас, но мой AIM-сервер пропадает и появляется несколько раз в день.)

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

Да что там, я замечал это даже с моим кабельным модемом. Например, когда все соседи приходят вечером домой, скорость падает почти до черепашьей. Хорошо, если бы моя система адаптировалась по такие условия. Например, я часто слушаю потоковые аудио-каналы. Нельзя ли изменять качество звука при изменении скорости соединения?

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

Локально хранящиеся данные жизненно необходимы для автономной работы. Например, Eudora должна где-то хранить исходящие сообщения. Windows Update нужно место для размещения загруженных обновлений и исправлений.

Если вы возьмете за правило создание хранилища локальных данных для сетевых операций, вы получите множество преимуществ. Конечно, программируя работу приложений с локальным хранилищем, а не с сетью, можно легко перейти к работе в автономном режиме. Вы легко можете создать логическую схему, которая связывает это хранилище с сетью с учетом качества и надежности подключения, качества обслуживания (т.е. колебаний и задержек). Локальные хранилища могут быть предельно простыми. Например, это может быть просто файл с исходящими SMTP-сообщениями. С другой стороны, это может быть сложная база данных, которая наполняется на основе правил, заранее выбирающих данные, которые могут понадобиться пользователю. Все, что вы можете сделать для улучшения отзывчивости приложения, необходимо делать, будь то приложение для ноутбука или двухпроцессорной рабочей станции на базе процессоры Intel® Xeon™. Локальное хранилище данных всегда поможет уменьшить время отклика системы.

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

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

Например, у моего компьютера гигабайт оперативной памяти. Но многие приложения не знают о ее существовании. Возьмем проигрывание музыкальных CD или фильмов на DVD, что я делаю довольно часто (еще бы, с 23-дюймовой панелью!). Проигрыватель постоянно поддерживает вращение диска в приводе. На это расходуется масса энергии и расходуется довольно неэффективно. Почему бы не организовать кэш в памяти? Ведь ее много, особенно когда я смотрю кино. Остановка диска сбережет электроэнергию (а на ноутбуке — продлит время работы от батареи). Можно даже кэшировать некоторое содержимое на жестком диске, который всегда вращается, чтобы можно было остановить CD.

В моем ноутбуке установлен процессор Intel® Pentium® M и набор микросхем Intel® 855, которые отличаются расширенными возможностями управления электропитанием. Но используют ли их мои приложения? Управляют ли они энергопотреблением? Насколько я знаю, нет. Но, учитывая, что заряд батареи кончается в середине перелета Нью-Йорк – Сан-Франциско, я бы хотел, чтобы было по-другому.

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

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

Многопоточные приложения также могут использовать преимущества многопроцессорной обработки. Многопроцессорная обработка на стороне клиента? Да, и причем все в большей степени. Технология Intel® Hyper-Threading (HT) используется во многих современных ПК и ноутбуках, так что со временем можно ожидать ее широкого распространения. А двухъядерные процессоры уже стучатся в наши двери. Таким образом, использование процессов и потоков – отличная идея даже для мобильных клиентов и просто замечательная для настольных приложений.

Я не агент по продажам и не пытаюсь перенести приложения с настольного ПК на КПК.

Но, с точки зрения разработчика приложений, я – мобильный пользователь даже во время работы на моем настольном суперкомпьютере.

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

Элан Цайчик, в прошлом разработчик ПО для базовых ЭВМ, работает главным аналитиков в компании "Кэмден Эсоушиэтс" – независимой технологической исследовательской фирме, занимающейся разработками в области сетей, систем хранения и программного обеспечения.

• Процессор Intel Pentium M
  
  
• Процессор Intel Xeon
  
  
• ПО для мобильных устройств