Human项目模型加载进度统计问题解析

问题背景

在Human项目（一个基于Web的人体检测和分析库）中，开发者发现了一个关于模型加载进度统计的有趣现象。具体表现为：当首次加载模型时（即模型尚未缓存到IndexedDB中），percentageLoaded统计值会保持在0，直到所有模型加载完成后才突然跳到100%。而在后续加载（模型已缓存）时，这个统计值则能正常显示加载进度。

技术原理分析

这个现象背后反映了Human项目模型加载机制的演变过程：

1. 历史实现：在早期版本中，Human采用顺序加载模型的方式，此时可以方便地计算并更新加载百分比，因为每个模型加载完成后都能明确知道整体进度。

2. 当前实现：现代版本改为异步并行加载模型，使用单个await等待所有Promise完成。这种优化显著提高了加载效率，但也带来了进度统计的变化：

   • 由于所有模型同时开始加载，系统无法准确知道每个中间阶段的完成情况
   • 统计值只能从0直接跳到100%，无法显示中间过程

解决方案与权衡

项目维护者考虑了两种可能的解决方案：

1. 侵入式方案：在每个模型加载器中更新全局统计，但这会：

   • 增加代码复杂度
   • 可能影响性能
   • 需要大量代码修改

2. 保持现状：接受从0到100%的跳变，因为：

   • 并行加载速度更快
   • 代码更简洁
   • 用户体验影响有限

最终，项目选择了一个折中方案并在开发版本中进行了修复，既保持了并行加载的优势，又解决了统计显示问题。

对开发者的启示

这个案例给前端开发者带来几点重要启示：

1. 性能与用户体验的平衡：并行加载提升了性能，但可能牺牲部分用户体验指标。开发者需要根据场景权衡。

2. 统计指标的设计：当底层实现改变时，上层指标可能需要相应调整，以保持其准确性和可用性。

3. 缓存机制的影响：IndexedDB等缓存策略会显著影响加载行为，开发者需要充分考虑首次加载和缓存加载的不同场景。

通过这个案例，我们可以更好地理解现代Web应用中资源加载机制的设计考量，以及如何在不同技术方案间做出合理选择。