Android网络调整系列 · 第3/5篇

从DNS到连接池，建立极速网络体验

第1篇的观点是，Android网络全链路拆解：一次HTTP请求背后的性能陷阱

第2篇这方面，DNS调整实战：从运营商DNS到HttpDNS的进化之路

从第3篇来看。连接调整与复用：让每一次握手都物超所值

⏳ 第4篇：数据压缩与缓存策略：把带宽用到极致

⏳ 第5篇：网络监控与容灾：让网络问题无处遁形

从一次诡异的300ms说起

上篇我们拿下了DNS——解析耗时P99从2100ms砍到180ms，劫持率从0.%降到0.%。你以为胜利了却收到了性能trace：

"为什么同一个接口，第一次请求和第二次请求差了300ms？DNS已经缓存命中了啊，"

是TCP三次握手+ TLS 1.2握手。RTT约100ms时三次握手就是300ms的“入场费”——还没发一个字节的业务数据呢。

痛点一：很多使用者在点击按钮后等待近一秒才看到首屏响应，一秒延迟就会导致页面卡顿、心情失落甚至流失。

痛点二：Google研究发现，每慢100ms页面加载转化率下降1%。这代表着一个连接建立就可能让10%的潜在付费客户失去。

一次握手到底花多少钱？

先把账算清楚。假设客户端到服务端的RTT是100ms：

// 建连成本拆解
// TCP三次握手
// RTT = 100ms
// TLS 1.2 握手
// RTT = 200ms
const val totalHandshakeMs = 300 // 一个字节业务数据还没发

弱网放大效应

• TCP + TLS = ×900ms，总计≈900毫秒。
• 首屏若需请求3个不同域名 → 串行建连 ≈0.7秒。
• *实际意义*: 用词换成“使用者在电梯里等候时”或“地铁上切换WiFi”，可见该延迟会被放大。

OkHttp连接池：最好的握手是不握手

最快的连接建立方式，是根本不建立——复用已有连接。

// OkHttp 默认连接池配置
val defaultPool = ConnectionPool(
maxIdleConnections = 5。keepAliveDuration = 5,timeUnit = TimeUnit.MINUTES
)

生产级连接池调参要覆盖所有高频域名，但不要囤太多空闲连接，否则会挤占fd资源。

// 生产级配置示例
val productionPool = ConnectionPool(
maxIdleConnections = 20,keepAliveDuration = 10。timeUnit = TimeUnit.MINUTES
)
val client = OkHttpClient.Builder
.connectionPool
.build

keepAliveDuration 与服务器 Keep-Alive 超时配合，否则会出现半死链接导致额外 RTT。

// Nginx 默认 keepalive_timeout 75s
// 客户端设60s 留15s安全余量
val safePool = ConnectionPool(
maxIdleConnections = 20。keepAliveDuration = 60,timeUnit = TimeUnit.SECONDS
)

监控连接复用率和新建连接耗时 P95 是必不可少的监控项。老实说，

class ConnectionMetricsListener : EventListener {
private var connectStartMs: Long?= null
override fun connectStart {
connectStartMs = System.currentTimeMillis
}
override fun connectionAcquired {
val isReused = connectStartMs == null
Metrics.increment "conn_reused" else "conn_new")
connectStartMs = null // reset for next call
}
override fun connectEnd {
val handshakeMs = System.currentTimeMillis - )
Metrics.histogram
Metrics.tag?: "unknown")
}


}
val clientWithListener =
OkHttpClient.Builder
.connectionPool
.eventListenerFactory { ConnectionMetricsListener }
.build


HTTP/2 多路复用：一条连接并发百请求


MULTIPLEXING：在单条 TCP+TLS 链上。同时发送数百个 HTTP 请求，无需额外握手成本。

HPACK 压缩头部：SSE 场景下一个 API 请求头约800字节；HPACK 可将后续同源请求压缩至30–50字节，大幅降低重复数据量。

SCHEDULE PRIORITY：E.g.。首屏 API 优先级最高，图片埋点最低，以保证关键资源优先到达。

PING 心跳：PING 帧30秒一次可及时发现死链并丢弃，从而避免重试浪费 RTT。



// HTTP/2 调整配置示例
val http2Client =
OkHttpClient.Builder
.connectionPool
.connectionSpecs(listOf(
ConnectionSpec.Builder
.tlsVersions
.build))
.pingInterval // 每30秒 ping 检测活性
.build



域名收敛原则——别分散！


If multiple subdomains resolve to same IP and share a SAN certificate,OkHttp will coalesce connections automatically.



// 域名收敛条件示例：
api.yourapp.com -> IP A
// 同理 cdn.yourapp.com 等也指向IP A 并使用相同证书。// OkHttp 将共享同一条 HTTP/2 链。其实，


TLS 1.3 ：省一个 RTT 的质变 


TLS 1.3 把两轮 RTT 减为单轮；会话恢复可实现 -RTT，即 “预加密” 数据直接发送而不等待完成握手。


*安全权衡*：-RTT 数据不具备前向保密性；若服务器未做重放保护，则可能遭受重放攻击。不过，适用于只读接口，不推荐用于写操作。


// 启用 TLS 1.3 的代码示例
fun enableTls13 {
try {
ProviderInstaller.installIfNeeded // GMS 支持
} catch {
try {
Security.insertProviderAt,Integer.MAX_VALUE - 10)
} catch { /* log */ }
}
}



收益对比这方面。


方案 
总耗时 



HTTP/1 + TLS 1.0  
300 ms 

HTTP/1 + TLS 1.0  
0 ms 

