本文探讨WebKit浏览器在加载网页时进度条行为背后的算法，解释了为何简单网页能快速加载完毕，而复杂网页可能卡在90%。加载进度由ProgressTracker类控制，通过网络部分接收到的数据更新。算法中，remainingBytes的估算准确性至关重要，尤其是未开始传输的请求资源量（estimatedBytesForPendingRequests）。然而，由于WebKit的边解析边显示机制和JavaScript的复杂性，导致未处理请求数（numPendingOrLoadingRequests）估算偏低，进而影响进度显示，造成用户体验不佳。因此，提出需要对现有算法进行微调，以优化复杂网页的加载体验。
常用手机浏览器的人都会注意到，在加载网页时会有这样的现象：
1. 若网页非常简单，则进度条会在开始跳几下，然后直接跳到最后
2. 若网页非常复杂，则进度条会卡在约90%的位置很久，而加载不完。
特别是后者造成了非常差的用户体验，因为这时候用户不知道网页是否还在加载，是否还在工作。
这些现象都是由WebKit内部的加载进度算法造成的，该算法在ProgressTracker类中，关于这个类，这篇文章有很好的说明，这里就不再重复了。
进度更新是由网络部分触发的，当网络部分收到一个报文，就会向上要求更新进度，并且将该报文的长度（bytesReceived） 传递上去，作为一个重要参数。
算法其实很简单，初始值设为10%，最大值设为90%。这就是为什么打开网页后，进度会直接跳出一块，而又有很多复杂网页卡在90%的原因了。
中间这块进度的计算是通过一个简单的数学式：
progressValue += (maxprogressValue - progressValue )*(bytesReceived / remainingBytes)
progressValue 是当前进度，maxprogressValue 是最大进度，即90%。 bytesReceived 本次收到的字节数。remainingBytes剩余的总字节数，这个值是估算出来的，其估算的是否准确直接决定了算法的成败。
此计算式虽然简单，但它保证了
最低0.47元/天 解锁文章
407
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
