在窗口中显示下载状态时，我有如下信息：
1) 总文件大小 (f)
2) 下载文件大小 (f')
3) 当前下载速度（秒）
一个简单的剩余时间计算是 (f-f')/(s)，但这个值很不稳定（剩余 6m / 剩余 2h / 剩余 5m！似曾相识？！:)
会不会有一个既稳定又不会出错的计算（即使下载即将完成也显示1h）？
【问题讨论】：
我们通过以下方式解决了类似的问题。我们对整个时间内的下载速度不感兴趣，只是根据最近的活动大致预计需要多长时间，但正如你所说，不是最近的数字到处乱跳。
我们对整个时间范围不感兴趣的原因是，下载可能会在半小时内达到 1M/s，然后在接下来的 10 分钟内切换到 10M/s。前半小时会严重拖慢平均速度，尽管您现在正在以相当快的速度鸣喇叭。
我们创建了一个循环缓冲区，每个单元格保存 1 秒内的下载量。循环缓冲区大小为 300，允许 5 分钟的历史数据，并且每个单元格都初始化为零。
我们还维护了一个总数（缓冲区中所有条目的总和，因此最初也是零）和计数（显然是零）。
每一秒，我们都会计算出自上一秒以来下载了多少数据，然后：
基本上，在伪代码中：
def init (sz):
buffer = new int[sz]
for i = 0 to sz - 1:
buffer[i] = 0
total = 0
count = 0
index = 0
maxsz = sz
def update (kbps):
total = total - buffer[index] + kbps
buffer[index] = kbps
index = (index + 1) % maxsz
if count < maxsz:
count = count + 1
return total / count
您可以根据自己的情况更改分辨率（1 秒）和历史记录（300），但我们发现 5 分钟的时间已经足够长，可以消除不规则之处，但仍会及时逐渐适应更永久的变化。
【讨论】：
Smooth s（exponential moving avg. 或类似）。
【讨论】：
我更喜欢使用最后 10 秒的平均速度，然后除以剩余部分。划分为当前速度太不稳定，而划分为整个进度的平均值无法处理永久的速度变化（就像另一个下载正在开始）。
【讨论】：
为什么不将下载速度计算为整个下载的平均值，即：
s = f' / elapsed time
这样它会随着时间的推移而变得平滑。
【讨论】：