上线之后，架构才开始被检验
卷一讨论的是客户端内部的秩序：分层、生命周期、资源句柄、帧预算、存档与可观测性。这些决定了一款产品「能不能稳定地跑起来」。
但玩家真正抱怨的问题，很少出自这些地方。上线后最常见的四类反馈是：
- 「打着打着就掉线，回来什么都变了。」
- 「更新完进不去，卡在加载 99%。」
- 「流量怎么这么大，一局就没了 20MB。」
- 「新版本把我的手机烫得厉害，还特别卡。」
四条里有三条直接落在网络与资源上。它们不是客户端内部某一行代码写错了，而是客户端与服务端之间、客户端与分发系统之间的契约没有设计好。
下限由交付链路决定
一个团队可以花半年把渲染管线优化到极致，却可能因为一次 45MB 的热更包下载失败，让 8% 的用户停在旧版本；也可以把架构图画得很漂亮，却因为重连后没有校准状态，让玩家在战斗里看到两个不同的血量。
这类问题的共同点是：它们不在任何单个模块的职责范围内。
- 协议兼容不是客户端一个人的事，但客户端是唯一能挡住不兼容消息的地方。
- 重连不是网络库一个人的事，但客户端必须定义「什么叫恢复完成」。
- 热更不是运维一个人的事，但客户端必须保证「更新失败还能回到可用状态」。
卷二要讲的，就是这些跨边界的能力怎么落到客户端的代码与流程里。
四个基本立场
本书对网络与资源有四个明确立场，它们会贯穿全卷：
第一，客户端不拥有权威，但拥有契约。 货币、奖励、战斗结果归服务端；客户端负责把契约写清楚：哪些字段必须校验、哪些版本必须拒绝、哪些状态必须重新拉取。
第二，网络不是「能通就行」，而是有分布的质量。 RTT 的 P95、弱网会话占比、断线率、重连成功率，这些数字决定了产品要设计多少兜底，而不是靠一句「加个重试」。
第三，资源不是美术交付物，而是产品结构。 资源怎么分组、首包放什么、分包多大、什么时候下载，直接决定首启流失、流量成本和热更频率。
第四，任何更新都必须可回滚。 不能回滚的热更，等于把线上当测试环境。灰度、差量、回滚不是发布流程的三个可选项，而是一套动作的三个环节。
为什么三件事放在一卷
网络、资源、热更看起来是三件事，实际上是一条链：
- 资源决定客户端需要向服务端和 CDN 要什么；
- 网络决定这些请求以什么节奏、在多差的链路上完成；
- 热更决定更新后的资源与配置如何安全地替换旧版本。
把三者拆开写，最容易出现的情况是：网络章节假设资源已经就位，资源章节假设下载永远成功，热更章节假设版本永远一致。三者放在一卷，才能讨论那些跨环节的事故——例如热更包下载失败后，客户端还能不能回到可用状态；例如弱网下按需下载超时，战斗是否应该开始。
这也是本卷章节顺序的理由：先讲连接与协议（第 1–3 章），再讲离线与同步（第 4–6 章），然后算流量（第 7 章），再进入资源与分包（第 8–9 章），最后是热更、灰度与 CDN（第 10–12 章），第 13 章收口。
与卷一的关系
卷二不重复卷一的内容，但每一章都能在卷一找到落点：
| 卷一的能力 | 卷二如何使用 |
|---|---|
| 分层与模块边界 | 网络层只暴露契约，不把协议细节泄进玩法层 |
| 生命周期与恢复 | 重连与前后台切换共用同一套状态机 |
| 资源句柄与内存 | 分包与按需下载决定资源何时进入内存 |
| 存档与云存档 | 离线队列与云存档共同处理冲突 |
| 可观测性 | 网络与下载指标进入同一套埋点与告警 |
如果卷一的结论还没有落地，卷二的方法会变成一堆无法验证的流程。序言里先说清楚这一点：卷二不是卷一的替代，而是卷一在真实链路上的延伸。
双案例的分工
《潮汐消消》是弱联网产品：单局 90 秒，主要为登录、云存档、活动与内购联网。它的网络问题集中在弱网、切后台与流量成本。
《潮汐方舟》是强联网产品：8–12 分钟一场战斗，服务端 10Hz 快照。它的网络问题集中在重连、状态校准、战报一致性与热更频率。
两款产品共用一套发行中台，却对网络与资源提出了完全不同的要求。这种对照会反复出现，因为同一套架构在不同联网形态下，优先级是相反的。
读完这一卷能做什么
- 能为一款移动游戏写出协议兼容规则，并把它变成可执行的契约测试。
- 能设计连接状态机、退避策略与重连后的状态校准流程。
- 能界定离线队列的边界，处理幂等、去重与冲突。
- 能算清一次会话的流量构成，给出流量预算与弱网适配方案。
- 能画出资源依赖图，决定首包、分包与按需下载的边界。
- 能说清商店政策允许热更什么、红线在哪里、失败如何回滚。
- 能把差量、灰度与版本收敛串成一条可观测的发布流水线。
一个提醒
本卷的案例数字用于演练判断口径，不是线上实测。读的时候请关注「为什么这样定」，而不是记住「RTT 是 240ms」。换成你自己的产品，先把附录 B 的表格填一遍，再看正文的规则是否还成立；不成立的地方，就是你产品真正的架构问题。
最后一句
网络与资源是移动产品最容易「看起来没问题」的部分：办公室里 Wi-Fi 稳定、测试机干净、资源包 freshly built。真正的架构能力，要到弱网、低端机、灰度发布和热更失败的时候才显形。
卷二的目标，是让这些时刻有预案，而不是有惊喜。预案不保证事故不发生，但能把事故从「不可解释」变成「可定位、可回滚、可复盘」。这也是本书愿意花一整卷讨论网络与资源的原因：它们决定的是产品的下限，而下限决定玩家会不会留下来。
继续阅读
探索更多技术文章
浏览归档，发现更多关于系统设计、工具链和工程实践的内容。