Lielākoties ir taisnība, ka avota algoritms zina, kas tam jādara pirms laika. Taču pīķēšana, kad jāveic katrs solis, būs ļoti grūti, ja ne praktiski neiespējami.
Visi uzdevumi nav izveidoti vienādi
Vienkāršākais veids, kā īstenot progresa joslu, ir izmantot uzdevumu skaitītāja grafisko attēlojumu. Ja procenti pabeigti, tiek vienkārši aprēķināts kā Pabeigtie uzdevumi / kopējais uzdevumu skaits. Lai gan tas loģiski nozīmē pirmo domu, ir svarīgi atcerēties, ka (protams) daži uzdevumi aizņem vairāk laika, lai pabeigtu.
Apsveriet šādus uzdevumus, ko veic uzstādītājs:
- Izveidot mapju struktūru.
- Atspiest un kopēt 1 GB lielu failu.
- Izveidot reģistra ierakstus.
- Izveidojiet sākuma izvēlnes ierakstus.
Šajā piemērā 1., 3. un 4. darbība pabeigtu ļoti ātri, kamēr 2. darbība prasīs zināmu laiku. Tātad progresa josla, kas strādā ar vienkāršu skaitli, ļoti strauji pietuvināsies līdz 25%, nedaudz nomainās, bet 2. solis strādā, un pēc tam pāriet uz 100% gandrīz uzreiz.
Šāda veida ieviešana patiesībā ir diezgan izplatīta starp progresa joslām, jo, kā minēts iepriekš, to ir viegli īstenot. Tomēr, kā redzat, uz to attiecas nesamērīgi uzdevumi faktiskais progresa procents, jo tas attiecas uz atlikušo laiku.
Lai to paveiktu, daži progresa stieņi var izmantot implementācijas, kurās tiek veiktas pakāpes. Apsveriet iepriekš minētos soļus, kur relatīvais svars tiek piešķirts katram solim:
- Izveidot mapju struktūru. [Svars = 1]
- Atspiest un kopēt 1 GB lielu failu. [Svars = 7]
- Izveidot reģistra ierakstus. [Svars = 1]
- Izveidojiet sākuma izvēlnes ierakstus. [Svars = 1]
Izmantojot šo metodi, progresa josla 10% soli pa solim (kopējais svars ir 10) ar soļiem 1, 3 un 4 pārvietojas, pabeidzot joslu 10%, un 2. solis pārvieto to par 70%. Kaut arī noteikti nav perfekta, tādas metodes kā šis ir vienkāršs veids, kā pievienot progresa joslas procentuālo daļu nedaudz lielāku precizitāti.
Iepriekšējie rezultāti negarantē nākotnes sniegumu
Tiklīdz jūsu skaits sasniedz 25, tomēr es sāku izspēlēt tenisa bumbiņas pie jums. Iespējams, tas pārtrauks jūsu ritmu, jo jūsu koncentrācija ir mainījusies no stingras skaitīšanas skaitīšanas, lai izvairītos no bumbām, kuras izmeta tavs ceļš. Pieņemot, ka jūs varat turpināt skaitīšanu, jūsu temps nedaudz palēninājās. Tātad tagad progresa josla joprojām ir kustībā, bet daudz lēnākā tempā, salīdzinot ar aplēsto laiku, kas paliek vai nu apstājoties, vai faktiski kāpšana augstāka.
Lai iegūtu praktisku piemēru, apsveriet failu lejupielādi. Jūs pašlaik lejupielādējat 100 MB failu ar ātrumu 1 MB / s. Tas ir ļoti viegli noteikt paredzamo pabeigšanas laiku. Bet 75% no tā ir, daži tīkla pārslogotības trāpījumi un jūsu lejupielādes ātrums samazinās līdz 500 KB / s.
Atkarībā no tā, kā pārlūkprogramma aprēķina atlikušo laiku, jūsu ETA varētu uzreiz pāriet no 25 sekundēm līdz 50 sekundēm (izmantojot tikai pašreizējo stāvokli: Atlikušais lielums / lejupielādes ātrums) vai, visticamāk, pārlūkprogrammā tiek izmantots ritošais vidējais algoritms, kas pielāgotos pārsūtīšanas ātruma svārstībām, nerādot dramatiskas lecenus lietotājam.
Ritošā algoritma piemērs attiecībā uz faila lejupielādi varētu darboties šādi:
- Pārskaitīšanas ātrums iepriekšējām 60 sekundēm tiek atgādināts ar jaunāko vērtību, kas aizstāj vecāko (piemēram, 61. vērtība aizstāj pirmo).
- Faktiskais pārsūtīšanas ātrums aprēķina vajadzībām ir šo mērījumu vidējais lielums.
- Atlikušais laiks tiek aprēķināts kā: Atlikušais izmērs / efektīvais lejupielādes ātrums
Tātad, izmantojot mūsu iepriekšējo scenāriju (vienkāršības labad izmantosim 1 MB = 1,000 KB):
- Pēc 75 sekundēm lejupielādē mūsu 60 atcerējās vērtības katram ir 1000 KB. Efektīvais pārsūtīšanas ātrums ir 1 000 KB (60 000 KB / 60), kas dod 25 sekundes (25 000 KB / 1,000 KB) atlikušo laiku.
- Pēc 76 sekundēm (ja pārsūtīšanas ātrums samazinās līdz 500 KB), faktiskais lejupielādes ātrums kļūst ~ 992 KB (59 500 KB / 60), kas ļauj iegūt atlikušo laiku ~ 24,7 sekundes (24 500 KB / 992 KB).
- Pēc 77 sekundēm: Efektīvais ātrums = ~ 983 KB (59 000 KB / 60), kas nodrošina ~ 24,4 sekundes (24 000 KB / 983 KB).
- Pēc 78 sekundēm: efektīvais ātrums = 975 KB (58 500 kb / 60), kas rada ~ 24,1 sekundes (23 500 kB / 975 kB).
Jūs varat redzēt modeli, kas parādās šeit, jo lejupielādes ātruma iegremdēšana pamazām tiek iekļauta vidējā, ko izmanto, lai novērtētu atlikušo laiku. Saskaņā ar šo metodi, ja iemērkšana ilga tikai 10 sekundes un pēc tam atgriezās pie 1 MB / s, lietotājs, visticamāk, neatzīs šo starpību (izņemot ļoti nelielu apstāšanās vietu aplēstā laika skaitīšanas laikā).
Nokļūšana uz misiņa aizbāžņiem - tas ir vienkārši metodoloģija informācijas nodošanai galapatērētājam par faktisko pamatcēloņu …
Jūs nevarat precīzi noteikt kaut ko, kas nav nedeterministisks
Visbeidzot, progresa joslas neprecizitāte samazinās līdz faktam, ka tā cenšas noteikt laiku kaut kas nedeterministisks. Tā kā datori apstrādā uzdevumus gan pēc pieprasījuma, gan fona, gandrīz neiespējami zināt, kādi sistēmas resursi būs pieejami jebkurā nākotnē - un tas ir sistēmas resursu pieejamība, kas ir nepieciešama jebkura uzdevuma pabeigšanai.
Izmantojot citu piemēru, pieņemsim, ka jūs izmantojat programmas jaunināšanu uz servera, kas veic diezgan intensīvu datubāzes atjauninājumu. Šajā atjaunināšanas procesā lietotājs pēc tam nosūta pieprasītu pieprasījumu citai datubāzei, kas darbojas šajā sistēmā. Tagad servera resursiem, īpaši datu bāzei, ir jāapstrādā gan jaunināšanas pieprasījumi, gan lietotāja iniciētā vaicājums - scenārijs, kas neapšaubāmi kaitēs izpildes laikam. Tāpat lietotājs varētu uzsākt lielu failu pārsūtīšanas pieprasījumu, kas apliktu ar nodokli uzglabāšanas caurlaidspēju, kas arī mazinātu veiktspēju. Vai arī plānots uzdevums varētu uzsākt, kas veic atmiņas intensīvu procesu. Jūs iegūstat ideju.
Tā kā varbūt ir reālistiskāks gadījums ikdienas lietotājam, apsveriet Windows atjaunināšanu vai vīrusu skenēšanu. Abas šīs darbības veic resursu intensīvas darbības fonā. Rezultātā katrs no tiem izrietošais progress ir atkarīgs no tā, ko lietotājs tajā laikā dara. Ja jūs lasāt e-pastu, kamēr tas darbojas, visticamāk pieprasījums pēc sistēmas resursiem būs mazs un progresa josla mainīsies konsekventi. No otras puses, ja jūs veicat grafikas rediģēšanu, tad jūsu pieprasījums pēc sistēmas resursiem būs daudz lielāks, tādēļ progresa joslas kustība būs šizofrēniska.
Kopumā vienkārši ir tas, ka nav kristāla bumbiņas. Pat pati pati sistēma nezina, kāda slodze būs kādā brīdī nākotnē.
Galu galā, tas tiešām nav svarīgi
Progresa joslas nolūks ir, pareizi, norādīt, ka progress tiek īstenots, un attiecīgais process nav pakārtots. Tas ir jauki, ja progresa rādītājs ir precīzs, bet parasti tas ir tikai neliels satraukums, kad tas nav. Lielākajā daļā gadījumu izstrādātāji nav gatavojas veltīt daudz laika un pūļu progresa joslas algoritmos, jo, godīgi sakot, ir daudz svarīgāki uzdevumi, lai pavadītu laiku.
Protams, jums ir visas tiesības tikt sajūsmām, kad progresa josla pāriet uz 99% uzreiz, un pēc tam ļauj atlikt vienu procenti par 5 minūtēm. Bet, ja attiecīgā programma darbojas kopumā, vienkārši atgādiniet sev, ka izstrādātājam bija savas prioritātes.
