乍一看，对时间做出准确的估计似乎相当容易。毕竟，生成进度条的算法知道它需要提前完成的所有任务…对吗？

在大多数情况下，源算法确实知道它需要提前做什么。然而，确定执行每一步所需的时间是一项非常困难的任务，如果不是几乎不可能的话。

并非所有任务都是平等创建的

实现进度条的最简单方法是使用任务计数器的图形表示。其中完成百分比仅计算为已完成任务/任务总数。虽然这在逻辑上是合理的，但重要的是要记住（显然）有些任务需要更长的时间才能完成。

请考虑安装程序执行的以下任务：

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%时，你完全有权生气。但是，如果各个程序总体上运行良好，只需提醒自己开发人员已经明确了他们的优先级。