Шаблоны разработки Индикатора выполнения?

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

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

Однако мы не реализовали его в этом проекте (по крайней мере, пока я был там), так что это всего лишь теоретическая идея: -)

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

Поскольку я не знаю технического решения вашей проблемы, я думаю, что то, что вы показываете пользователю (и сколько времени вы тратите на разработку решения), должно основываться на функциональных соображениях: кто этим пользуется? насколько точной должна быть информация? Это интерактивный процесс, во время которого они не могут выполнять другую работу, или они могут позволить ему работать в фоновом режиме и вернуться к нему? Является ли рабочий процесс, во время которого выполняется ваша длительная функция, зависимым от времени или критически важным?

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

Очень интересный подход - это восприятие пользователя.

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

Обратите внимание, что предпочтительная формула отображения - (x + (1-x) / 2 )⁸, где x - фактический прогресс по шкале от 0 до 1 :)

Поэтому я бы предложил:

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

Я знаю, это не точно, но если пользователи считают, что это быстрее, я соглашусь с этим!

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

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

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

Что-то вроде этого ...

class IAggregateProgressMonitor : public IProgressMonitor
{
   void setChildValue(IProgressMonitor *, int v);
   void setChildEstimatedTime(IProgressMonitor *, int v);
}

class AggregateProgressMonitor : public IAggregateProgressMonitor 
{
   void setChildValue(IProgressMonitor * child, int v)
   {
      int aggregateValue = mapChildValueToAggregateValue(child, v);
      setValue(aggregateValue);
   }

   void setChildEstimatedTime(IProgressMonitor * child, ulong ms)
   {
      children[child]->estimatedTime = ms;
      updateChildProgressRatios();
   }
}

class SubProgressMonitor : public IProgressMonitor
{
  SubProgressMonitor(IAggregateProgressMonitor *parent, int parentFrom, 
                     int parentLength) ... ;
  void setValue(int v)
  {
     parent->setChildValue(this, v);
  }

  void setEstimatedRunningTime(ulong ms)
  {
    parent->setChildEstimatedTime(this, ms);
  } 
};

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

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

После завершения вы можете расширить AggregateProgressMonitor (переопределив методы IProgressMonitor), чтобы отображать прогресс пользователю.