Android设备WIFI连接时API响应慢波动大问题排查咨询

基础对照测试（先锁问题边界） #

• 用adb连接出问题的Android设备，进入shell环境连续ping目标Azure App Service域名20次以上，统计丢包率、RTT波动范围，再用自带的curl命令发起和App内参数完全一致的API请求，单独统计耗时：
  • 如果curl请求同样存在2-8秒的波动，问题出在系统网络栈、WIFI环境或公网链路层
  • 如果curl请求稳定在1秒左右，问题出在App自身的网络库配置
• 把办公WIFI的AP频段固定为2.4G/5G分别测试，部分小型定制Android设备的WIFI天线抗干扰能力弱，办公环境多AP重叠、同频干扰严重时，空口帧重传会直接带来大幅延迟波动，以太网不存在空口干扰问题所以表现稳定。
• 临时关闭办公WIFI的SSL深度检测、应用层防火墙、未知设备QoS限流规则测试：企业WIFI通常会给加入域的笔记本设备加白名单，跳过流量检测步骤，未备案的定制Android设备流量会被逐包检测，很容易产生秒级转发延迟。

Android系统侧配置排查 #

• 检查WIFI连接的高级设置，确认是否存在自动下发的代理、异常DNS配置：定制Android系统在WIFI环境下经常默认优先使用运营商公共DNS，容易出现Azure节点解析漂移、跨区调度的问题，可手动将WIFI的DNS改为1.1.1.1或Azure权威DNS后测试解析稳定性。
• 关闭WIFI省电模式：小型Android设备默认会开启WIFI低功耗策略，无持续流量时WIFI模块进入休眠，每次发起请求前需要先唤醒硬件，会产生1-5秒不等的额外延迟，可通过adb执行settings put global wifi_sleep_policy 2关闭WIFI休眠策略后测试。
• 临时关闭系统级VPN、私有DNS、网络加速类功能，这类功能会对所有流量做中间转发，在WIFI环境下的转发性能普遍低于以太网口。

Retrofit/OkHttp配置排查 #

• 优先排查IPv6兼容性问题：绝大多数办公WIFI会下发IPv6地址但未配置可用的IPv6公网出口，OkHttp默认优先尝试IPv6连接，等待连接超时后才会回退到IPv4，整个回退过程刚好会产生2-7秒的延迟，和你描述的波动范围完全吻合。这是Android设备WIFI环境下API延迟波动的最高频诱因之一。可通过自定义OkHttp的DNS解析逻辑，强制优先返回IPv4地址测试，参考配置：

val okHttpClient = OkHttpClient.Builder()
    .dns { hostname ->
        InetAddress.getAllByName(hostname).filterIsInstance<Inet4Address>()
    }
    .build()

• 检查连接池配置：WIFI环境下AP、出口网关的NAT会话超时时间通常比以太网环境短，如果OkHttp连接池保活时间设置过长，会出现复用已被NAT设备丢弃的死连接的问题，需要重新完成TCP握手、TLS握手，在有干扰的WIFI环境下这类握手流程很容易出现秒级延迟，可适当调短连接池保活时间、开启TCP keepalive探测。
• 临时强制使用HTTP/1.1协议测试：部分企业WIFI的应用网关对HTTP/2、QUIC协议的帧处理存在兼容性问题，会引发请求重传、队头阻塞，导致延迟波动。

Azure服务侧排查 #

• 开启App Service的端到端请求日志，对比以太网来源、WIFI来源的请求在服务端的实际处理耗时：
  • 如果两类请求的服务端处理耗时一致，说明延迟全部产生在传输链路或客户端侧，回到前面的排查项即可
  • 如果WIFI来源的请求到达服务端的时间本身就存在明显延迟，说明存在公网路由调度问题，可通过配置接入加速节点优化链路
• 临时将App Service的最低TLS版本调整为TLS 1.2测试，部分老旧的Android WIFI模块对TLS 1.3握手的兼容性较差，容易引发握手阶段的耗时波动。

内容的提问来源于stack exchange，提问作者sjohansson