3. 启动阶段网络请求的特殊性：主线程阻塞、冷启动DNS缓存

启动阶段的网络请求，说白了就是“夹缝中求生”。App刚起来，各种初始化任务堆成山，主线程忙得像个陀螺。这时候你的OkHttp请求哪怕只慢几百毫秒，都可能被系统判定超时。我踩过不少这种坑，今天就把两个最典型的“杀手”拎出来聊透。

主线程阻塞：超时判定的隐形加速器

你想想，OkHttp的超时机制依赖什么？依赖定时器和后台线程。但冷启动阶段主线程有可能被Activity启动、ContentProvider加载、插件注册等操作塞满。一旦主线程卡住几秒钟，OkHttp内部的超时检测线程虽然还在跑，但Android系统对超时回调的调度可能会延迟——再加上主线程本身如果抢占了太多CPU时间，连okhttp的连接池清理任务都可能被推迟。

我自己遇到过最典型的场景：冷启动时在主线程调了一个同步网络请求。明明OkHttp设置了5秒超时，结果足足等了8秒才抛TimeoutException。为什么？因为主线程忙着渲染首屏，线程调度的优先级被压低了，超时检测的Runnable没及时被派发。

冷启动DNS缓存：解析慢一拍，超时就来了

另一个容易被忽略的点是DNS缓存。App刚安装完、冷启动时，系统DNS缓存是空的。首次解析某个域名，需要走完整的UDP查询、可能还有递归。国内有些公共DNS响应不稳定，经常要200ms~1s。而OkHttp默认的连接超时通常只有10秒，看起来够用？但别忘了，DNS解析是发生在连接建立阶段的，如果解析耗时长，再加上TLS握手、网络延迟，很容易就把连接超时窗口给填满了。

我曾经遇到一个线上崩溃：用户反馈冷启动后立马崩溃。查日志发现是OkHttp抛了SocketTimeoutException，但网络请求本身很简单。最终定位到——用户所在地区DNS服务器不稳定，冷启动首次解析耗时3秒多，加上TLS握手2秒，直接撞了5秒的连接超时阈值。

如何排查：先确认是不是主线程阻塞

做法很简单——在超时发生的地方，打印出当前线程名和堆栈。如果看到“main”线程，而且堆栈里是Activity.onCreate之类的，那就八九不离十了。

// 在超时回调中打印线程信息
call.enqueue(new Callback() {
    @Override
    public void onFailure(@NonNull Call call, @NonNull IOException e) {
        Log.d("TimeoutDebug", "当前线程: " + Thread.currentThread().getName());
        // 如果输出 "main"，就是主线程问题
    }
});

如何排查：DNS解析耗时检测

可以用adb命令模拟冷启动后的首次DNS查询，或者直接加一行测试代码：

// 冷启动后立即执行
long start = System.nanoTime();
InetAddress.getByName("your-api.com");
long cost = (System.nanoTime() - start) / 1_000_000;
Log.d("DNS", "首次DNS解析耗时: " + cost + "ms");

如果耗时超过500ms，就得考虑做本地DNS预解析了。

两个问题的本质：资源竞争 + 缓存缺失

最后总结一下：启动阶段网络请求超时，核心原因就两点——主线程阻塞让超时检测变慢，以及冷启动DNS缓存缺失让连接建立变慢。两个问题叠加，很容易触发OkHttp的超时逻辑。你只要把这两条线守住了，启动崩溃率能降一大截。