Alla uppdrag skapas inte lika

Det enklaste sättet att implementera en progressiv bar är att använda en grafisk representation av uppgiftsräknaren. Där det procentuella resultatet helt enkelt beräknas som

Avslutade uppgifter / Totalt antal uppgifter

. Även om detta ger en logisk förståelse för första tanke, är det viktigt att komma ihåg att vissa uppdrag tar längre tid att fullborda. Tänk på följande uppgifter utförda av en installatör: Skapa mappstruktur.

Dekomprimera och kopiera 1 GB värde av filer.

1. Skapa registerposter.
2. Skapa startmeny poster.
3. I det här exemplet skulle steg 1, 3 och 4 slutföra mycket snabbt medan steg 2 skulle ta lite tid. Så en progressiv bar som arbetar med en enkel räkning skulle hoppa till 25% väldigt snabbt, stanna en stund medan steg 2 arbetar och sedan hoppa till 100% nästan omedelbart.
4. Denna typ av implementering är faktiskt ganska vanlig bland progressionsfält eftersom det som sagt ovan är lätt att implementera. Men som du kan se är det föremål för oproportionerliga uppgifter som strider mot

faktiska

-procentandelen när det gäller tiden som återstår. För att komma runt om det här kan vissa framdriftsfält använda implementeringar där steg viktas. Tänk på stegen ovan där en relativ vikt tilldelas varje steg: Skapa mappstruktur. [Vikt = 1]

Dekomprimera och kopiera 1 GB värde av filer. [Vikt = 7]

1. Skapa registerposter. [Vikt = 1]
2. Skapa startmeny poster. [Vikt = 1]
3. Med hjälp av den här metoden går framdriftsfältet i steg om 10% (eftersom den totala vikten är 10) med steg 1, 3 och 4 flyttar stången 10% vid fullbordandet och steg 2 flyttar det 70%. Även om det inte är perfekt, är metoder som detta ett enkelt sätt att lägga till lite mer noggrannhet i progressfältet.
4. Tidigare resultat garanterar inte framtida resultat

Tänk på ett enkelt exempel på att jag ber dig räkna till 50 medan Jag använder en stoppur för att klara dig. Låt oss säga att du räknar till 25 på 10 sekunder. Det vore rimligt att anta att du kommer att räkna de återstående numren på ytterligare 10 sekunder, så att en spårning av progressbalk skulle visa 50% komplett med 10 sekunder kvar.

När din räkning når 25 börjar jag dock kasta tennisbollar på dig. Det här kommer sannolikt att bryta din rytm när din koncentration har flyttat från strängt räkna siffror för att dodging bollar kastade dig. Om du antar att du kan fortsätta räkna, har din takt definitivt minskat lite. Så nu går framdriftsfältet fortfarande, men i en mycket långsammare takt med den beräknade tiden som stannar antingen i stillastående eller faktiskt klättra högre.

För ett mer praktiskt exempel på detta, överväga en filhämtning. Du hämtar för närvarande en 100 MB-fil med en hastighet på 1 MB / s. Det här är väldigt lätt att bestämma den beräknade tiden för slutförandet. Men 75% av vägen där, det hinner vissa nätverkstopp och din nedladdningshastighet sjunker till 500 KB / s.

Beroende på hur webbläsaren beräknar den återstående tiden kan din ETA direkt gå från 25 sekunder till 50 sekunder (med nuvarande Endast tillstånd:

Storlek kvarvarande / Hastighet

) eller, med största sannolikhet, använder webbläsaren en rullande medelalgoritm som skulle anpassa sig för fluktuationer i överföringshastigheten utan att visa dramatiska hopp för användaren. Ett exempel på en rullande algoritm när det gäller att hämta en fil kan fungera så här: Överföringshastigheten för de föregående 60 sekunderna kommer ihågs med det nyaste värdet som ersätter det äldsta (t.ex. 61: e värdet ersätter det första).

Den effektiva överföringen ränta för beräkningsberäkningen är medelvärdet av dessa mätningar.

• Återstående tid beräknas som:
• Återstående storlek / Effektiv nedladdningshastighet
• Så här använder vi vårt scenario ovan (för enkelhets skull använder vi 1 MB = 1.000 KB): Vid 75 sekunder i nedladdningen, våra 60 minnsvärden skulle vardera vara 1000 kB. Den effektiva överföringshastigheten är 1000 kB (60 000 kB / 60), vilket ger en återstående tid på 25 sekunder (25 000 kB / 1000 kB).

