На пръв поглед изглежда, че генерирането на точна оценка на времето трябва да бъде сравнително лесно. В края на краищата алгоритъмът, който създава лентата за напредъка, знае всички задачи, които трябва да направи преди време ... нали?
В по-голямата си част е вярно, че алгоритъмът на източника знае какво трябва да направи преди време. Обаче определянето на времето, което ще бъде необходимо за извършване на всяка стъпка, е много трудна, ако не и невъзможна задача.
Най-лесният начин за внедряване на лентата за прогрес е да се използва графично представяне на брояча на задачите. Където процента е пълен се изчислява като Завършени задачи / Общ брой задачи, Докато това прави логически смисъл на първото мислене, важно е да се помни, че (очевидно) някои задачи отнемат повече време.
Помислете за следните задачи, изпълнявани от монтажник:
В този пример стъпки 1, 3 и 4 ще завършат много бързо, докато стъпка 2 ще отнеме известно време. Така че прогресивната лента, която работи на обикновен брой, ще скочи до 25% много бързо, ще спре малко, докато стъпка 2 работи и след това ще скочи до 100% почти веднага.
Този тип внедряване всъщност е доста често срещано сред баровете за напредък, тъй като, както беше посочено по-горе, е лесно да се приложи. Както виждате, обаче, той е обект на непропорционални задачи, които затрудняват действителен процент прогрес, тъй като се отнася до оставащото време.
За да обработите това, някои ленти за напредък могат да използват реализации, където стъпките са претеглени. Обсъдете стъпките по-горе, където е определена относителна тежест за всяка стъпка:
Използвайки този метод, прогресивната лента ще се движи с нарастване от 10% (като общото тегло е 10), като стъпките 1, 3 и 4 преместват лентата 10% при завършване, а стъпка 2 я движат 70%. Макар че със сигурност не е перфектен, методите като този са лесен начин да добавите малко повече точност към процента на прогреса.
Помислете за един прост пример за мен, който ви моли да преброите до 50, докато използвам хронометър, за да ви време. Да предположим, че броите до 25 на 10 секунди. Би било разумно да предположим, че останалите числа ще се броят за още 10 секунди, така че проследяващ прозорец, който проследява това, ще покаже 50% пълна с 10 секунди.
След като броят ви достигне 25, обаче, започвам да хвърлям топки за тенис. Вероятно това ще наруши вашия ритъм, тъй като концентрацията ви се е преместила от строго преброяване на числа до избягване на топки, изхвърлени от пътя. Ако приемем, че сте в състояние да продължите да броите, скоростта ви със сигурност е намаляла малко. Така че сега лентата за напредъка все още се движи, но много по-бавно, като очакваното време остава или в застой или всъщност се катери по-високо.
За по-практичен пример за това, помислете за изтегляне на файл. Понастоящем изтегляте 100 MB файл със скорост от 1 MB / s. Това е много лесно да се определи очакваното време за завършване. Но 75% от пътя, някои посещения при претоварване на мрежата и скоростта на изтегляне спадат до 500 KB / s.
В зависимост от начина, по който браузърът изчислява оставащото време, вашата ETA може незабавно да премине от 25 секунди до 50 секунди (използвайки само настоящото състояние: Оставащ размер / скорост на изтегляне) или, най-вероятно, браузърът използва алгоритъм на усукана средна стойност, който ще се коригира за колебанията в скоростта на предаване, без да показва драматични скокове на потребителя.
Пример за алгоритъм за подвижване по отношение на изтеглянето на файл може да работи по следния начин:
Така че, използвайки нашия сценарий по-горе (с цел простота ще използваме 1 MB = 1.000 KB):
Можете да видите шаблона, който се появява тук, тъй като намаляването на скоростта на изтегляне бавно се включва в средната стойност, която се използва за оценка на оставащото време. При този метод, ако потапянето трае само 10 секунди и след това се върне на 1 MB / s, е малко вероятно потребителят да забележи разликата (освен за много малък период от време в очакваното време за обратно броене).
Как да стигнем до месинговите карета - това е просто методология за предаване на информация на крайния потребител за действителната основна причина ...
В крайна сметка, грешката в прогреса се свежда до факта, че се опитва да определи време за нещо, което е недетерминистично.Тъй като компютрите обработват задачи както при поискване, така и на заден план, е почти невъзможно да се знае какви системни ресурси ще бъдат налични във всеки един момент в бъдеще - и наличието на системни ресурси, които са необходими за завършване на задачата.
Като използвате друг пример, предполагайте, че провеждате надстройване на програма на сървър, който извършва доста интензивна актуализация на базата данни. По време на процеса на актуализиране потребителят изпраща след това искане към друга база данни, изпълняваща тази система. Сега ресурсите на сървъра, особено за базата данни, трябва да обработват заявки както за надстройката, така и за заявката, инициирана от потребителя - сценарий, който със сигурност ще бъде вредно за времето за изпълнение. Алтернативно, потребителят би могъл да инициира голяма заявка за прехвърляне на файлове, която би облагала складовата производителност, която също би намалила производителността. Или може да започне задачата, която изпълнява процес, изискващ памет. Получавате идеята.
Като може би по-реалистичен пример за всекидневен потребител - помислете дали да пуснете Windows Update или вирусно сканиране. И двете операции извършват операции с много ресурси във фонов режим. В резултат на това, всеки напредък зависи от това, което потребителят прави по това време. Ако четете своя имейл, докато това се изпълнява, най-вероятно търсенето на системни ресурси ще бъде ниско и лентата за напредък ще се движи последователно. От друга страна, ако правите графично редактиране, тогава вашето търсене на системни ресурси ще бъде много по-голямо, което ще предизвика движение на лентата на прогреса да бъде шизофреничен.
Като цяло, просто няма кристална топка. Дори самата система не знае какъв товар ще бъде във всеки един момент в бъдеще.
Намерението на лентата за напредък е да покаже, че наистина се постига напредък и съответният процес не е окачен. Хубаво е, когато индикаторът за напредъка е точен, но обикновено това е незначително раздразнение, когато не е така. В по-голямата си част разработчиците няма да отделят много време и усилия в алгоритми за прогрес, защото, честно казано, има много по-важни задачи, с които да отделите повече време.
Разбира се, имате всички права да бъдете раздразнени, когато прогресната лента скача до 99%, завършва незабавно и след това ви кара да изчакате 5 минути за оставащия един процент. Но ако съответната програма работи добре, просто си напомнете, че разработчикът е имал своите приоритети прави.
