乍一看，對時間做出準確的估計似乎相當容易。畢竟，生成進度條的演算法知道它需要提前完成的所有任務…對嗎？

在大多數情況下，源演算法確實知道它需要提前做什麼。然而，確定執行每一步所需的時間是一項非常困難的任務，如果不是幾乎不可能的話。

並非所有任務都是平等建立的

實現進度條的最簡單方法是使用任務計數器的圖形表示。其中完成百分比僅計算為已完成任務/任務總數。雖然這在邏輯上是合理的，但重要的是要記住（顯然）有些任務需要更長的時間才能完成。

請考慮安裝程式執行的以下任務：

1. 建立資料夾結構。
2. 解壓縮並複製1 GB的檔案。
3. 建立登錄檔項。
4. 建立“開始”選單項。

在本例中，步驟1、3和4將很快完成，而步驟2需要一些時間。因此，一個簡單計數的進度條會很快跳到25%，在第2步工作時暫停一段時間，然後幾乎立即跳到100%。

這種型別的實現實際上在進度條中非常常見，因為如上所述，它很容易實現。但是，正如您所看到的，由於它與剩餘時間相關，它會受到不相稱的任務的影響，使實際進度百分比發生偏差。

為了解決這個問題，一些進度條可能會使用加權步驟的實現。考慮以上步驟，其中每個步驟都分配了相對權重：

1. 建立資料夾結構。[重量=1]
2. 解壓縮並複製1 GB的檔案。[重量=7]
3. 建立登錄檔項。[重量=1]
4. 建立“開始”選單項。[重量=1]

使用此方法，進度條將以10%的增量移動（總重量為10%），步驟1、3和4在完成時將進度條移動10%，步驟2將進度條移動70%。當然，這樣的方法並不完美，但它是一種簡單的方法，可以提高進度條百分比的準確性。

過去的業績不能保證將來的業績

舉個簡單的例子，我讓你數到50，而我用秒錶給你計時。假設你在10秒內數到25。我們可以合理地假設您將在額外的10秒鐘內計算剩餘的數字，因此跟蹤這一點的進度條將在剩餘的10秒鐘內顯示50%的完成。

一旦你數到25，我就開始向你扔網球。很可能，這會打破你的節奏，因為你的注意力已經從嚴格計算數字轉移到躲避拋給你的球。假設你能繼續數數，你的速度肯定慢了一點。因此，現在進度條仍在移動，但速度要慢得多，預計剩餘時間要麼停滯，要麼實際上升得更高。

關於這個更實際的例子，請考慮檔案下載。您當前正在以1 MB/s的速率下載一個100 MB的檔案。這很容易確定估計的完成時間。但是75%的情況下，一些網路擁塞會發生，你的下載速率會下降到500kb/s。

根據瀏覽器計算剩餘時間的方式，您的ETA可以立即從25秒變為50秒（僅使用當前狀態：剩餘大小/****），或者，最有可能的是，瀏覽器使用滾動平均演算法，該演算法可以調整傳輸速度的波動，而不會向用戶顯示劇烈的跳躍。

有關下載檔案的滾動演算法示例可能如下所示：

• 用最新值替換最舊值（例如，第61個值替換第一個值）來記住前60秒的傳輸速度。
• 用於計算的有效傳輸率是這些測量值的平均值。
• 剩餘時間計算為：剩餘大小/有效****

因此，使用上面的場景（為了簡單起見，我們將使用1 MB=1000 KB）：

• 下載75秒後，我們記住的60個值將分別為1000 KB。有效傳輸速率為1000 KB（60000 KB/60），剩餘時間為25秒（25000 KB/1000 KB）。
• 76秒（傳輸速度降至500 KB）時，有效****變為約992 KB（59500 KB/60），剩餘時間約為24.7秒（24500 KB/992 KB）。
• 77秒時：有效速度=~983 KB（59000 KB/60），剩餘時間約為24.4秒（24000 KB/983 KB）。
• 78秒時：有效速度=975 KB（58500 KB/60），剩餘時間約為24.1秒（23500 KB/975 KB）。

你可以在這裡看到這種模式，****的下降慢慢地融入到用來估計剩餘時間的平均值中。在這種方法下，如果dip僅持續10秒，然後返回到1 MB/s，則使用者不太可能注意到差異（除了估計倒計時中非常小的暫停）。

直截了當-這只是一種方法，用於將資訊傳遞給終端使用者，以瞭解實際的根本原因…

你不能準確地確定不確定的東西

最終，進度條的不準確歸結為這樣一個事實：它試圖為不確定的事情確定一個時間。因為計算機可以按需處理任務，也可以在後臺處理任務，所以幾乎不可能知道在將來的任何時候什麼系統資源是可用的，而完成任何任務都需要系統資源的可用性。

使用另一個示例，假設您正在執行相當密集的資料庫更新的伺服器上執行程序升級。在這個更新過程中，使用者會向這個系統上執行的另一個數據庫傳送一個請求。現在，伺服器資源（特別是資料庫資源）必須同時處理升級請求和使用者發起的查詢請求，這種情況肯定會對執行時間造成相互損害。或者，使用者可以發起一個大的檔案傳輸請求，這將對儲存吞吐量徵稅，這也會降低效能。或者可以啟動一個執行記憶體密集型程序的計劃任務。你明白了。

作為一個對普通使用者來說更現實的例子，可以考慮執行Windows更新或病毒掃描。這兩種操作都在後臺執行資源密集型操作。因此，每個人的進步取決於使用者當時在做什麼。如果您正在閱讀您的電子郵件，而這執行，最有可能的需求系統資源將是低的，進度條將不斷移動。另一方面，如果你正在做圖形編輯，那麼你對系統資源的需求將更大，這將導致進度條運動精神分裂。

總的來說，這只是因為沒有水晶球。甚至連繫統本身都不知道它在未來的任何時候會承受什麼樣的負載。

歸根結底，這並不重要

進度條的意圖是，好吧，表明確實正在取得進展，並且相應的程序沒有掛起。當進度指標準確時，這是好事，但通常情況下，它只是一個小麻煩時，它不是。在很大程度上，開發人員不會在進度條演算法上投入大量的時間和精力，因為坦率地說，還有更重要的任務需要花時間。

當然，當進度條立即跳到99%完成，然後讓你等5分鐘等待剩下的1%時，你完全有權生氣。但是，如果各個程式總體上執行良好，只需提醒自己開發人員已經明確了他們的優先順序。