Vid 76 sekunder (där överföringshastigheten sjunker till 500 kB) blir ~ 992 KB (59,500 KB / 60) vilket ger en återstående tid på ~ 24,7 sekunder (24,500 KB / 992 KB).

• Vid 77 sekunder: Effektiv hastighet = ~ 983 KB (59.000 KB / 60) ~ 24,4 sekunder (24.000 KB / 983 KB).
• Vid 78 sekunder: Effektiv hastighet = 975 KB (58.500 KB / 60) vilket ger resterande tid på ~ 24,1 sekunder (23,500 KB / 975 KB).
• Du kan se mönstret som dyker upp här som dip i nedladdningshastigheten införs långsamt i medelvärdet som används för att uppskatta den återstående tiden. Under denna metod, om dipet bara varade i 10 sekunder och sedan återvände till 1 MB / s, är det osannolikt att användaren märker skillnaden (spara för en mycket liten stall i beräknad tidräkning).
• Komma till mässingstakarna - det här är helt enkelt metod för att vidarebefordra information till slutanvändaren för den faktiska bakomliggande orsaken ...

Det går inte att bestämma någonting som är Nondeterministic

I slutändan beror progressionsfelaktigheten på att det försöker bestämma en tid för något som är nondeterministic. Eftersom datorer hanterar uppgifter både efterfrågan och bakgrunden är det nästan omöjligt att veta vilka systemresurser som kommer att finnas tillgängliga när som helst i framtiden - och det är tillgången på systemresurser som behövs för att någon uppgift ska kunna slutföras.

Använd ett annat exempel, anta att du kör en programuppgradering på en server som utför en ganska intensiv databasuppdatering. Under denna uppdateringsprocess skickar en användare sedan en krävande begäran till en annan databas som körs på det här systemet. Nu måste serverresurserna, specifikt för databasen, behandla förfrågningar både för din uppgradering och för användarens initierade fråga - ett scenario som säkert kommer att vara ömsesidigt skadligt för exekveringstiden. Alternativt kan en användare initiera en stor filöverföringsförfrågan som skulle skatta lagringskapaciteten som skulle också skada prestandan. Eller en schemalagd uppgift kan sparka ut som utför en minnesintensiv process. Du får tanken.

Som kanske en mer realistisk instans för en daglig användare - överväga att köra Windows Update eller en virusskanning. Båda dessa operationer utför resursintensiva operationer i bakgrunden. Till följd av detta är framstegen varje tillverkning beroende av vad användaren gör vid den tiden. Om du läser ditt e-postmeddelande medan det här körs, är det troligt att efterfrågan på systemresurser kommer att vara låg och framdriftsfältet kommer att flytta konsekvent. Å andra sidan, om du gör grafikredigering så kommer din efterfrågan på systemresurser att bli mycket större, vilket kommer att göra att rörelsen i framdriftslinjen blir schizofren.

Det är helt enkelt att det inte finns någon kristallkula. Inte ens systemet själv vet vilken belastning det kommer att vara under någon tidpunkt i framtiden.

I slutändan är det verkligen inte fråga.

Förloppet för framstegsfältet är att väl ange att framsteg verkligen görs och respektive process hänger inte. Det är trevligt när framdriftsindikatorn är korrekt, men det är vanligtvis bara en mindre irritation när det inte är det. För det mesta kommer utvecklare inte att ägna mycket tid och ansträngning till framstegsalgoritmer eftersom det är uppriktigt att det finns mycket viktigare uppgifter att spendera tid på.

Du har självklart rätt att vara irriterad när en progressiv spår till 99% slutförs direkt och sedan får du vänta 5 minuter för de återstående 1 procenten. Men om respektive program fungerar bra övergripande, bara påminna dig om att utvecklaren hade sina prioriteringar rakt.

Så här ändrar du skärmbilder sparas i OS X

Skärmdumpar är lätta att ta i OS X. Du kan antingen använda Command + Shift + 3 eller Command + Shift + 4 för att ta full skärm skärmdumpar eller crosshair skärmdumpar. Som standard sparas dessa bilder på skrivbordet, men det finns ett enkelt sätt att ändra det. För att göra detta behöver du bara köra några kommandon i terminalen.

(how-to)

Hur digital bildskärning fungerar och varför du borde använda den

Bildskärning kan bara vara det mest underutnyttjade digitala fotografitricket här sidan om att studera histogrammet. Läs vidare när vi förklarar vilken bildskärpa är, varför vi behöver det, vad det gör, och varför du bör tillämpa det på dina egna bilder, för att förvisa fuzzy kanter och göra dina bilder pop.

(how-to)