Программирование мобильных устройств на платформе .NET Compact Framework - Иво Салмре

 System.Threading.Thread.Sleep(1200);

 //Известить пользователя текстовым сообщением о завершении работы

 //(текст обновляется всякий раз, когда ПИ выполняет обычное

 //обновление экрана)

 label1.Text = "Работа успешно завершена!";

 //Избавиться от курсора ожидания

 System.Windows.Forms.Cursor.Current = System.Windows.Forms.Cursors.Default;

}

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

Максимальная продолжительность отображения курсора ожидания

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

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

Максимальная продолжительность загрузки/сохранения данных, а также запуска/закрытия приложения

Задачи, для выполнения которых требуется длительное время, часто можно вытолкнуть в фоновый поток, так что пользователь даже не будет замечать, что задача выполняется долго. Если задача выполняется фоновым потоком, то говорят, что она выполняется в "асинхронном режиме". Однако в некоторых ситуациях для того, чтoбы приложение могло продолжить работу, требуется предварительно выполнить некоторые операции. К числу типичных ситуаций такого рода относятся следующие: 

■ Загрузка документов. Если приложение предназначено для работы с документами, то для того, чтобы оно могло продолжить работу, может потребоваться загрузка документа. 

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

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

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

Накладные расходы по обработке исключений

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

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

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

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

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

В листинге 7.4 представлен пример приложения, в котором сравниваются два алгоритма, решающие одну и ту же задачу, но значительно различающиеся между собой показателями производительности. Один алгоритм осуществляет сложение двух чисел и возвращает их сумму, а также булевское значение, которое указывает на знак результата — положительный или отрицательный. Другой алгоритм также складывает два числа и возвращает результат, но если результат является отрицательным числом, возбуждается исключение. Как и следовало ожидать, алгоритм, в котором в процессе нормального выполнения приложения используется возбуждение исключений, по своей производительности разительно отличается в худшую сторону от алгоритма, в котором исключения не используются. Хотя в абсолютном смысле оба алгоритма paботают довольно быстро и выполняют 10000 итераций менее чем за 2,5 секунды, один из них работает более чем в 350 раз быстрее по сравнению с другим; в случае вычислений, в которых интенсивно используются циклы, это различие может иметь критическое значение.

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