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ă.

Toate sarcinile nu sunt create egale

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 finalizate. Î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 se finaliza.

Luați în considerare următoarele sarcini efectuate de un instalator:

  1. Creează structura folderului.
  2. Decomprimă și copiază fișiere în valoare de 1 GB.
  3. Creează intrări de tip registry.
  4. Creează intrări din meniul de pornire.

În acest exemplu, pașii 1, 3 și 4 se vor termina foarte repede, în timp ce pasul 2 va dura ceva timp. Deci în bara de progres se lucrează la un număr simplu care se poate să urce 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. Cu toate acestea, după cum puteți vedea, este supusă unor sarcini disproporționate înclinate procentului real de progres î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 etapele de mai sus în cazul în care o sarcină relativă este atribuită fiecărei etape:

  1. Creeazăstructura folderului. [Greutate = 1]
  2. Decomprimă și copiază fișiere în valoare de 1 GB. [Greutate = 7]
  3. Creează intrări de tip registry. [Greutate = 1]
  4. Creează intrări din meniul de pornire. [Greutate = 1]

Folosind această metodă, bara de progres s-ar mișca cu 10% (cu greutatea totală de 10), etapele 1, 3 și 4 mutând bara 10% la finalizare, iar 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.

Rezultatele anterioare nu garantează performanța viitoare

Luați în considerare un exemplu simplu care nu vă cere decât să numărați până la 50 în timp ce folosesc un cronometru pentru a vă oferi timp. Să presupunem că numărați până la 25 în 10 secunde. Ar fi rezonabil să presupunem că veți număra restul de numere în încă 10 secunde, astfel o bară de progres ar arăta 50%, cu 10 secunde rămase.

Odată ce numărul dvs. ajunge la 25, încep să arunc cu mingi de tenis în tine. Probabil, acest lucru îți va strica ritmul pe măsură ce concentrarea ta s-a mutat pe bilele aruncate în cale. Presupunând că ești capabil să continui să numeri, 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 mai accelerat.

Pentru un exemplu mai practic, 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 totul nu se poate realiza la acuratețea pe care o presupuneți că va fi.

În funcție de modul în care browserul calculează timpul rămas, ETA ar putea trece instantaneu de la 25 secunde la 50 de secunde (folosind doar starea actuală: mărimea rămasă / viteza de descărcare) sau, cel mai probabil, browserul folosește un algoritm mediu rulant care se va ajusta pentru fluctuații în viteza 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:

  • Viteza de transfer pentru cele 60 de secunde anterioare este reținută cu cea mai recentă valoare înlocuind-o pe cea mai veche (de exemplu, cea de-a 61-a valoare o înlocuiește pe prima).
  • Rata efectivă de transfer în scopul calculării este media acestor măsurători.
  • Timpul rămas este calculat astfel: Viteza de descărcare, plus mărimea, plus ce a  rămas

Deci, folosind scenariul de mai sus (de dragul simplității, vom folosi 1 MB = 1.000 KB):

  • La 75 de secunde de descărcare, cele 60 de valori amintite ar fi fiecare 1000 KB. Rata de transfer efectivă este de 1.000 KB (60.000 KB / 60), ceea ce rezultă un timp de 25 de secunde (25.000 KB / 1.000 KB).
  • La 76 de secunde (unde viteza de transfer scade la 500 KB), viteza efectivă de descărcare devine ~ 992 KB (59,500 KB / 60), ceea ce duce la un timp rămas de ~ 24,7 secunde (24,500 KB / 992 KB).
  • La 77 de secunde: Viteză efectivă = ~ 983 KB (59.000 KB / 60), rezultând un timp rămas de ~ 24.4 secunde (24.000 KB / 983 KB).
  • La 78 secunde: Viteză efectivă = 975 KB (58,500 KB / 60), ceea ce înseamnă că timpul rămas este de ~ 24,1 secunde (23,500 KB / 975 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.

Nu puteți determina cu exactitate ceva care este nedeterminat

În cele din urmă, inexactitatea barei de progres se reduce la faptul că încearcă să determine timpul pentru ceva care nu este determinabil. 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

Folosind un alt exemplu, 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 interogare 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 care ar afecta și performanța. Sau ar putea începe o sarcină programată, care realizează un proces intensiv de memorie. Ai prins ideea.

Probabil, o instanță mai realistă pentru un utilizator de zi cu zi – luați în considerare rularea unui Update Windows 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 barei de progres mai încet decât ar trebui.

În cele din urmă, nu contează

Scopul barei de progres este de a indica, bineînțeles, faptul că are loc un progres. Este minunat atunci când bara de progres afișează corect estimarea, 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 își dedică prea mult timp și efort în algoritmii de progresie, deoarece, sincer, există sarcini mult mai importante pentru a-și petrece timpul.

Desigur, aveți tot dreptul să fiți 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 își pune prioritățile personale pe primul loc înainte de orice.

LĂSAȚI UN MESAJ

Please enter your comment!
Please enter your name here

Acest sit folosește Akismet pentru a reduce spamul. Află cum sunt procesate datele comentariilor tale.