По большей части это правда, что исходный алгоритм знает, что ему нужно делать загодя. Однако фиксация времени, необходимого для выполнения каждого шага, - очень сложная, если не практически невозможная задача.
Все задачи не созданы равными
Самый простой способ реализовать индикатор выполнения - использовать графическое представление счетчика задач. Где процент завершен, просто вычисляется как Завершенные задачи / общее количество задач, Хотя это имеет логический смысл при первой мысли, важно помнить, что (очевидно) некоторые задачи занимают больше времени.
Рассмотрим следующие задачи, выполняемые установщиком:
- Создание структуры папок.
- Декомпрессируйте и скопируйте файлы объемом 1 ГБ.
- Создайте записи реестра.
- Создайте записи в меню «Пуск».
В этом примере шаги 1, 3 и 4 будут выполняться очень быстро, в то время как шаг 2 займет некоторое время. Таким образом, индикатор выполнения, работающий над простым подсчетом, очень быстро переместится на 25%, немного остановится, пока работает шаг 2, а затем сразу начнет прыгать на 100%.
Этот тип реализации на самом деле довольно распространен среди индикаторов выполнения, поскольку, как указано выше, его легко реализовать. Однако, как вы можете видеть, это подвержено непропорциональным задачам, искажающим фактический процент прогресса, поскольку это касается оставшегося времени.
Чтобы обойти это, некоторые индикаторы выполнения могут использовать реализации, где этапы взвешиваются. Рассмотрим приведенные выше шаги, на которые каждому шагу присваивается относительный вес:
- Создание структуры папок. [Вес = 1]
- Декомпрессируйте и скопируйте файлы объемом 1 ГБ. [Вес = 7]
- Создайте записи реестра. [Вес = 1]
- Создайте записи в меню «Пуск». [Вес = 1]
Используя этот метод, индикатор выполнения перемещается с шагом 10% (при общем весе 10), при этом шаги 1, 3 и 4 перемещают планку на 10% после завершения, а шаг 2 перемещает ее на 70%. Хотя это, конечно, не идеально, методы, подобные этому, - это простой способ добавить немного большую точность в процентный показатель прогресса.
Прошедшие результаты не гарантируют будущую производительность
Однако, когда ваш счет достигает 25, я начинаю бросать на вас теннисные мячи. Вероятно, это нарушит ваш ритм, когда ваша концентрация переместится от строго подсчета чисел до уклонения шаров, брошенных вам в путь. Предполагая, что вы можете продолжать подсчет, ваш темп, конечно, немного замедлился. Итак, теперь индикатор прогресса все еще движется, но гораздо медленнее, когда расчетное время остается либо в состоянии покоя, либо на самом деле поднимается выше.
Для более практического примера этого рассмотрим загрузку файла. В настоящее время вы загружаете файл размером 100 МБ со скоростью 1 Мбайт / с. Это очень просто определить приблизительное время завершения. Но 75% от того, что происходит, некоторые перегрузки сети и скорость загрузки снижаются до 500 КБ / с.
В зависимости от того, как браузер вычисляет оставшееся время, ваш ETA может мгновенно перейти от 25 секунд до 50 секунд (используя только существующее состояние: Размер Оставшаяся / Скорость загрузки) или, скорее всего, браузер использует скользящий средний алгоритм, который будет корректировать колебания скорости передачи без отображения резких скачков для пользователя.
Пример алгоритма качения в отношении загрузки файла может работать примерно так:
- Скорость передачи за предыдущие 60 секунд запоминается с самым новым значением, заменяющим самое старое (например, значение 61st заменяет первое).
- Эффективная скорость передачи для целей расчета - это среднее значение этих измерений.
- Оставшееся время рассчитывается как: Размер оставшейся / эффективной скорости загрузки
Таким образом, используя наш сценарий выше (для простоты мы будем использовать 1 МБ = 1000 КБ):
- Через 75 секунд в загрузку наши 60 запоминаемых значений будут составлять 1000 КБ. Эффективная скорость передачи составляет 1000 КБ (60 000 КБ / 60), что дает время, оставшееся 25 секунд (25 000 КБ / 1000 КБ).
- В течение 76 секунд (когда скорость передачи данных падает до 500 КБ), эффективная скорость загрузки составляет ~ 992 КБ (59 500 КБ / 60), что дает время, оставшееся до 24,7 секунд (24 500 КБ / 992 КБ).
- На 77 секунд: Эффективная скорость = ~ 983 КБ (59 000 КБ / 60), что дает время, оставшееся до 24,4 секунды (24 000 КБ / 983 КБ).
- В 78 секунд: Эффективная скорость = 975 КБ (58 500 КБ / 60), что дает время, оставшееся до 24,1 секунды (23 500 КБ / 975 КБ).
Вы можете увидеть шаблон, возникающий здесь, когда скорость погружения медленно включается в среднее значение, которое используется для оценки оставшегося времени. Согласно этому методу, если провал длится всего 10 секунд, а затем возвращается к 1 Мбайт / с, пользователь вряд ли заметит разницу (за исключением очень незначительного останова в расчетном времени отсчета времени).
Получение латуни - это просто методология для передачи информации конечному пользователю для фактической основной причины …
Вы не можете точно определить то, что является недетерминированным
В конечном счете, погрешность индикатора прогресса сводится к тому, что он пытается определить время для чего-то недетерминированного. Поскольку компьютеры обрабатывают задачи как по требованию, так и в фоновом режиме, практически невозможно узнать, какие системные ресурсы будут доступны в любой момент в будущем, и это доступность системных ресурсов, необходимых для завершения любой задачи.
Используя другой пример, предположим, что вы запускаете обновление программы на сервере, который выполняет довольно интенсивное обновление базы данных. Во время этого процесса обновления пользователь затем отправляет требуемый запрос другой базе данных, работающей в этой системе. Теперь серверные ресурсы, особенно для базы данных, должны обрабатывать запросы как для вашего обновления, так и для инициированного пользователем запроса - сценария, который, безусловно, будет взаимно вредным для времени выполнения. В качестве альтернативы, пользователь может инициировать большой запрос на передачу файлов, который будет облагать суммой пропускной способности хранилища, которая также будет снижать производительность. Или может начаться запланированное задание, которое выполняет процесс интенсивной работы с памятью. Вы поняли эту идею.
Как, пожалуй, более реалистичный пример для обычного пользователя - рассмотрим запуск Windows Update или проверку на вирусы. Обе эти операции выполняют интенсивные работы в фоновом режиме. В результате каждый прогресс зависит от того, что пользователь делает в то время. Если вы читаете электронную почту во время ее запуска, скорее всего, спрос на системные ресурсы будет низким, а индикатор выполнения будет постоянно двигаться. С другой стороны, если вы занимаетесь графикой, то ваш спрос на системные ресурсы будет намного больше, что приведет к тому, что движение индикатора прогресса будет шизофреническим.
В общем, просто нет хрустального шара. Даже сама система не знает, какой нагрузкой она будет находиться в любой момент в будущем.
В конечном счете, это действительно не имеет значения
Цель индикатора прогресса состоит в том, чтобы показать, что прогресс действительно выполняется, и соответствующий процесс не вешается. Хорошо, когда индикатор прогресса является точным, но, как правило, это незначительная досада, когда это не так. По большей части разработчики не собираются уделять много времени и сил алгоритмам алгоритма выполнения, потому что, честно говоря, есть гораздо более важные задачи, на которые нужно потратить время.
Конечно, вы имеете полное право быть раздраженным, когда индикатор выполнения прыгает до 99% в полном объеме, а затем заставляет вас ждать 5 минут для оставшегося процента. Но если соответствующая программа работает хорошо в целом, просто напомните себе, что разработчик имеет свои приоритеты прямо.
