串行请求对首屏加载时间的定量分析模型
在首屏加载过程中,若多个网络请求以串行方式执行,则会引入显著的排队延迟。本章建立严格的定量分析模型,推导首屏时间公式,量化串行数对加载速度的影响,并通过关系图直观呈现。
首屏时间公式
定义关键变量:
- RTT:单次请求往返延迟(Round-Trip Time),单位为 ms
- P:首批并行请求数量(受浏览器并发限制,通常为 6)
- N:串行阶段内的请求总数
- Trender:首帧渲染与资源解析耗时
在经典的“首屏瀑布模型”中:
首屏时间 = 最大并行阶段耗时 + 串行阶段总耗时 + 首帧渲染耗时
其中:
最大并行阶段耗时 = max(所有并行请求的 RTT)
串行阶段总耗时 = (N / P) × avg(RTT) —— 当 N > P 时,剩余请求进入串行排队
若所有请求必须完全串行(P=1),则公式简化为:
首屏时间 = N × avg(RTT) + T_render
示例计算:
avg(RTT) = 200ms, T_render = 150ms
串行请求数 N = 8 → 首屏时间 = 8 × 200 + 150 = 1750ms
若使用并发 P=6,则首屏时间 ≈ max(RTT)? + ceil(8/6) × 200 + 150 ≈ 200 + 400 + 150 = 750ms
avg(RTT) = 200ms, T_render = 150ms
串行请求数 N = 8 → 首屏时间 = 8 × 200 + 150 = 1750ms
若使用并发 P=6,则首屏时间 ≈ max(RTT)? + ceil(8/6) × 200 + 150 ≈ 200 + 400 + 150 = 750ms
请求排队延迟
串行请求会引入明确的“排队队列”。假设每个请求完成后才发起下一个请求,则第 k 个请求的完成时间为:
T_k = T_0 + Σ_{i=1}^{k} (RTT_i + 处理_i)
其中 T_0 为第一个请求开始时间,处理_i 为服务端处理耗时
实际排队延迟可细分为:
- DNS 排队:串行 DNS 查询累积
- TCP 连接排队:每次建立连接等待握手
- TLS 协商排队:HTTPS 场景下的证书验证串行化
- HTTP 请求/响应排队:应用层数据传输排队
注意: Android 平台下若使用 OkHttp 默认连接池,同一域名最多支持 5 个并发连接。超过后自动排队,但若同时有多个域名请求,串行效应会体现在 DNS 与连接复用失败上。
串行数与首屏时间关系图
以下 SVG 图展示了固定 RTT=200ms 条件下,不同串行请求数量对应的首屏加载时间(假设无并行)。同时对比了理想并发场景(P=6)的实际收益。
公式与表格汇总
| 串行数 N | 串行耗时 (ms) | 并行 P=6 耗时 (ms) | 排队延迟差 (ms) |
|---|---|---|---|
| 1 | 350 | 350 | 0 |
| 2 | 550 | 350 | 200 |
| 4 | 950 | 550 | 400 |
| 6 | 1350 | 350 | 1000 |
| 8 | 1750 | 550 | 1200 |
| 10 | 2150 | 750 | 1400 |
| 12 | 2550 | 750 | 1800 |
结论:串行请求数量 N 每增加 1,首屏时间近似线性增长(斜率 = avg(RTT))。当 N ≥ 6 时,串行方案的首屏时间将超过 1 秒,用户体验显著劣化。优化核心在于利用 Retrofit + OkHttp 连接池,将串行请求转换为合并接口或并发执行。