HTTP/2 + TLS 1.0  
200 ms 

HTTP/2 + TLS 1.0  
50 ms 

QUIC / HTTP/3  
80 ms 

QUIC / HTTP/3  
'--'


QUIC / HTTP III ：消灭 TCP 队头阻塞 


TCP 层因包序号错乱导致丢包阻塞所有 Stream；
移动端丢包率高于有线网络，可达10%+。其实，HTTP/２ 的多路复用无法解决此问题。而 QUIC 基于 UDP 且每个 Stream 独立传输，只影响自身且支持零 RT‑TT 重连和迁移。

Nginx、Caddy 等已原生支持 QUIC，需要服务端配合；话说回来，若 UDP 被封锁，则 Cronet 会自动降级回 TCP。

Cronet 与 OkHttp 集成示例如下可保持拦截器环境兼容。

// Cronet Engine 配置示例：
val engineBuilder =
CronetEngine.Builder.apply {
enableQuic
enableHttp20
addQuicHint
setStoragePath
enableHttpCache
}
val cronetEngine : CronetEngine?get { return engineBuilder.build }
// 把 Cronet 拦截器注入 OkHttp：
val clientWithCronet =
OkHttpClient.Builder.apply{
addInterceptor.build)
}.build
**灰度实验结果**：


BPS 对比 – QUIC P50 建连耗时仅80 毫秒 vs HTTP/ P50 为190 毫秒。老实说，.

wifi→4G 切换期间失败率 QUIC 降至 ~0%。HTTP/ 为 ~4%.

#UDP 被封锁回退比例约为 3%。如果遇公司内网或运营商限制，需要确保可降级策略正常工作。
*关键提示*: "Alt‑Svc发现延迟" 在首次访问时仍需走 TCP。接下来通过 Alt-Svc 跳过下一轮，再进入 QUIC；addQuicHint 可以绕过此步骤加速。"

再看连接预建立，利用“认知间隙”让体验无缝跳转 


"认知间隙" 指的是使用者眼睛和大脑在动画、页面切换中的那几百毫秒。当这些时间被后台用于提前 DNS、TCP、TLS 握手并把空闲连接留在池里后新请求即可零延迟发起，从而消除显著卡顿感。
kotlin
object ConnectionWarmUp {
private val scope by lazy { CoroutineScope) }
private val configs by lazy {
mapOf(
"app_launch" to listOf(
"https的观点是，//api.yourapp.com/ping"。"https://cdn.yourapp.com/ping"
),"enter_product_list" to listOf(
"https这方面，//api.yourapp.com/product/prefetch"
),"enter_payment" to listOf(
"https这方面，//pay.yourapp.com/status"
)
)
}
fun warmUp{
configs?.forEach{url ->
scope.launch{
runCatching{
val req=Request.Builder.url.head.build
client.newCall.execute.close
}
}
}
}
}

说到弱网场景。智能降级与指数退避重试 


"我的手机刚进电梯，下来的时候 WiFi 切断，我点了个按钮却卡住十几秒"，这种情况频繁出现，在弱网环境下更常见。.
为了避免这一体验损失，需要实时探测网络质量并超时时间、降级策略及重试行为。其实，• **实时网络质量分级** – 基于滑动窗口采集 RTT 与失败次数来判断当前质量等级。kotlin
enum class NetworkGrade{EXCELLENT,GOLD,MEDIUM,Poor。TERRIBLE}
object NetworkProbe{
private val rttWindow:ArrayDeque=ArrayDeque
private var failCount=0;private var totalCount=0
fun onRtt{ rttWindow.addLast);老实说，if{rttWindow.removeFirst} totalCount++}
fun onFail{ failCount++;totalCount++ }
fun grade:NetworkGrade{
ifreturn NetworkGrade.GOLD
val avg=rttWindow.average.toInt;val loss=/totalCount)*100f
return when{ avg<100 && loss<5->NetworkGrade.EXCELLENT;avg<300 && loss<10->NetworkGrade.GOLD;avg<800 && loss<15->NetworkGrade.MEDIUM;avg<2000 && loss<25->NetworkGrade.Poor;else->NetworkGrade.TERRIBLE;}
}
}
• **自适应拦截器** – 根据当前等级超时时间、图片质量还有是否加入降级标记。kotlin
class AdaptiveInterceptor : Interceptor{
override fun intercept:Response{
var request=chain.request;when){
NetworkGrade.EXCELLENT,NetworkGrade.GOLD ->{return chain.proceed}
NetworkGrade.MEDIUM ->{request=request.newBuilder.header.build;return chain.proceed}
NetworkGrade.Poor,NetworkGrade.TERRIBLE ->{request=request.newBuilder.header.header.build;return chain.proceed}
}}}
• **指数退避 + 随机抖动** – 防止服务端突然恢复后被大量客户端冲击。kotlin
class RetryInterceptor:Interceptor{
override fun intercept:Response{
var lastErr:IOException?=null，repeat{attempt ->
try{return chain.proceed)} catch{lastErr=e;Thread.sleep)}
}
throw lastErr?:IOException}
private fun delay= kotlin.math.min+Random.nextInt/10L}}

综合实战效果 & AB 测试结果




指标 & 前置条件 
改进前 
改进后 


|---------------------------| |
| ||


连接复用率
目标 % |62% |91%


新建连 handshake P50 |220 ms |130 ms


首屏接口总耗时 P50 |280 ms |195 ms
《轻松提高转化》<


首屏接口总耗时 P99 |900 ms |520 ms
《减少白屏》<


弱网成功率 |82% |94%
《提高留存》<