课程导论：为什么启动阶段 OkHttp 容易超时崩溃
我做了这么多年 Android 性能优化，最让我头疼的问题之一，就是启动阶段的网络请求。尤其是用了 OkHttp 之后，线上时不时冒出一个 ConnectTimeoutException 或 SocketTimeoutException。你说它难吧，倒也不难；但每次定位都要翻遍各种日志，最后发现——嗯，其实都是那几个老问题。
这一章，我们就来聊聊“为什么”。只有搞清楚病根，后面的调试技巧才有意义。
启动阶段的“黑暗三秒”
App 冷启动的时候，系统在干什么？
- 加载 Application 类、初始化各种 SDK
- 主线程空闲前要处理很多同步任务
- 网络模块刚初始化，连接池还是空的
- DNS 可能还没缓存，要首次查询
- 线程池里的线程可能正在被其他组件抢占
说白了，这三秒里系统非常“脆弱”。你想想看，一个请求发出去，要经历 DNS 解析、TCP 三次握手、TLS 协商（如果用了 HTTPS）——每一步都可能比平时慢好几倍。而 OkHttp 默认的超时时间是 10 秒，看似很宽裕，但在这些环节叠加起来后，10 秒其实也没那么保险。
OkHttp 的默认超时配置
我猜很多人做项目时直接 new OkHttpClient() 什么都没配。来，看看默认值：
OkHttpClient client = new OkHttpClient.Builder()
.connectTimeout(10, TimeUnit.SECONDS)
.readTimeout(10, TimeUnit.SECONDS)
.writeTimeout(10, TimeUnit.SECONDS)
.build();这三个 10 秒，在正常网络下够用。但启动阶段不一样——
- connectTimeout：包括 DNS 解析 + TCP 连接 + TLS 握手。弱网下 DNS 可能花 3~5 秒，TCP 再重试几轮，10 秒就用完了。
- readTimeout / writeTimeout：如果服务端在启动时还没准备好（比如网关限流），读超时也会触发。
我在项目中遇到过，有一次线上崩溃全是 readTimeout，查下来发现是后端网关在启动时段做了慢启动预热，前几秒故意延迟响应。OkHttp 等不及，直接抛异常，导致 Activity 启动时发生未捕获崩溃。
隐藏在表象下的根因
你以为只是超时配置太短？其实背后至少有三个层面的原因：
1. 网络层面
- DNS 解析慢：首次解析要查远程 DNS，运营商 DNS 有时很慢，甚至返回劫持 IP，连接失败。
- TCP 连接建立慢：移动网络下，空口调度延迟高，一个 RTT 可能几百毫秒，加上重试，很容易达到阈值。
- SSL 协商：HTTPS 需要证书验证、密钥交换，多出 2~3 个 RTT。
2. 客户端资源层面
- 连接池未预热：刚启动时连接池里一条连接都没有，每个请求都要新建连接。
- 线程池竞争：OkHttp 内部使用 dispatcher 线程池，如果主线程或其他组件占用了很多线程，请求可能排队等待。
3. 业务层配置问题
- 重试机制缺失：很多团队没有自定义重试，一次超时就放弃，后续关键接口依赖失败导致崩溃。
- 超时设得太短：为了“用户体验”把超时改成 5 秒，结果在 4.5G 弱网下频繁超时。
典型崩溃场景一览
我把常见的崩溃场景整理了一下，你对照着看看项目中遇到过哪些：
| 场景 | 表现 | 根因 |
|---|---|---|
| 首次启动冷启动 | 请求超时，界面白屏 | DNS 未缓存 + 连接池空 |
| 弱网（电梯/车库） | ConnectTimeoutException | TCP 握手 RTT 过长 |
| 多请求并发 | readTimeout | 线程池排队 + 服务端延迟 |
| 代理/热点切换 | SocketException | 网络瞬间不可用，OkHttp 未及时感知 |
| 自定义超时过短 | 频繁超时崩溃 | 没考虑启动阶段额外延迟 |
为什么常规调试手段失效？
很多人遇到崩溃，第一反应是看 Logcat。但 OkHttp 的日志在启动阶段可能被其他日志淹没，而且超时异常往往被包装成 IOException，不仔细看堆栈很难发现是哪个环节超时。
- 默认日志不打印 DNS 耗时：你只知道连接超时，但不知道是 DNS 还是 TCP。
- 堆栈没有线程调度信息：你很难判断是不是因为线程池打满导致请求排队。
- 用户复现难：启动阶段超时往往低频出现，自己测试很难触发。
所以，我们需要更精准的调试手段——比如自定义 EventListener、网络拦截器、慢日志监控等。这些后面的章节会详细展开。
小结：越复杂，越要系统看
启动阶段 OkHttp 超时崩溃，说白了就是一个“多因素叠加”的问题。网络慢一点、连接池空一点、配置不合理一点，单独看都不致命，但加在一起就崩了。我建议你在做启动优化时，先把这三大类的根因印在脑子里，调试时才能一眼看穿。