《移动游戏产品的架构·客户端与移动运行时》序：为什么移动游戏需要一本产品架构书

一个真实的分歧

拾光工作室的「潮汐」IP 同时跑着两款产品。《潮汐消消》是休闲三消，《潮汐方舟》是卡牌策略 RPG。它们在同一个账号体系下登录，共用同一套支付通道和活动配置平台，甚至共用同一批运营同学。上线第一年，团队很自然地想让方舟复用消消的客户端框架——既然都是「移动游戏客户端」，为什么不能复用？

复用到第三个月，问题集中爆发，而且没有一个能靠「换个引擎 API」解决：

• 消消 90 秒一局，玩家随时切后台、随时被杀进程是常态；方舟一场战斗 8–12 分钟，战斗中途断线重连要恢复到「同一回合同一手牌」，两者的状态保存策略根本不是一个量级。
• 消消 35% 的玩家在 4GB 以下的低端机上，稳态内存基线 420MB；方舟只有 15% 低端机，但稳态内存 1,150MB。同一套资源缓存策略，在一款产品上是节省，在另一款产品上是卡死。
• 消消首包 120MB，安装即玩是它的转化命门；方舟首包 350MB、总资源 1.8GB，装完还要下载。两者对「首帧时间」的容忍度差了一倍以上。
• 消消崩溃率 0.18% 已经算健康，方舟 0.12% 却更危险，因为它单场的沉没成本高得多，一次战斗崩溃换来的是一整场进度和一次差评。

这些分歧的答案不在引擎文档里，也不在服务端架构书里。它们属于同一类问题：在明确的移动端约束下，客户端应该由哪些部分组成、各部分之间怎么依赖、出问题时先牺牲什么。

这本书就是为这一类问题写的。

引擎之外，架构之内

市面上不缺两类书：一类教你怎么用引擎做出一个能跑的游戏，另一类讲服务端怎么扛住百万在线。但一个移动游戏团队真正每天在拍板的问题，大多落在这两类书的中间地带：

这些问题有一个共同点：**它们的正确答案是一条边界，而不是一个功能。**边界划错了，加多少代码都在补窟窿；边界划对了，实现甚至可以换引擎重写而不改结构。

本书把这类边界称作「产品架构」。它不讨论某个渲染管线怎么调，也不讨论战斗同步算法怎么写，只讨论在内存、电量、发热、网络、机型五条移动端约束下，客户端各层之间应该怎样切分、怎样依赖、怎样验收。

这本书拒绝写什么

写架构书最容易滑向两种失败：一种是把别人的文档复述一遍，另一种是假装所有决策都有唯一正确答案。为了避免这两种失败，本书有几条明确的禁区：

• 不写引擎教程。 引擎在本书里是一个叫 Host 的接口，负责提供渲染、音频、资源加载、原生能力。引擎怎么实现不关心，客户端在引擎之上怎么组织才关心。想深入引擎内部，可以读站内的《Cocos 游戏开发》和《游戏引擎实现原理》。
• 不写服务端拓扑与同步算法。 只写客户端在网络契约里的责任：什么状态归服务端权威、断线后客户端该信谁、离线队列能排多久。服务端的部分指向《游戏服务端架构》和《MMO 服务器开发》。
• 不写品类数值与经济系统。 三消的关卡难度曲线、卡牌的战力公式，是产品设计的领域，不是客户端架构的领域。
• 不写小游戏平台能力。 原生 Android / iOS 与渠道包，和小游戏/H5 的发布模型是两件事，后者已有《小游戏开发实战》覆盖。
• 不把案例数字写成实测。 本书使用一组完整的案例设定值，用来演练口径和决策。它们是设定，不是某台设备的跑分；任何需要真机才能得出的结论，书里都会明说「这里只是模型」。

两条产品线，一套判断方法

本书的案例不是虚构的玩具工程。拾光工作室的两款产品构成了一组刻意的对照：

