Читать онлайн «Программирование мобильных устройств на платформе .NET Compact Framework». Страница 13

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

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

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

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

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

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

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

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

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

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

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

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