我们都曾 mock 过“还剩 X 分钟”的对话框,它似乎过于简单,但我们如何改进它呢?
实际上,输入是截至当前时间的一组下载速度,我们需要使用它来估计完成时间,也许带有确定性指示,例如使用一些 Y% 的“剩余 20-25 分钟”置信区间。
这样做的代码可以放在一个小库中并在所有项目中使用,所以真的有那么难吗?你会怎么做?您会给以前的下载速度赋予什么样的权重?
或者是否已经有一些开源代码?
编辑:总结:
- 通过更好的算法/过滤器等改进预计完成时间。
- 提供间隔而不是单一时间('1h45-2h30 分钟'),或者只限制精度('大约 2 小时')。
- 指出进展何时停滞 - 尽管如果进展持续停滞然后继续,我们应该能够处理。可能“大约 2 小时,目前停滞不前”
最佳答案
更一般地说,我认为您正在寻找一种即时测量传输速度的方法,传输速度通常通过一小段时间内的平均值获得。
问题一般是为了有反应,周期通常极小,从而导致溜溜球效应。
我会提出一个非常简单的方案,让我们对其建模。
考虑随时间 (x) 变化的曲线速度 (y)。
Instant Speed,只不过是读取当前 x (x0) 的 y。
平均速度,不超过
Integral(f(x), x in [x0-T,x0])/T
我建议的方案是应用过滤器,为最后时刻赋予更多权重,同时仍将过去时刻考虑在内。
它可以很容易地实现为 g(x,x0,T) = 2 * (x - x0) + 2T
,这是表面 T 的简单三角形。
现在您可以计算 Integral(f(x)*g(x,x0,T), x in [x0-T,x0])/T
,这应该可以工作,因为这两个函数总是积极的。
当然你可以有一个不同的 g
,只要它在给定的区间内总是正的并且它在区间上的积分是 T(所以它自己的平均值恰好是 1)。
此方法的优势在于,因为您对即时事件给予了更多权重,所以即使您考虑更大的时间间隔,您也可以保持相当的 react 性(因此平均值更精确,并且不易出现问题)。
此外,我很少看到但认为可以提供更精确估计的是将用于计算平均值的时间与估计的剩余时间相关联:
- 如果我下载一个5ko文件,它会立即加载,无需估计
- 如果我下载一个 15 Mo 的文件,大约需要 2 分钟,所以我想估计是……每 5 秒?
- 如果我下载一个 1.5 Go 文件,它需要……大约 200 分钟(以相同的速度)……也就是说 3 小时 20 分钟……也许每分钟估计一次就足够了?
因此,下载时间越长,我需要的 react 越少,我可以平衡的就越多。一般来说,我会说一个窗口可以覆盖总时间的 2%(也许除了少数几个初步估计,因为人们喜欢即时反馈)。此外,一次按整个 % 指示进度就足够了。如果任务很长,我准备等待。
关于algorithm - 估计/预测下载完成时间,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/1881652/