每次车从隧道出来，导航总要“愣”几秒才能重新定位、重新拉路况，很多人把这归结为“信号不好”。但作为搞移动端网络优化的人，我心里清楚，这背后其实是 DNS 解析失效、连接重建、请求超时重试、数据包排队这一连串问题在排队爆发。用户不管你是哪一层出了问题，他们只记得“导航卡了一下”。
高德 APP 这样的地图应用，网络优化和普通工具类 App 完全不是一个量级。普通 App 的请求大多是用户主动刷出来的，地图应用却是用户在高速移动中、在信号忽强忽弱的环境里、在一秒钟内可能发出几十个请求的场景下使用。我在这条链路上踩了不少坑，也沉淀了一些切实有效的优化手段，这篇文章就把从 DNS 到弱网的全链路优化思路完整梳理一遍。无论你是在做移动端基础组件，还是单纯对这个话题感兴趣，都可以参考这里的实践经验。
1. 导航场景下的网络全貌：为什么通用优化手段不够用
1.1 移动网络环境比想象中更恶劣
很多做后端优化的同学对网络的认知还停留在“机房到机房”的模型：网络是相对稳定的，延迟主要在跨地域链路上。但移动端完全不是这么回事，尤其是地图导航场景。
一次典型的地图请求，链路是这样的：蜂窝基站或者 Wi-Fi 路由器 → 运营商网关 → 公网骨干 → CDN 或者源站服务器，然后原路返回。这中间任何一段出现抖动，用户体感就会出问题。更麻烦的是，移动端用户的位置是持续变化的，相当于一直在不同的基站之间切换，每一次切换都可能伴随 IP 地址变化、TCP 连接断开、DNS 缓存失效。
高德这种应用还有几个邻人头疼的数据特征：
- 突发请求量极高：手指滑动地图，一秒钟内可能触发二三十个瓦片图片请求，请求还都是小而碎的类型。
- 网络环境割裂：地下车库、隧道、高架桥下、地铁车厢、电梯里，这些场景的信号衰减路径完全不同，没有一套固定参数能适配所有情况。
- 实时性要求苛刻：路径规划晚一秒返回，车就可能开错一个路口；路况数据晚十秒到达，用户看到的可能就是过期信息。
我经常举一个例子：信号满格和网络好用之间，有时候隔着一整条街。移动网络里，信号强度（RSRP）只代表接收功率，不代表数据传输速率。你可能在某个商场地下一层看到手机信号满格，但实际丢包率高达 30%，因为周围全是承重墙带来的多径干扰。用“信号好不好”来判断网络质量，是用户层面最直观的理解，但工程上必须拆得更细。
1.2 用户体感与网络指标的复杂对应关系
网络优化做久了会有一个共识：技术指标好不好，和用户觉得好不好用，中间没有绝对的对等关系。用户不会看你的 DNS 解析耗时降低了多少毫秒，他们只会在意两件事：内容出来得快不快，以及有没有出现中断、白屏、转圈。
但工程上又必须用指标来驱动优化。我们内部把用户可感知的问题拆成几类：
- 找路慢：请求发出去，迟迟等不到响应，对应的是连接失败、超时、重试。
- 图片糊：瓦片加载不出来，地图区域是灰的，对应的是图片请求被阻塞或超时。
- 卡顿：交互没有响应，对应的是主线程被网络回调阻塞，或者数据包排队导致 CPU 大量消耗在序列化和解压上。
- 完全不可用：对应的是本地网络完全断开、DNS 解析彻底失败、服务器拒绝服务。
所以全链路优化的目标，从来不是追求单一指标最优，而是把整条链路的“坑”都填平，保证用户在最差的环境下，也能至少完成核心任务。后面所有优化手段，都是围绕这个目标展开的。
2. DNS 解析优化：把找 IP 的第一跳握在自己手里
2.1 传统 DNS 在移动端的三大顽疾
DNS 是网络请求的第一步，但也是长期被忽视的一步。在移动端，传统 DNS 解析暴露出来的问题比桌面端和服务器端严重得多。
第一个问题是解析慢。运营商 LocalDNS 有自己的缓存策略，命中缓存时可能只要几毫秒，但一旦缓存未命中，就要递归查询上级 DNS 服务器，耗时可能攀升到几百毫秒甚至数秒。最麻烦的是，这个耗时完全不可控，你无法预判这次请求是快是慢。在地图场景里，用户从隧道出来的一瞬间需要立刻恢复定位数据，DNS 慢了两秒，界面就转两秒的圈。
第二个问题是内容被劫持或污染。这种情况在不同网络环境下有过不同程度的体现：部分公网 Wi-Fi 会篡改 DNS 响应，把域名解析到错误 IP；有些网络还会在解析失败时直接给你返回一个广告页面。对地图应用来说，域名被劫持的后果不只是打不开页面，而是导航数据被替换、位置请求被拦截，属于直接可感知的严重故障。
第三个问题是调度失灵。传统 DNS 是按“发起请求的出口 IP”来调度流量的。但手机在移动网络下处于运营商 NAT 之后，LocalDNS 看到的是出口网关的 IP，不是用户真实所在的位置。这就导致明明用户在上海，内容调度却把他导到了北京的节点。地图瓦片、路况数据的加载延迟因此凭空多出几十毫秒。
2.2 HTTPDNS 方案：客户端主动出击
解决上述问题的主流方案是 HTTPDNS。核心思路很简单：客户端不再走系统默认的 LocalDNS 解析流程，而是直接通过 HTTP 接口，向专门的 DNS 服务端请求域名对应的 IP。
高德这种体量的应用，HTTPDNS 基本是标配了。具体接入时的逻辑是这样的：
- App 启动时，从配置中心拉取 HTTPDNS 服务商的地址列表。
- 需要解析域名时，直接向这个 HTTP 接口发起请求，携带 App 标识、用户所在网络类型、经纬度等信息。
- 服务端综合用户位置、运营商、服务可用性，返回一组排序好的 IP 地址和各自的 TTL。
- 客户端拿到结果后，缓存到内存和本地存储中，后续请求直接使用这些 IP。
这里有个容易踩坑的点：很多团队第一次接入 HTTPDNS 时，只是把域名解析换成了 HTTP 请求，但缓存策略还是沿用系统 DNS 的逻辑，结果收益不大。HTTPDNS 的核心优势不只是“解析快”，而是“结果可定制”。你可以根据自己的业务特点调整 TTL 长短、IP 排序权重、甚至指定某个特殊区域的用户走特定节点。这个能力才是它价值的真正体现。
2.3 缓存、预取与降级：DNS 的容灾设计
DNS 优化不能只盯着“解析过程”，客户端这侧的缓存和降级策略同样关键。
我在实际项目中建立的缓存体系分三层：
- 内存缓存：TTL 设置为 60 到 120 秒，保证短时间内高频请求不重复走 HTTPDNS 接口。
- 本地持久化：上次解析成功的记录会写入本地文件，App 冷启动时直接读取，不等网络请求返回就能发起业务请求。
- 网络切换触发刷新：从 Wi-Fi 切到蜂窝网络、或者从 4G 切换到 5G 时，主动清除当前缓存并重新解析。因为不同网络路径下，最优的接入节点可能完全不同。
预取机制的收益也很大。地图上可能有几十个需要访问的域名，但冷启动时不可能全部预解析，否则浪费流量和电量。我们的做法是根据用户进入的页面和即将发起的请求，动态计算“接下来一分钟内最可能用到的域名列表”，提前 30 秒左右发起异步解析。
最后是降级策略。HTTPDNS 服务商本身也可能出故障，必须准备好 Plan B。我们设置的降级路径是：主 HTTPDNS → 备用 HTTPDNS → 系统 LocalDNS。这个降级不是简单的“请求失败就换”，而是有一个失败置顶机制：连续多次解析失败的域名自动切换到备选通道，同时上报监控，方便后续排查。
注意：降级到系统 LocalDNS 时，要同时关闭本地持久化缓存，避免把之前 HTTPDNS 的结果和系统解析结果混用。两个不同来源的 IP 对全局调度秩序的影响，是实测中比较容易忽视的坑。
2.4 解析结果的 IP 质量排序
HTTPDNS 返回的 IP 不是随机的，服务端会按照调度策略排序，但客户端不能盲信这个顺序。
我们的做法是：在客户端做“IP 质量打分”。每个 IP 根据历史请求的成功率、连接耗时、首包耗时计算一个质量分，优先使用分数最高的 IP。如果某个 IP 连续失败超过阈值，自动把它拉入惩罚列表，短时间内不再使用。这个机制在弱网环境下特别有用——服务端调度的信息再全，也不如客户端在真实网络里踩出来的数据准确。
DNS 这层优化做完之后，解析耗时整体下降很明显，但真正让用户感知到变化的，是把解析和后续的连接建立作为一个整体来协同优化，这就到了下一层。
3. 连接建立优化：每一层通信协议都在省一个 RTT
3.1 TCP 细节：从 Nagle 算法到 KeepAlive
DNS 拿到 IP 之后，下一步是建立 TCP 连接。一个 TCP 连接从客户端发起 SYN 到最终建立，至少要一个 RTT（三次握手的前两次）。在正常网络下这一个 RTT 也就几十毫秒，但在弱网环境下可能膨胀到几秒。这一层的优化核心，是“减少不必要的连接新建”和“让现有的连接更高效”。
TCP 层面有几个容易被忽略的细节。第一个是TCP_NODELAY选项。默认情况下，TCP 会启用 Nagle 算法，把小包积攒起来一并发送，这在传输大量数据时能提高吞吐，但在地图这种需要发小请求、立即拿响应的场景就会增加延迟。我们会确保所有对时延敏感的业务请求都开启TCP_NODELAY，让每个小包立即发送，不等下一批数据凑齐。
第二个是 KeepAlive 参数的调整。系统默认的 TCP KeepAlive 探测间隔是 2 小时，这个值对移动端来说太长了。想想这个场景：用户开着导航进了电梯，网络短暂断开再恢复时，App 还在使用之前那条已经死掉的连接，请求全都超时。我们把 KeepAlive 探测间隔缩短到 5 分钟级别，同时配合客户端主动的空闲探活机制，快速识别并回收死连接。
3.2 TLS 握手：从 2-RTT 到 0-RTT
现在的移动端流量基本都是 HTTPS，TLS 握手在连接建立后还要额外消耗 1 到 2 个 RTT。这一层加密是有代价的，尤其对地图这种高频请求场景。
TLS 1.2 时代，握手需要一个完整往返拿到服务器证书，再加上密钥协商，差不多 2 个 RTT。TLS 1.3 把握手压缩到了 1 个 RTT，还支持 0-RTT 会话恢复——客户端如果之前和服务器通信过，可以在第一个数据包里直接带上应用数据，省掉整个握手过程。
但 0-RTT 不是免费的午餐。它存在重放攻击风险，客户端离线打包发送的数据可能被恶意第三方截获后重放。所以我们的策略是分级使用：只有幂等、无副作用的请求（比如路况查询）才开 0-RTT，涉及账户信息的请求老老实实走完整的 TLS 1.3 握手。
还有一个容易被忽视的细节是证书链。有些服务端的证书链包含多级中间证书，每次握手都需要把整个证书链传给客户端，弱网下这个传输耗时可能畸形地放大。我们的做法是精简证书链，确保服务端只下发必要的证书层级，同时启用 OCSP Stapling，把证书有效性查询的结果由服务器直接附带在握手阶段，避免客户端再去额外访问 OCSP 服务器。OCSP 服务器在弱网下经常连不上，这一步处理不好会拖垮整个握手的耗时。
3.3 HTTP/2 与连接池：能复用的资源绝不上路重造
HTTP/1.1 时代，浏览器和 App 的并发连接数都有限制，一个域名下建立的连接多了还会被服务端拒绝。地图应用的请求碎片化严重，如果每个请求都新建连接再关闭，光是握手开销就能让首屏时间翻倍。
升级到 HTTP/2 之后，连接复用和并发能力都大幅提升：
- 多路复用：一条长连接上可以同时跑多个请求，请求之间各自独立的 Stream 互不阻塞，解决了 HTTP/1.1 的队头阻塞问题。
- 头部压缩（HPACK）：地图请求的 Header 里有大量重复字段（User-Agent、Accept、Cookie 等），HPACK 把这些内容用索引替换，流量节省非常可观。
- 连接预算降低：原本一个页面要开二三十个连接，现在一个域名基本维持一条长连接就够了，对弱网场景意义重大。
连接池的设计上，我们坚持两个原则。第一，核心域名连接预建立：冷启动时 App 会预判用户最先访问的域名，提前建立好连接，等用户开始操作时直接发请求。第二，空闲连接不过度保留：长连接虽然好，但移动网络下的连接生命周期比带宽充足的光线网络要短得多。我们会设置一个合理的空闲超时值，超过这个时间就主动关闭，避免为了省一次握手而占着一个可能已经半死的连接。
经验补充：连接池的大小不是越大越好。每个连接在客户端和服务端都要占用内存和端口资源，连接数太多反而可能触发系统的资源保护机制。在实际调优中，单个域名的连接池维持在 2 到 4 条是多数场景的合理区间，具体数值根据请求并发模型压测后确定。
4. 弱网请求治理：超时、重试与压缩的平衡艺术
4.1 场景化超时：一刀切的超时时间是最差设计
弱网环境下的请求治理，第一个要解决的问题是“等多久才算失败”。很多团队习惯配置一个全局超时时间，比如 10 秒，所有请求统一执行。这种一刀切的设计问题很大。
地图场景的请求天然分轻重缓急。路径规划是用户当下的核心任务，等 10 秒用户可能还在忍受范围里；但如果一个瓦片图片请求等了 10 秒才失败，用户早就滑到别的地方去了。所以我们的超时设计是分级的：
- 交互级请求（瓦片加载、路况刷新、关键词联想）：超时时间 3 到 5 秒，快速失败让用户重新操作，宁可慢一点也不要一直转圈。
- 核心任务请求（路径规划、路线详情、导航起终点确认）：超时时间放宽到 8 到 10 秒，给业务足够的时间在弱网下努力一把。
- 后台静默请求（预加载、缓存刷新）：超时时间最长，但配合低优先级调度，不影响用户正在执行的操作。
这套策略运行一段时间后，我们又加了一个动态调节维度：根据当前网络的实测质量自动调整超时。网络质量好的时候，把超时缩短，避免失败请求拖太久；网络质量差的时候，反而要适当延长超时，因为这个时候重试的成本比重试等待更高。动态调节的依据来自客户端持续采集的网络质量分，而不是简单的信号强度。
4.2 重试策略：幂等、退避与网络兜底
超时之后一般伴随重试，但重试设计不好，往往会放大问题。我见过最典型的反面案例：线上某个接口偶发超时，客户端统一在 1 秒后重试，结果瞬时流量翻倍，把服务端直接打崩，原本偶发的超时变成了系统性超时。
安全的重试策略要满足几个条件：
第一，请求必须幂等。GET、HEAD、PUT 这类请求天然幂等，重试没有副作用。POST 请求要加幂等键，服务端根据这个键识别是否为同一个业务请求，保证重复发送不会导致重复下单、重复上报这类问题。
第二，重试要有退避和抖动。固定间隔重试会导致客户端之间同步共振。我们的默认策略是 1 秒、2 秒、4 秒的指数退避，并在每次重试之间加上随机抖动。最大重试次数控制在 3 次以内，再多的重试只是浪费电量和带宽。
第三，换网络重试是最高性价比的手段。弱网环境下，很多请求失败是因为当前网络本身不可用，重试再多次也不会成功。正确的做法是监听网络切换事件，从 Wi-Fi 切到蜂窝网络、或者从 4G 切换到 5G 时，把这些在途的失败请求主动重发一次。实测下来，这个策略的成功率提升非常可观，远高于同网络下的多次重试。
4.3 数据瘦身：从 JSON 到 Protobuf 到增量更新
网络请求的响应体大小，直接决定弱网下的传输时间。这一点上，我们做了三层收敛。
第一层是格式升级。客户端和服务端的通信协议从 JSON 逐步迁到了 Protobuf。同样一个路径规划结果，JSON 序列化后可能 200KB，Protobuf 大概 40KB，体积相差 5 倍左右。再加上压缩算法从 gzip 切到 Brotli（在支持的环境下），响应体的传输时间能压缩接近八成。这里要注意：Protobuf 在移动端的解析性能也远好于 JSON，对 CPU 资源和内存占用都是一次正优化。
第二层是数据裁剪。地图场景有很多点到点的数据，服务端会按需返回。比如路况详情，正常网络下返回精细到路段的实时速度，弱网下则返回粗粒度的畅通/缓行/拥堵三色信息。数据量小了，用户反而更容易看懂当前路况。信息降级不是功能倒退，而是根据网络条件动态适配信息服务形态。
第三层是增量更新。地图基础数据有很强的静态属性，没必要每次全量拉取。我们建立了增量更新机制：客户端记录本地数据版本号，请求时带上版本号，服务端只返回变更的部分。地图瓦片也类似，相同层级的瓦片做过哈希指纹对比，内容没变就直接复用本地缓存，不再传输重复数据。
4.4 弱网测试怎么做才算靠谱
优化做得好不好，不能靠玄学，要靠可控的弱网测试环境。常用的工具是 iOS 的 Network Link Conditioner、Android 下的 adb 网络限速、PC 端的 Charles 和 Fiddler。Fiddler 的弱网模拟功能很适合前后端联调阶段快速验证，但它的模拟粒度偏粗，一般只能设置固定的延迟和带宽值。
真正靠谱的弱网测试，要覆盖三类混合场景，而不是简单地把延迟调大：
- 高延迟：模拟 RTT 200ms 到 1000ms 的链路，测试超时逻辑和用户等待体验。
- 高丢包：模拟 5% 到 30% 的丢包率，测试 TCP 重传和请求重试的效果。这一步能暴露很多在理想网络下根本不会出现的问题。
- 带宽受限：模拟 30Kbps 到 200Kbps 的低带宽，测试数据压缩和大包拆分策略。
高德在内部搭建的弱网测试环境，会把这些参数组合成不同的“弱网等级”，从轻度劣化到完全不可用分为多档，每一档对应一套客户端预期表现。每次网络优化版本上线前，所有核心业务都必须跑一遍全档位的弱网测试，不达预期不允许发布。
5. 地图数据请求的专项优化：瓦片、路况与分级调度
5.1 地图瓦片加载：预加载和双层缓存是命根子
地图瓦片是地图应用最典型、也是量最大的请求类型。一张瓦片是一张 256×256 像素的小图片，常见体积在 10KB 到 50KB 之间。用户缩放、平移一次地图，可能需要加载几十张瓦片。瓦片请求的体验好坏，直接决定地图的“跟手程度”。
瓦片优化的核心，我总结为三个关键词：分级预加载、内存缓存、磁盘缓存。
分级预加载的逻辑是：用户看到当前视野时，App 除了加载当前层级的瓦片，还会预测用户下一步可能缩放到的层级，提前把低一级和高一级的部分瓦片拉下来缓存。这个预测不是猜，而是根据手势方向、地图中心点移动速度、当前缩放级别建立的模型。比如用户在地图上快速向上滑动，系统会预加载上方区域的瓦片；用户双击某个点进行放大，系统会提前加载目标层级中心附近的瓦片。
内存缓存用的是 LRU 策略，最近使用的瓦片常驻内存，保证用户来回拖动地图时能秒级复用。内存缓存的容量要控制好，太大会挤压其他业务的内存空间，太小则命中率上不去。这块的调优是一个持续的平衡过程，我的经验是按单张瓦片平均 20KB 估算，内存缓存设置在 50 到 80MB 范围，基本能覆盖核心城市一个区域的高频回看需求。
磁盘缓存主要解决冷启动后首次打开地图的加载问题。地图瓦片有很强的时效性（道路会变、楼宇会变），磁盘缓存不能无限期保留。我们的策略是分区管理：基础底图数据缓存周期长（比如 7 天），动态标注数据缓存周期短（比如 1 天）。缓存命中后要异步验证版本，发现内容过期再重新拉取，而不是先等验证再显示。
5.2 路况数据的时效性与降级方案
路况是地图应用里比较特殊的请求：数据量不大，但对时效性要求极高。一条路况信息超过 5 分钟基本就失去参考价值了。正常网络下，路况请求是轻量高频的，30 秒刷新一次。
弱网下，路况刷新就会遇到矛盾：刷新太频繁，请求发不出去；刷新太慢，用户看到的是过期路况。我们最终采用的方案是“自适应刷新间隔”，网络质量好的时候 15 秒刷一次，网络变差时自动拉长到 60 秒一次。同时，在弱网下自动切换为粗粒度路况请求，只拉取用户当前路线前后几公里的路况概要，不再拉全城路况。
当然，路况数据的传输方式也值得考虑。基于长连接的推送，在弱网环境下其实不如“短轮询+缓存兜底”稳定。长连接在丢包环境下频繁断开重连，开销反而更大。我们的实践是：存续的网络连接上使用推送，断线时自动回退到定时轮询，保证用户始终能拿到至少一份可用的路况数据。
5.3 请求优先级调度：把最关键的请求插到最前面
地图请求的特点是并发度极高、类型复杂。试想一个典型场景：用户在导航过程中，屏幕上同时需要路况刷新、语音包下载、实时位置上传、路口放大图请求、ETC 记录上报。如果不做优先级调度，带宽和连接资源会被大量非关键请求占用，直接拖累导航主流程。
我们建立了一套客户端请求调度系统，核心逻辑是：所有网络请求在发出前，先经过一个优先级队列。
- P0 级：用户正在进行的核心操作请求，比如一次点击“开始导航”后触发的路径规划。
- P1 级：支撑当前界面显示的必要请求，比如正在浏览区域的瓦片图、导航中下一路口的示意图。
- P2 级：前体验较好的增强请求，比如周边餐饮 POI、路况详情报。
- P3 级：后台预取和上报类任务，比如本地数据增量更新、日志上传。
调度器会根据当前网络质量动态调整各级请求的并发配额。网络好的时候，P2、P3 级请求可以并行跑；弱网环境下，直接砍掉 P3，限制 P2，把大部分带宽和连接资源留给 P0 和 P1。这套机制上线后，弱网导航场景的卡顿明显减少，因为“关键请求等不到资源”的基本矛盾解决了。
6. 监控、告警与持续迭代：把优化建立在数据之上
6.1 客户端网络指标采集：不只看平均，更要看分位数
所有优化上线后，都要有数据来验证效果，否则就是拍脑袋。我们在客户端埋了一套网络监控指标，覆盖全链路的每个步骤。
取样的指标包括：
- DNS 耗时：分成功和失败统计，记录解析耗时分布。
- 连接建立耗时：TCP 握手时间、TLS 握手时间分别记录，方便定位是网络问题还是证书问题。
- 首包时间（TTFB）：请求发出到收到响应第一个字节的时间，这个指标最能直接反映用户等待感受。
- 请求完成率：按不同弱网等级统计，重点看 4G 弱覆盖和 Wi-Fi 高干扰场景下的表现。
- 客户端错误分布：超时、连接重置、DNS 解析失败、TLS 握手失败等错误类型分别统计。
这里有一个很容易犯的统计误区：只看平均耗时。平均耗时会被极端值拉偏，线上某个弱网场景的请求 30 秒才超时，平均下来所有请求的耗时都被拉高了，但实际上 95% 的请求都很快。我们的监控报表核心看 P50、P90、P95、P99 四个分位，以及错误率。弱网优化做得好不好，看 P95 比看平均数可靠得多。
6.2 上行归因和灰度验证
指标采集只是第一步，归因才是关键。用户在哪个城市、用的哪家运营商、连的 4G 还是 5G、当时网络质量几分、App 版本是多少——这些信息要和网络指标一起上报，才能在问题发生时快速定位。比如某个版本上线后，上海电信用户的 DNS 解析成功率明显下降，如果监控只看到“DNS 失败率升高”而没有细分维度，排查起来会非常痛苦。
灰度发布也是网络优化必须遵守的流程。网络相关的改动，风险往往比业务功能改动更隐蔽——它受环境影响大，同一个改动在办公网下表现很好，到了弱网环境可能完全是另一回事。所以我们的节奏是：配置中心动态下发，首批 5% 白名单用户验证核心指标无劣化，再逐步放量到 30%、100%。这个放量过程一般需要 2 到 3 个自然日，不是技术婆婆妈妈，而是留够时间观察长尾场景的网络表现。
6.3 实际调优中容易被忽略的细节
最后分享几个自己在项目里被反复磨炼出来的细节，这些写在标准文档里都容易被跳过：
千万不要高估客户端的本地时间。埋点数据里的时间戳，最好由服务器在响应头里下发时间校准，否则客户端本地时间乱了，所有耗时分析都没有参考意义。
日志上报要有采样率。全量上报网络日志，流量消耗反而是个问题。我们的策略是：正常网络下 5% 采样，弱网或请求失败时 100% 采样。这样监控覆盖和流量成本能形成一个相对合理的平衡。
网络优化和服务端优化必须联动。有段时间我们盯客户端调优，怎么调首包时间都压不下来，后来排查发现是服务端业务逻辑里有一个耗时的同步调用，纯粹拖了响应后腿。客户端把问题定位到了，还要推动服务端一起改。全链路优化，链路两端的配合不能少。
别忘了“无网”场景。弱网优化做得再细，也要给离线场景留好退路。高德离线地图的存在本身就是一种网络优化思路——与其在弱网环境下挣扎，不如把一部分数据直接搬进用户手机。实际导航过程中，离线数据和在线数据的无缝切换，用户是感知不到的，但体验差异巨大。
做了这么多年移动端网络优化，我最大的体会是：网络问题永远不会被彻底消灭。你优化了 DNS，还会遇到连接被重置；你优化了连接池，还会遇到链路丢包；你优化了超时重试，还会遇到服务端抖动。真正让用户觉得“这个 App 网络挺好的”，不是因为你解决了一切问题，而是因为在任何糟糕的网络条件下，用户的核心任务总是能完成。哪怕慢一点，哪怕图像质量低一点，只要用户还能被带到目的地，这场优化就算赢了一半。这些经验希望能给正在做网络优化的你一些参考，尤其是里面的超时分级、弱网降级、优先级调度这几个思路，换个业务场景同样适用。
开发指南)
