Sākumā domāja, šķiet, ka precīzai laika novērtēšanai vajadzētu būt diezgan viegli. Galu galā algoritms, kas veido progresa joslu, zina visus uzdevumus, kas tam jādara pirms laika ... pareizi?
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.
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:
Š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:
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.
Apsveriet vienkāršu piemēru no manis, aicinot jūs saskaitīt līdz 50, kamēr es laiku pa laikam izmantoju hronometru. Pieņemsim, ka jūs saskaitāt 25 pēc 10 sekundēm. Būtu pamatoti uzskatīt, ka atlikušos skaitļus skaitīs vēl 10 sekundes, tāpēc progresa joslas izsekošana to rādītu 50% un atlikušās 10 sekundes.
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:
Tātad, izmantojot mūsu iepriekšējo scenāriju (vienkāršības labad izmantosim 1 MB = 1,000 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 ...
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ē.
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.
