点击关注公众号,Java干货及时送达
这是一个充满魔力的数字,曾让我狂躁、焦虑,甚至激动得想砸键盘锤电脑扔手机。结果半小时过去了,进度条死死卡在99%,任你千兆光纤,专线宽带,愣是一丝不动,稳如泰山。即使你重启电脑,重新打开下载软件,重新开始那99%的下载任务,它依旧还是99%,不增不减。
你不禁开始疑惑:为什么进度条总要卡在99%?为什么最后1%永远加载不动?
今天,要为大家破解这一千古谜题,揭开背后不可告人的真相。 技术原理导致
1896年,波兰经济学家Karol Adamiecki制作了一种名叫时间表的图,提出了早期的进度条概念,但是当时没有具体的应用。
等到1979年,这哥们Mitchell Model在他的博士论文中提出了进度条。
其实这种 1% 随时都在发生,但我们只对最后的 1% 印象深刻。
它有时候前面很快,后面很慢。
就像 U 盘复制文件,系统会根据文件数量和传输速度算好大概时间,但并不是每个百分比都执行相同的工作,因为每个文件大小都不一样,而最后 1% 可能因为还要验证文件、全盘扫描、整理数据等等,所以耗时也最久。
它也可能一直不快不慢,因为它整条都是假的。
虽然卡在 99% 的等待并不让人愉快,但也不得不承认,没有 0% 到 99%,我们的情绪会更焦躁,因为不知道尽头在哪里。这就是进度条的厉害之处 —— 让你心甘情愿地等待。 产品经理的恶意
1985 年,卡内基梅隆大学人机交互研究所教授 Brad Myers 还是一位研究生,当时他就在论文里提出了这个观点。只要看到进度条,人们就会感觉好点,它能让人放松,让人在等待时间去干点别的 —— 去花 5 分钟发个传真,或者干些在 1985 年的办公室会干的事。
假设现在有2个相同下载速度的进度条,A和B,它们的下载完成时间都是100秒。A是经过产品经理特殊调教的虚假进度条,它很套路,用了20秒下载到99%,最后1%花了80秒完成。B是老实进度条,没被调教,10秒加载到10%,100秒100%,一分不差。此时因为A前十秒加载到99%,而同样时间B却仅有10%,在强烈的对比下,大部分人会认为A比B更快,A比B更好用。在优胜劣汰的规则下,用户肯定更多会选择A这种方式的软件,而产品经理想要留住用户,采用这种虚假进度条那是必须的。现在明白了吧,有时候不是进度条不准,而是产品经理在搞事。 下载完成后的块校验
根据我多年的经验,导致这种情况发生的原因主要还是因为资源块校验的机制。迅雷下载采用P2P协议加速,P2P的优点在于有多个数据来源。每个下载过该文件的人,相当于一台服务器,当别人下载时自动在后台上传数据,提供速度。说白了就是下的人越多,你所下载的资源能被拼凑时间越短。但缺点同样也有,因为数据来源多,质量参差不齐外加上传不稳定,容易导致文件乱码出错。因此迅雷定下了一个规则:在下载到99.9%的时候,会对文件进行块检验,如果某个块出现问题,无法重新下载,则会一直卡在当前进度不动。如果哪天卡在99.9%不动,别傻楞去充白金会员,大声告诉你:钛金会员都没用!
如有文章对你有帮助,
“在看”和转发是对我最大的支持!
最近面试BAT,整理一份面试资料《Java面试BAT通关手册》,覆盖了Java核心技术、JVM、Java并发、SSM、微服务、数据库、数据结构等等。获取方式:关注公众号并回复 java 领取,更多内容陆续奉上。