Question

我有一个按文件上传到服务器文件的系统，并显示文件上传进度的进度条，然后在第二个进度条下面，我想指出排队等待上传的所有文件的批量完成百分比。

我可以解决的信息和算法是：

已发送的字节数/要发送的总字节数=第一个进度条（例如，512KB的1024KB（50％））

工作正常。但是假设我还有两个其他文件要上传，但两个文件大小都是未知的（因为只有在文件即将开始上传时才会知道，此时它被压缩并确定文件大小）我将如何制作我的第三个进度条？

我不认为这是可能的，因为我需要“发送总字节数”/“要发送的总字节数”，以更大规模复制我的第一个进度条的逻辑，但是我确实得到了一个版本工作： “我们当前的文件编号”/“要发送的文件总数”通过批处理返回百分比，但显然不会逐步更新，而且非常粗糙。

所以进一步思考我认为如果我可以将当前文件％与此算法合并，我可能会得到我的批次当前点的正确进度百分比。

我试过这个算法，但是没有这么好用（对任何数学头都很抱歉，很可能很明显为什么它不起作用）

("Current file number we are on" / "total number of files to send") * ("Bytes Sent" / "Total Bytes To Send")

例如，当我使用这个例子进行测试时，我认为我在正确的轨道上：2/3（第3档文件中的第2个）= 66％（这是正确的）但是当我添加* 0.20时（仅表示20个）第二个文件的百分比已上传）我们回到了13％。我需要的只是33％多一点！我确实尝试了0.80和（2/3 *（2/3 * 0.2））

的逆

这可以在不知道要批量上传的整个字节的情况下完成吗？

请帮忙！谢谢！

Answer 1

如果您不知道其他排队文件有多大，那么就无法准确显示与所需时间相关且与所需时间成比例的百分比值。

我想到了许多解决方法：

看起来像你知道但实际上欺骗用户的一种方法是假设所有排队的文件与正在进行的文件大小相同，或者到目前为止处理的文件的平均值。基于此，如果所有文件的大小确实相同，进度条将显示“真相”，如果尺寸差别很大，则会非常关闭。
另一种方法是让您的第二个进度条显示不是传输的字节百分比，而是显示文件的百分比。因此，如果您有4个文件，那个条形将从0到25％到50％到75％到100％。它不会准确反映所花费的时间，但至少你不会撒谎。
你可以用微软这样的方法做得更糟：让你的进度条的增长渐渐变慢，因为它接近100％，所以它实际上从未到达终点。所有用户看到的都是“几乎完成”的更接近的值。这样的显示器看起来很酷，但实际上为用户提供了尽可能少的信息。

Answer 2

正如@Carl所观察到的那样，在不知道还有多少仍然要发送的情况下，你不能产生已经发送的比例的真实估计。暂时不考虑科学的准确性和完整性，你的计算：

("Current file number we are on" / "total number of files to send") * 
("Bytes Sent" / "Total Bytes To Send")

应该扩展到包含文件分数的想法。比方说，如果您从第7个文件的11％和30％中发送了6个文件，那么您需要计算

(6.3 / 11) * ("Bytes Sent" / "Total Bytes To Send")

沿着该行的某处，您将发送的文件数乘以当前已发送文件的比例，即您计算0.66*0.2=0.13，而不是添加当前文件的比例。

再次提高科学的准确性和完整性，为什么不在第二个进度条上使用传输速率？如果你把它整合到一个明智的时期，它应该给观察者一种令人满意的感觉，即某些事情正在发生并且正在取得进展。

Answer 3

哦，天哪，我没有考虑最简单的方法：

(double)((ProcessedFileCount + DecimalBytesTransferred) / TotalFileCount)

（其中processedFileCount始终指示完全传输和完整的文件）

和3个文件批次的证明测试案例：

Eg. ((2 + 1.0) / 3) (File 1+2+3: 100%) == batch 100% complete.
Eg. ((2 + 0.9) / 3) (File 1+2: 100%, File 3: 90%) == batch 96% complete.
Eg. ((1 + 0.9) / 3) (File 1: 100%, File 2: 90%) == only 63% complete.

努力享受！感谢您的意见，我会考虑所有外部建议。

使用有限的信息计算总批量上传传输百分比

3 个答案: