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

Автор книги: Иво Салмре

сообщить о нарушении

Текущая страница: 27 (всего у книги 69 страниц)

Рекомендации по использованию потоков в мобильных приложениях

Назначайте обслуживание пользовательского интерфейса основному потоку

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

Стремитесь поддерживать способность пользовательского интерфейса к отклику на высоком уровне

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

Начинайте с создания однопоточного приложения

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

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

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

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

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

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

Максимально упрощайте многопоточный код и документируйте его для повышения надежности

Безопасность многопоточной поддержки – штука хитрая. Если не уделить должное внимание тому, как осуществляется считывание и запись переменных-членов, то может случиться так, что ваше приложение будет пытаться прочитать в одном потоке переменную, запись которой была начата другим потоком, но еще не успела закончиться; "атомарность", то есть неделимость – выполнение за один раз от начала до конца, для большинства операций над данными, находящимися в памяти, не гарантируется, поскольку для записи большинства типов данных требуется выполнение нескольких инструкций микропроцессора. Тот факт, что возникновение проблем подобного рода зависит от временных характеристик выполнения потоков и случается редко, значительно затрудняет их обнаружение, воспроизведение и отладку. Даже ecли гарантирована атомарность доступа к переменным, но при этом было уделено недостаточное внимание тому, как осуществляются вызовы функций-членов классов, то вы можете оказаться в ситуации, когда либо портятся данные, либо программа ведет себя непредсказуемым образом, поскольку соответствующие данные параллельно изменяются алгоритмами, выполняющимися разными потоками; представьте, например два потока, которые одновременно пытаются вставлять и удалять записи в одном и том же связанном списке. Для надежной обработки таких ситуаций необходимо определить "критические разделы" кода; тем самым будет гарантироваться, что любой код, связанный с одним и тем же объектом семафора, сможет выполнять только одним потоком. (В C# это достигается за счет использования оператора lock(объект), а в Visual Basic – с использованием оператора SyncLock(объект). Для получения более подробной информации относительно двух указанных операторов обратитесь к библиотеке справочной документации MSDN.) Ситуацию могут еще более осложнять "зависания", или "взаимоблокировки", когда два потока, выполняющиеся в одно и то же время в разных критических разделах, вызывают код, который должен войти в критический раздел, "принадлежащий" в данный момент другому потоку; при вхождении в критический раздел другого потока будет приостановлено выполнение каждого потока. По этой причине, а также с учетом факторов производительности, чрезмерно вольное использование критических разделов может привести к появлению дополнительных проблем.

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

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

// К ДАННОЙ <ПЕРЕМЕННОЙ/СВОЙСТВУ/МЕТОДУ> ДОСТУП ИЗ НЕСКОЛЬКИХ ПОТОКОВ

// ОСУЩЕСТВЛЯТЬСЯ НЕ ДОЛЖЕН!!!

// Предполагается, что этот метод будет использоваться

// <высокоприоритетным/фоновым> потоком для ...

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

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

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

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

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

Заблаговременное прогнозирование потребностей пользователя

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

В качестве хорошего примера можно привести программу для просмотра изображений в Windows XP. Окно этой программы появляется сразу же после того, как вы дважды щелкнете мышью на имени файла изображения в окне проводника. В результате этого изображение загружается и отображается на экране. Одновременно с этим, но незаметно для пользователя и без какой-либо инициативы с его стороны, после вывода на экран первого изображения на фоне загружается также изображение, файл которого размещен в каталоге вслед за первым. Если следующим действием пользователя, которое можно считать наиболее вероятным, будет щелчок на кнопке Next Image (Следующее изображение) в программе для просмотра изображений, то следующая фотография незамедлительно появится на экране без видимой задержки. В случае современных крупных цифровых фотографий, загрузка, распаковка и масштабирование которых требуют значительного времени, это не такое уж и малое достижение. Описанная заблаговременная загрузка производится в основном только для изображений, которые располагаются следующими в списке файлов каталога изображений. Если вы щелкнете на кнопке Previous Image (Предыдущее изображение), то, вероятнее всего, увидите на экране сообщение "Generating preview" ("Генерируется изображение предварительного просмотра"), появляющееся на короткое время на экране при загрузке фотографии по требованию. Переходы в обратном направлении используются менее часто и поэтому не оптимизируются. Поскольку для цифровых изображений могут требоваться значительные ресурсы памяти, осуществление предварительной загрузки большого количества изображений в предвидении того, что пользователь может захотеть их просмотреть, на сегодняшний день вызывает затруднения. Аналогичным образом, то же самое сообщение "Generating preview" будет появляться на экране, если вы выполните ряд быстрых последовательных щелчков на кнопке Next Image, требующих загрузки очередных изображений; это объясняется тем, что вы требуете большего, чем позволяют возможности средств опережающего просмотра в отношении загрузки следующих фотографий. В большинстве случаев, прежде чем переходить к следующей фотографии, текущую фотографию рассматривают хотя бы в течение одной-двух секунд, и именно для такого сценария и была предусмотрена оптимизация.

Оптимизация загрузки изображений программой просмотра основывается на вполне разумных предположениях:

1. В большинстве случае порядок просмотра фотографий соответствует продвижению по списку в прямом направлении.

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

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

Пример использования фонового потока для выполнения отдельной задачи

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

Кроме того, в рассматриваемом примере основному потоку предоставляется возможность запрашивать прекращение выполнения фоновой задачи. Для уведомления потока, выполняющего фоновую задачу, о поступлении запроса на прекращение выполнения, используется вызов метода m_threadExecute.setProcessingState(ThreadExecuteTask.ProcessingState.requestAbort) из другого потока. За периодическую проверку этого состояния и осуществление возможного прекращения выполнения операции отвечает код, выполняемый фоновым потоком. Конечный автомат для класса ThreadExecuteTask представлен на рис. 9.1.

Рис. 9.1.  Конечный автомат для отдельной задачи, выполняемой фоновым потоком

Листинг 9.1. Код для управления выполнением одиночной задачи фоновым потоком

using System;

public class ThreadExecuteTask {

 //Перечисляем возможные состояния

 public enum ProcessingState {

  //–

  //Начальное состояние

  //–

  //Пока ничего интересного не происходит

  notYetStarted,

  //–

  //Рабочие состояния

  //–

  //Ожидание запуска фонового потока

  waitingToStartAsync,

  //Выполнение кода в фоновом потоке

  running,

  //Запросить отмену выполнения вычислений

  requestAbort,

  //–

  //Состояния завершения

  //–

  //Состояние завершения: выполнение фонового потока

  //успешно завершено

  done,

  //Состояние завершения: выполнение потока отменено

  //до его завершения

  aborted

 }

 ProcessingState m_processingState;

 public delegate void ExecuteMeOnAnotherThread(ThreadExecuteTask checkForAborts);

 private ExecuteMeOnAnotherThread m_CallFunction;

 private object m_useForStateMachineLock;

 public ThreadExecuteTask(ExecuteMeOnAnotherThread functionToCall) {

  //Создать объект, который мы можем использовать

  //в конечном автомате в целях блокировки

  m_useForStateMachineLock = new Object();

  //Обозначить готовность к началу выполнения

  m_processingState = ProcessingState.notYetStarted;

  //Сохранить функцию, которую необходимо вызвать

  //в новом потоке

  m_CallFunction = functionToCall;

  //–

  //Создать новый поток и вызвать в нем функцию на выполнение:

  // this.ThreadStartPoint()

  //–

  System.Threading.ThreadStart threadStart;

  threadStart = new System.Threading.ThreadStart(ThreadStartPoint);

  System.Threading.Thread newThread;

  newThread = new System.Threading.Thread(threadStart);

  //Обозначить готовность к началу выполнения (в целях определенности

  //это важно сделать еще до того, как будет запущен поток!)

  setProcessingState(ProcessingState.waitingToStartAsync);

  //Дать ОС команду начать выполнение нового потока в асинхронном режиме

  newThread.Start();

  //Возвратить управление функции, вызывающей этот поток

 }

 //–

 //Эта функция является точкой входа, вызываемой

 //для выполнения в новом потоке

 //–

 private void ThreadStartPoint() {

  //Установить состояние обработки, соответствующее

  //выполнению функции в новом потоке!

  setProcessingState(ProcessingState.running);

  //Запустить на выполнение пользовательский код и передать указатель в

  //наш класс, чтобы этот код мог периодически проверять, не поступил ли

  //запрос на прекращение выполнения

  m_CallFunction(this);

  //Если выполнение не было отменено, изменить состояние таким образом,

  //чтобы оно соответствовало успешному завершению

  if (m_processingState != ProcessingState.aborted) {

   //Обозначить завершение выполнения

   setProcessingState(ProcessingState.done);

  }

  //Выйти из потока...

 }

 //–

 //Конечный автомат

 //–

 public void setProcessingState(ProcessingState nextState) {

  //B любой момент времени только одному потоку выполнения

  //могут быть разрешены попытки изменить состояние

  lock(m_useForStateMachineLock) {

   //B случае попытки повторного вхождения в текущее состояние

   //никакие дополнительные действия не выполняются

   if (m_processingState == nextState) {

    return;

   }

   //–

   //Простейший защитный код, гарантирующий

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

   //либо успешно завершена, либо успешно отменена

   //–

   if ((m_processingState == ProcessingState.aborted) ||

       (m_processingState == ProcessingState.done)) {

    return;

   }

   //Убедиться в допустимости данного изменения состояния

   switch (nextState) {

   case ProcessingState.notYetStarted:

    throw new Exception("Переход в состояние 'notYetStarted' невозможен");

   case ProcessingState.waitingToStartAsync:

    if (m_processingState != ProcessingState.notYetStarted) {

     throw new Exception("Недопустимое изменение состояния");

    }

    break;

   case ProcessingState.running:

    if (m_processingState != ProcessingState.waitingToStartAsync) {

     throw new Exception("Недопустимое изменение состояния");

    }

    break;

   case ProcessingState.done:

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

    //Это возможно также в тех случаях, когда пользователь затребовал

    //отмену выполнения, но работа к этому моменту уже была закончена

    if ((m_processingState != ProcessingState.running) &&

       (m_processingState != ProcessingState.requestAbort)) {

     throw new Exception("Недопустимое изменение состояния");

    }

    break;

   case ProcessingState.aborted:

    if (m_processingState != ProcessingState.requestAbort) {

     throw new Exception("Недопустимое изменение состояния");

    }

    break;

   }

   //Разрешить изменение состояния

   m_processingState = nextState;

  }

 }

 public ProcessingState State {

  get {

   ProcessingState currentState;

   //Предотвратить попытки одновременного чтения/записи состояния

   lock(m_useForStateMachineLock) {

    currentState = m_processingState;

   }

   return currentState;

  }

 }

} //Конец класса

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

Листинг 9.2. Тестовая программа для выполнения работы в фоновом потоке

using System;

//–

//Тестовый код, который используется для выполнения

//фоновым потоком

//–

public class Test1 {

 public int m_loopX;

 //–

 //Функция, вызываемая фоновым потоком

 // [in] threadExecute: Класс, управляющий выполнением нашего потока.

 // Мы можем контролировать его для проверки

 // того, не следует ли прекратить вычисления

 //–

 public void ThreadEntryPoint(ThreadExecuteTask threadExecute) {

  //Это окно сообщений будет отображаться в контексте того потока,

  //в котором выполняется задача

  System.Windows.Forms.MessageBox.Show("Выполнение ТЕСТОВОГО ПОТОКА");

  //–

  //60 раз

  //–

  for (m_loopX = 0; m_loopX < 60; m_loopX++) {

   //Если затребована отмена выполнения, мы должны завершить задачу

   if (threadExecute.State == ThreadExecuteTask.ProcessingState.requestAbort) {

    threadExecute.setProcessingState(ThreadExecuteTask.ProcessingState.aborted);

    return;

   }

   //Имитировать выполнение работы: пауза 1/3 секунды

   System.Threading.Thread.Sleep(333);

  }

 }

} //Конец класса

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

Листинг 9.3. Код для запуска и тестирования приведенного выше тестового кода

//Класс, который будет управлять выполнением нового потока

private ThreadExecuteTask m_threadExecute;

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

Test1 m_testMe;

//–

//Этот код должен быть запущен ранее другого кода, поскольку

//он запускает новый поток выполнения!

//

//Создать новый поток и обеспечить его выполнение

//–

private void buttonStartAsyncExecution_Click(object sender, System.EventArgs e) {

 //Создать экземпляр класса, метод которого мы хотим вызвать

 //в другом потоке

 m_testMe = new Test1();

 //Упаковать точку входа метода класса в делегат

 ThreadExecuteTask.ExecuteMeOnAnotherThread delegateCallCode;

 delegateCallCode = new ThreadExecuteTask.ExecuteMeOnAnotherThread(m_testMe.ThreadEntryPoint);

 //Дать команду начать выполнение потока!

 m_threadExecute = new ThreadExecuteTask(delegateCallCode);

}

//Проверить состояние выполнения

private void buttonCheckStatus_Click(object sender, System.EventArgs e) {

 //Запросить у класса управления потоком, в каком состоянии он находится

 System.Windows.Forms.MessageBox.Show(m_threadExecute.State.ToString());

 //Запросить класс, метод которого выполняется в потоке,

 //о состоянии выполнения

 System.Windows.Forms.MessageBox.Show(m_testMe.m_loopX.ToString());

}

//Принудительно вызвать запрещенное изменение состояния

//(это приведет к возбуждению исключения)

private void buttonCauseException_Click(object sender, System.EventArgs e) {

 m_threadExecute.setProcessingState(ThreadExecuteTask.ProcessingState.notYetStarted);

}

//Послать асинхронному коду запрос с требованием отмены его выполнения

private void buttonAbort_Click(object sender, System.EventArgs e) {

 m_threadExecute.setProcessingState(ThreadExecuteTask.ProcessingState.requesAbort);

}