La început, se pare că generarea unei estimări precise a timpului ar trebui să fie destul de ușoară. La urma urmei, algoritmul care produce bara de progres cunoaște toate sarcinile pe care trebuie să le îndeplinească înainte ... corect?
În cea mai mare parte, este adevărat că algoritmul sursă nu știe ce trebuie să facă înainte. Cu toate acestea, fixarea timpului necesar pentru realizarea fiecărui pas este o sarcină foarte dificilă, dacă nu chiar imposibilă.
Cea mai simplă modalitate de a implementa o bară de progres este de a folosi o reprezentare grafică a contorului de sarcini. În cazul în care procentul complet este pur și simplu calculat ca Sarcini completate / numărul total de sarcini. În timp ce acest lucru are sens logic la prima gândire, este important să ne amintim că (în mod evident) unele sarcini durează mai mult pentru a finaliza.
Luați în considerare următoarele sarcini efectuate de un instalator:
În acest exemplu, pașii 1, 3 și 4 se vor termina foarte repede, în timp ce pasul 2 va dura ceva timp. Deci un bara de progres care lucra la un număr simplu ar urca foarte repede la 25%, se va stăpâni puțin în timp ce pasul 2 va funcționa și apoi va sari la 100% aproape imediat.
Acest tip de implementare este de fapt destul de comun printre barele de progres, deoarece, așa cum sa menționat mai sus, este ușor de implementat. Cu toate acestea, după cum puteți vedea, este supus unor sarcini disproporționate real Procentul progresului în ceea ce privește timpul rămas.
Pentru a rezolva această problemă, unele bare de progres pot folosi implementări în care pașii sunt ponderați. Luați în considerare pașii de mai sus în cazul în care o greutate relativă este atribuită fiecărei etape:
Folosind această metodă, bara de progres s-ar muta în trepte de 10% (greutatea totală este de 10), treptele 1, 3 și 4 mutând bara 10% la finalizare și pasul 2 deplasându-l cu 70%. În timp ce cu siguranță nu este perfect, metodele de acest gen sunt o modalitate simplă de a adăuga un pic mai multă precizie la procentul barei de progres.
Luați în considerare un exemplu simplu de a vă cere să numărați până la 50 de ani în timp ce folosesc un cronometru pentru a vă oferi timp. Să presupunem că numărați la 25 în 10 secunde. Ar fi rezonabil să presupunem că veți număra restul de numere în încă 10 secunde, astfel că un bara de progres urmărind acest lucru ar arăta 50% completă, cu 10 secunde rămase.
Odată ce numărul dvs. ajunge la 25, totuși, încep să arunc mingi de tenis la tine. Probabil, acest lucru vă va rupe ritmul pe măsură ce concentrarea dvs. sa mutat de la numărarea cu strictețe a numerelor la bilele de evadare aruncate în cale. Presupunând că sunteți capabili să continuați să numărați, ritmul tău a încetinit puțin. Așa că acum bara de progres se mișcă, dar într-un ritm mult mai lent, cu timpul estimat rămânând fie în staționare, fie chiar alpinat mai sus.
Pentru un exemplu mai practic despre acest lucru, luați în considerare descărcarea unui fișier. În prezent, descărcați un fișier de 100 MB la o rată de 1 MB / s. Este foarte ușor să determinați timpul estimat de finalizare. Dar 75% din acest mod, unele hituri de congestie a rețelei și rata descărcării scade la 500 KB / s.
În funcție de modul în care browserul calculează timpul rămas, ETA ar putea trece instantaneu de la 25 de secunde la 50 de secunde (folosind numai starea actuală: Dimensiunea rămasă / viteza de descărcare) sau, cel mai probabil, browserul folosește un algoritm de medie turație care se va ajusta pentru fluctuațiile vitezei de transfer fără a afișa salturi dramatice către utilizator.
Un exemplu de algoritm de rulare cu privire la descărcarea unui fișier ar putea funcționa astfel:
Deci, folosind scenariul de mai sus (de dragul simplității, vom folosi 1 MB = 1.000 KB):
Puteți vedea modelul care apare aici, deoarece scăderea vitezei de descărcare este încet încorporată în media care este utilizată pentru a estima timpul rămas. Prin această metodă, dacă dip-ul a durat doar 10 secunde și apoi a revenit la 1 MB / s, este puțin probabil ca utilizatorul să observe diferența (cu excepția unui stand foarte mic în timpul de numărare inversat).
Noțiuni de bază la aripi de alamă - aceasta este pur și simplu metodologia de transmitere a informațiilor către utilizatorul final pentru cauza reală de bază ...
În cele din urmă, inexactitatea bara de progres se reduce la faptul că încearcă să determine timpul pentru ceva care nu este determinist.Deoarece computerele procesează sarcini atât la cerere, cât și în fundal, este aproape imposibil să știm ce resurse de sistem vor fi disponibile în orice moment în viitor - și este disponibilitatea resurselor de sistem necesare pentru îndeplinirea oricăror sarcini.
Folosind un alt exemplu, să presupunem că executați o actualizare de program pe un server care efectuează o actualizare destul de intensă a bazei de date. În timpul acestui proces de actualizare, un utilizator trimite apoi o solicitare solicitantă către o altă bază de date care rulează pe acest sistem. Acum, resursele serverului, în mod special pentru baza de date, trebuie să proceseze cereri atât pentru actualizarea dvs., cât și pentru interogarea inițiată de utilizator - un scenariu care va fi cu siguranță un efect negativ asupra duratei de execuție. Alternativ, un utilizator ar putea iniția o cerere mare de transfer de fișiere care să impoziteze capacitatea de stocare, ceea ce ar afecta și performanța. Sau ar putea începe o sarcină programată, care să efectueze un proces intensiv de memorie. Ai idee.
Ca, probabil, o instanță mai realistă pentru un utilizator de zi cu zi - luați în considerare rularea Windows Update sau scanarea de virusi. Ambele operațiuni realizează operații cu resurse intensive în fundal. În consecință, progresele înregistrate de fiecare depinde de ceea ce face utilizatorul în acel moment. Dacă citiți e-mailul în timp ce acest lucru se execută, cel mai probabil cererea de resurse de sistem va fi scăzută și bara de progres se va mișca în mod consecvent. Pe de altă parte, dacă faceți editare grafică, cererea dvs. privind resursele de sistem va fi mult mai mare, ceea ce va determina mișcarea bara de progres să fie schizofrenică.
În general, este pur și simplu că nu există nici o minge de cristal. Nici sistemul în sine nu știe ce încărcare va fi în orice moment în viitor.
Scopul barei de progres este de a indica, bineînțeles, că se înregistrează progrese și că procesul respectiv nu este atins. Este drăguț atunci când indicatorul de progres este corect, dar în mod obișnuit este vorba doar de o mică neplăcere atunci când nu este. În cea mai mare parte, dezvoltatorii nu vor dedica prea mult timp și efort în algoritmii pentru bara de progres, deoarece, sincer, există sarcini mult mai importante pentru a petrece timpul.
Desigur, aveți toate dreptul de a fi supărat atunci când o bară de progres sare până la 99% complet instantaneu și apoi vă face să așteptați 5 minute pentru restul de unu la sută. Dar dacă programul respectiv funcționează bine în ansamblu, reamintiți-vă că dezvoltatorul avea prioritățile lor drepte.
