Na prvi pogled, čini se da bi stvaranje točne procjene vremena trebalo biti prilično jednostavno. Uostalom, algoritam koji proizvodi bar napredak zna sve zadatke koje treba učiniti prije vremena ... zar ne?
U većini slučajeva, istina je da izvorni algoritam zna što treba učiniti prije vremena. Međutim, odlaganje vremena koje će trebati za izvođenje svakog koraka je vrlo težak, ako ne i praktički nemoguć zadatak.
Najjednostavniji način implementacije trake napretka je korištenje grafičkog prikaza brojača zadataka. Tamo gdje se postotak potpuna jednostavno izračunava kao Završene zadatke / ukupan broj zadataka, Iako ovo prvo razmišljanje čini logičnim smislom, važno je zapamtiti da (očito) neki zadaci traju duže.
Razmotrite sljedeće zadatke koje izvršava instalacijski program:
U ovom primjeru, koraci 1, 3 i 4 završili bi vrlo brzo dok bi korak 2 trebao malo vremena. Dakle, traka napretka koji rade na jednostavnom broju skočit će na 25% vrlo brzo, zaustaviti se malo, dok korak 2 radi, a zatim skočiti na 100% gotovo odmah.
Ova vrsta implementacije je zapravo prilično česta među trakama napretka jer je, kao što je već rečeno, lako implementirati. Međutim, kao što vidite, podložno je nerazmjernim zadacima koji su zaostajali stvaran postotak napretka jer se odnosi na preostalo vrijeme.
Da bi se ovo riješilo, neki se gumbi za napredovanje mogu koristiti implementacijama u kojima su koraci ponderirani. Razmislite o gore navedenim koracima gdje je dodijeljena relativna težina za svaki korak:
Koristeći ovu metodu, traka za napredovanje kretala se u koracima od 10% (kao ukupna težina 10) s koracima 1, 3 i 4 pomicanja trake 10% po završetku, a korak 2 pomiče 70%. Iako zasigurno nije savršen, takve metode su jednostavan način da dodate malo više točnosti na postotak stupnja napredovanja.
Razmislite o jednostavnom primjeru koji traži od vas da računate na 50 dok koristim štopericu na vrijeme. Pretpostavimo da računate na 25 u 10 sekundi. Bilo bi razumno pretpostaviti da ćete prebrojati preostale brojeve u dodatnih 10 sekundi, tako da će praćenje trake napretka pokazati 50% potpune s preostalim 10 sekundi.
Jednom kada vam broj dosegne 25, počinjem bacati teniske loptice na vas. Vjerojatno ćete ovo prekinuti ritam jer se koncentracija prebacuje iz strogo brojanih brojeva na izbjegavanje kugli koje su vam bačene. Pretpostavljajući da ste u mogućnosti nastaviti brojanje, vaš tempo je zasigurno usporio. Sada se traka napretka još uvijek kreće, ali u znatno sporije vrijeme s preostalim procijenjenim vremenom ostaje ili se uspravi.
Za praktičniji primjer toga, razmislite o preuzimanju datoteka. Trenutno preuzimate datoteku od 100 MB brzinom od 1 MB / s. Ovo je vrlo lako odrediti procijenjeno vrijeme dovršetka. No, 75% načina na koji se tamo pojavio, neki mrežni zastoj pogoduje i brzina preuzimanja pada na 500 KB / s.
Ovisno o tome kako preglednik izračunava preostalo vrijeme, vaš ETA mogao bi odmah ići od 25 sekundi do 50 sekundi (samo u trenutačnom stanju: Preostala veličina / Brzina preuzimanja) ili, najvjerojatnije, preglednik koristi prosječni algoritam koji se podešava za fluktuacije brzine prijenosa bez prikazivanja dramatičnih skokova korisnika.
Primjer algoritma za valjanje s obzirom na preuzimanje datoteke može raditi nešto slično:
Zato upotrijebite gore navedeni scenarij (za jednostavnost koristit ćemo 1 MB = 1000 KB):
Vidjet ćete uzorak koji se pojavljuje ovdje, jer je usporavanje brzine preuzimanja polako uključeno u prosjek koji se koristi za procjenu preostalog vremena. Pod ovom metodom, ako je umočen samo trajao 10 sekundi, a zatim se vraća na 1 MB / s, korisnik vjerojatno neće primijetiti razliku (osim vrlo malo zastoja u procijenjenom odbrojavanju vremena).
Doći do brass metode - to je jednostavno metodologija za prenošenje informacija krajnjem korisniku za stvarni temeljni uzrok ...
Naposljetku, nepreciznost naprednog stupnja svodi se na činjenicu da pokušava odrediti vrijeme za nešto što je neodređeno.Budući da računala obrađuju zadatke i na zahtjev iu pozadini, gotovo je nemoguće znati koji će resursi sustava biti dostupni u bilo kojem trenutku u budućnosti - a to je dostupnost resursa sustava potrebnih za dovršavanje bilo kojeg zadatka.
Pomoću drugog primjera, pretpostavimo da na poslužitelju imate nadogradnju programa koja obavlja prilično intenzivno ažuriranje baze podataka. Tijekom tog procesa ažuriranja, korisnik zatim šalje zahtjevan zahtjev drugoj bazi koja se izvodi na ovom sustavu. Sada resursi poslužitelja, posebno za bazu podataka, moraju obraditi zahtjeve za vašu nadogradnju, kao i korisnik pokrenuo upit - scenarij koji će sigurno biti uzajamno štetan za vrijeme izvršenja. Alternativno, korisnik može pokrenuti veliki zahtjev za prijenos datoteka koji bi porezao propusnost pohrane koja bi također mogla narušiti izvedbu. Ili bi mogao pokrenuti zakazani zadatak koji obavlja proces s intenzivnim memorijom. Dobivate ideju.
Kao, možda, realističniji primjer svakodnevnog korisnika - razmislite o pokretanju sustava Windows Update ili skeniranju virusa. Obje ove operacije izvode resurse intenzivne operacije u pozadini. Kao rezultat toga, svaki napredak ovisi o tome što korisnik trenutno radi. Ako čitate vašu e-poštu dok se to pokreće, najvjerojatnije će potražnja na resursima sustava biti niska i traka napretka će se kretati dosljedno. S druge strane, ako radite s grafičkim uređivanjem, vaša potražnja za resursima sustava bit će mnogo veća što će uzrokovati shizofrenu kretanje trake napretka.
Sve u svemu, jednostavno je da nema kristalne kugle. Čak niti sam sustav ne zna što će biti opterećeno u bilo kojem trenutku u budućnosti.
Namjera trake napretka je, dobro, ukazati na to da se napredak doista stvara, a odgovarajući proces nije obješen. Lijepo je kada je indikator napretka točan, ali obično je to samo manji smetnji kad to nije. U većini slučajeva, programeri neće uložiti puno vremena i napora u napredne algoritme bar jer, iskreno, postoje mnogo važnije zadaće da provedu vrijeme.
Naravno, imate pravo na neugodno vrijeme kada se traka napretka skoči na 99%, a zatim čeka 5 minuta za preostalih jedan posto. No, ako program djeluje dobro, samo se podsjetite da je programer imao svoje prioritete ravno.
