我有一段代码以递归方式扫描目录，然后解码并加载来自支持的文件类型的信息。这很好。
问题是这个过程可能需要很长时间才能完成，所以我试图找到一种方法来进行进度报告。 （完成百分比和估计剩余时间）
但是存在一个概念上的问题：
我最初的想法是遍历所有文件夹并计算有多少文件，然后根据此数字进行进度报告。这会给大型文件结构带来问题（包含数百万个文件和文件夹）。
或者，我虽然在计算进度。当我浏览目录时，将文件添加到我的总计数文件中。但这意味着随着新文件/文件夹的发现，进度可以上下变化。我的进步将毫无意义，因为单个足够大的文件夹可能会显着降低我的进度。
这个概念问题是否有替代解决方案？也许某种形式的混合解决方案？
我使用Java，应该重要。 （虽然我不知道会怎么样）
答案 0 :(得分：0)
随机估计
您还可以执行深度优先搜索并估算剩余的工作，并在进度时更新估算值。只需平均每个级别的扇出率，并将这些统计信息应用于每个未知文件夹。这并不完美，您可能希望对现实世界组织的某些幂律分布敏感（即文件夹中文件数量的日志通常是（高斯）分布的）。
但是，这仍然会受到波动的影响。如果第一个叶子包含1,000个目标文件（并且处于大扇出状态下），并且树的其余部分每个叶子只有0-5个，那么您的初始估计值将非常高。如果订单被撤销，您将进行人为的低估计，直到最终的0.1％占用实际运行时间的一半。
完整计数
计算大型文件系统中的条目需要花费这么长时间吗？这将与负载解码阶段进行比较。提供更准确的进度报告是否值得花费？请记住，您不必解释每个文件名。只计算目标文件的数量，然后重复每个目录的nodeID。如果可以的话，处理那些节点ID（整数）而不是字符串名称的开销。