它们共享账号、支付、活动、数据与发行中台，却在客户端层、玩法内核、资源包、热更节奏、性能预算和发布窗口上完全隔离。**共享什么、隔离什么，本身就是架构决策。**书中每一节都会指定一个主案例，另一个案例只在关键分歧处作对照——不是为了展示「两种做法都行」，而是为了让你看见同一个决策在不同约束下会得出不同答案。

这组对照还带来一个额外好处：它逼着书里每个结论都必须写成带条件的判断。「应该做资源引用计数」是空话；「引用计数在 1,150MB 稳态内存的方舟上必须配合水位告警，在 420MB 的消消上必须先保证低端机不抖」才是可执行的判断。

四卷的位置

《移动游戏产品的架构》规划四卷，从客户端一路排到平台治理：

你手里的这一卷是卷一《客户端与移动运行时》，共 13 章 39 节，外加序、前言、目录和三篇附录。它故意不谈变现，也不谈发行，因为一个连冷启动、恢复和内存水位都没定清楚的客户端，谈商业化只会把问题放大。

卷一的章节顺序不是知识点的罗列，而是一条判断链：

1. 先看清问题（第 1 章，双案例与约束清单）；
2. 再切结构（第 2–3 章，分层与引擎/壳边界）；
3. 然后处理运行时（第 4–5 章，生命周期与配置）；
4. 接着管资源与交互（第 6–8 章，内存、UI、设备输入）；
5. 再进入计量（第 9–12 章，帧率功耗、存档、区域化、可观测性）；
6. 最后收口成基线（第 13 章，双案例客户端基线）。

每一章三节，节与节之间存在依赖：跳过第 4 章直接读第 10 章，你会看到一堆「恢复」「回滚」的结论，却不知道它们依赖哪一套生命周期假设。这也是我建议第一次按顺序读的原因。

关于代码

卷一附带一个可运行的实验工程 mga-lab：TypeScript 编写，Node 26.5.0 原生类型剥离，零第三方依赖，用 node --test 跑测试。正文里每一段带 // file: 头的代码块，都能在实验工程里逐字节找到对应文件。

需要说明的是这个工程能做什么、不能做什么：

• 能真实运行：分层依赖检查、生命周期状态机、恢复令牌合并、配置 schema 与迁移、资源依赖图、内存预算、UI 栈与弹窗仲裁、手势状态机、帧预算与温控档位、存档合并、Intl 时区换算、埋点采样、三消与卡牌的确定性回放。
• 只能建模：原生桥接（用 Host 接口加 mock）、崩溃与 ANR 采集（事件 schema 与采样规则）、渲染（无头布局模型）、传感器、渠道支付广告适配器。

凡属于第二类的，正文都会明确写出「这里是模型，不是设备实测」。读到这类段落时，请把它当作结构示范，而不是性能结论。真机上的数字，永远要自己在目标机型上跑。

写给谁

这本书假设你满足三个前提中的至少两个：

• 做过至少一个移动端项目，知道冷启动、切后台、弱网、机型分档在真实设备上意味着什么；
• 能读懂接口、状态机和依赖图，愿意把架构规则写成可执行的断言；
• 正在或即将为「不止一款产品」负责客户端，需要一套能跨产品复用的判断方法。

如果你只想要「三消关卡的数值怎么做」，这本书会让你失望；如果你正卡在「两款产品能不能共用一套客户端框架」「低端机到底该牺牲画质还是牺牲帧率」这类没有标准答案的问题上，这本书的结构应该能直接用。

一个提醒

架构书最危险的读法是把它当成标准答案。本书给出的每一个决策都带着前提：DAU 规模、机型分布、包体预算、联网形态、收入结构。前提变了，结论就应该重算——这正是第 13 章要你把双案例基线写成可复核表格的原因。

书里的判断可以抄，前提不能抄。先确认你的产品站在哪组约束里，再决定采用哪条边界。