串行请求对首屏加载时间的定量分析模型

在首屏加载过程中,若多个网络请求以串行方式执行,则会引入显著的排队延迟。本章建立严格的定量分析模型,推导首屏时间公式,量化串行数对加载速度的影响,并通过关系图直观呈现。

首屏时间公式

定义关键变量:

  • 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

请求排队延迟

串行请求会引入明确的“排队队列”。假设每个请求完成后才发起下一个请求,则第 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)的实际收益。

串行请求数量 vs 首屏加载时间 (RTT=200ms, T_render=150ms) 串行请求数量 N 首屏加载时间 (ms) 0 2 4 6 8 10 12 0 500 1000 1500 2000 串行 (P=1) 理想并行 (P=6) 🔍 串行每增加1个请求,首屏时间线性增加约200ms 并行场景下:前6个请求并发完成,后续请求开始排队 N=12时串行首屏时间2450ms vs 并行700ms

公式与表格汇总

串行数 N串行耗时 (ms)并行 P=6 耗时 (ms)排队延迟差 (ms)
13503500
2550350200
4950550400
613503501000
817505501200
1021507501400
1225507501800
结论:串行请求数量 N 每增加 1,首屏时间近似线性增长(斜率 = avg(RTT))。当 N ≥ 6 时,串行方案的首屏时间将超过 1 秒,用户体验显著劣化。优化核心在于利用 Retrofit + OkHttp 连接池,将串行请求转换为合并接口或并发执行。