这是 2021 年 1 月的客户端工程笔记，十篇文章可以看成两张问题清单。第一张是启动链路：玩家从点图标到进大厅，中间要过登录状态机、资源清单、场景切换、弱网重试四道关，任何一道没设计好，表现都是「卡在 90%」或者「弹窗连成串」。第二张是战斗手感：输入缓冲、动画事件管线、技能表现编排，决定了玩家按下去的那一下到底有没有被接住。
除了这两张清单，还有两篇偏性能的文章：内存水位和长列表虚拟化。它们讨论的是同一件事——客户端里最贵的资源是时间和内存，而这两样东西通常在项目中期才开始被认真对待，那时改造成本已经很高。建议把这十篇当作「客户端体检表」，逐条对照自己的项目打分。
这批笔记的写作方式很一致：先描述一个线上或测试期真实现象，再解释它为什么不是「偶发」，最后给出工程上可执行的边界与检查项。所以它更适合当工具书翻，而不是当教程从头读到尾。
专题速览
| 维度 | 说明 |
|---|---|
| 文章数量 | 10 篇 |
| 时间范围 | 2021 年 1 月 |
| 主题分布 | 启动与资源 4 篇、战斗与表现 3 篇、性能与界面 2 篇、运营开关 1 篇 |
| 面向读者 | 客户端主程、战斗程序、性能优化工程师、客户端测试 |
| 阅读价值 | 把线上高频故障整理成可逐条自查的工程清单 |
| 难度 | 以工程实践为主，少量架构层面的取舍讨论 |
| 前置知识 | 需要了解客户端基本的资源加载、UI 框架与网络层抽象 |
本月问题地图
把这十篇放在一起看，会发现它们覆盖了客户端最常被投诉的几个方向。下表给出「玩家感受」和「工程根因」的对应关系，方便你从现象反查文章。
| 玩家感受 | 工程根因 | 对应文章 |
|---|---|---|
| 卡在 90% 不动 | 加载阶段不可解释、进度是假的 | 场景切换、资源清单 |
| 登录时弹窗连成串 | 登录链路没有统一状态机 | 登录状态机 |
| 点了没反应、黏手 | 输入没有缓冲与优先级 | 输入缓冲 |
| 技能伤害晚了半拍 | 动画事件被当成业务总线 | 动画事件管线、技能表现编排 |
| 玩半小时闪退 | 内存没有水位线与分级回收 | 内存水位 |
| 背包越滑越卡 | 长列表没有虚拟化 | 长列表优化 |
| 弱网下状态错乱 | 请求没有队列与幂等 | 离线与重试 |
| 开关互相覆盖 | 灰度规则散落在代码与配置 | 灰度开关 |
启动与资源链路
启动链路是玩家对游戏的第一印象，也是客户端最容易出事故的地方。这一组文章的共同结论是：登录、资源、场景、网络这四件事不能各自为政，必须有一套统一的失败与恢复语义。登录失败要能区分「凭证失效」「排队中」「服务器维护」「网络不通」，资源更新失败要能断点续传并校验完整性，场景加载失败要能回退到安全场景而不是卡死，弱网重试要能在不重复扣道具的前提下收敛请求。
| 文章 | 核心内容 |
|---|---|
| 游戏客户端登录状态机：别让一次重连变成一串弹窗 | 把登录链路拆成明确状态与迁移条件，避免账号 SDK、渠道包、排队、公告各自弹窗互相打架 |
| 游戏客户端资源清单：版本号、依赖和回滚要一起设计 | 资源清单不只是下载列表，还要回答版本归属、依赖关系、校验值、可选性和回滚能力 |
| 游戏客户端场景切换：读条不是遮羞布 | 读条的可信感来自进度真实、阶段可解释、失败可重试，而不是把加载时间藏起来 |
| 游戏客户端离线与重试：不要让按钮点击变成请求风暴 | 弱网下的重复点击需要用请求队列与幂等语义收敛，而不是靠禁用按钮硬扛 |
这一组建议按「登录状态机 → 资源清单 → 场景切换 → 离线重试」的顺序读，因为它们的依赖关系正好是玩家实际经历的顺序。读完这四篇，你应该能画出一张完整的启动时序图，并标出每一段的超时、重试与兜底策略。
战斗手感与表现编排
手感是客户端里最难量化、也最容易被低估的部分。这三篇分别从输入、动画和表现编排三个层次切入，合起来构成一次技能释放的完整生命周期：玩家按下按键，输入系统决定这一下是否被缓冲、缓冲多久、在哪个窗口执行；动画系统播放对应轨道，并在关键帧抛出事件；表现编排层把事件翻译成镜头、特效、震动、音效和伤害数字。
| 文章 | 核心内容 |
|---|---|
| 动作游戏客户端输入缓冲：手感来自被认真处理的几十毫秒 | 输入缓冲窗口、优先级排序与动画窗口执行时机，决定了「黏手」和「按了没反应」的观感 |
| 游戏客户端动画事件管线：别把伤害、音效和特效都塞进帧回调 | 动画事件被当成业务总线后必然失控，需要把伤害、音效、特效、镜头拆成独立可编排的轨道 |
| 游戏客户端技能表现编排：一次大招背后的镜头、特效和命中反馈 | 一次大招是输入、动画、镜头、震动、音效、命中表现的精密编排，缺一环玩家就觉得不对 |
性能与界面
性能问题里最尴尬的一类，是「开发机很顺、线上很卡」。这两篇分别从内存和 UI 两个角度解释这种落差：内存问题往往在切场景、开界面反复累积后才爆发，UI 问题则在列表项数量上升后从「能滑」变成「掉帧」。
| 文章 | 核心内容 |
|---|---|
| 移动游戏客户端内存水位：不要等系统杀进程才开始优化 | 建立内存水位线与分级回收策略，把闪退和后台被回收变成可预测、可预防的问题 |
| 游戏客户端长列表优化：背包、邮件和排行榜为什么越滑越卡 | 背包、邮件、排行榜是 UI 性能的试金石，虚拟化、对象复用与增量刷新是基本盘 |
运营开关与兜底
| 文章 | 核心内容 |
|---|---|
| 游戏客户端灰度开关：活动、实验和兜底都需要同一套规则 | 临时 if 会随活动数量失控，开关需要统一的配置来源、优先级、默认值与生效范围 |
开关看似是运营需求，实际是客户端架构问题。当开关散落在代码、配置、服务端和渠道包里时，没有人能回答「当前这个玩家到底开了哪些开关」。这一篇给出的做法是把开关收敛到一套带优先级和默认值的规则系统，并让开关状态可被诊断面板读取。
关键结论速记
- 启动链路需要一个显式状态机，而不是一串回调，否则失败分支会指数增长。
- 资源清单要能回答「这个文件属于哪个版本、依赖谁、能不能回滚」。
- 读条进度必须与真实工作挂钩，假进度比慢加载更伤信任。
- 弱网重试的前提是请求幂等，否则重试就是在制造事故。
- 输入缓冲窗口是手感的核心参数之一，值得单独配置与调优。
- 动画事件应当是可编排的轨道，而不是塞满业务逻辑的帧回调。
- 技能表现要分层：逻辑命中、表现播放、资源回收三者解耦。
- 内存优化要设水位线，按等级触发不同强度的回收。
- 长列表的性能上限由渲染节点数量决定，虚拟化是必选项。
- 灰度开关需要统一规则、优先级与默认值，不能临时加 if。
常见反模式
| 反模式 | 后果 |
|---|---|
| 用「重试按钮」代替状态机 | 玩家反复点击，状态越来越乱 |
| 把下载进度按文件数平均 | 大文件卡在最后，进度条失真 |
| 在动画帧回调里直接结算伤害 | 表现与逻辑耦合，改动画就改逻辑 |
| 靠禁用按钮防连点 | 网络恢复瞬间仍会并发，且体验差 |
| 内存只在低内存警告时才回收 | 系统杀进程时已来不及 |
| 列表每帧全量刷新 | 数量一多必然掉帧 |
| 开关直接写在客户端代码里 | 无法热更、无法灰度、无法审计 |
与其他月份的衔接
- 上接：本月的资源清单与离线重试，在 2021 年 2 月的首包范围与断点下载中得到延续。
- 下接：本月的输入缓冲与动画事件，为 2021 年 6 月的输入系统设计与动画状态机打下基础。
- 横向：登录状态机与服务端专题里的会话管理是同一个问题的两侧。
- 纵向：内存水位与 2021 年 6 月的内存泄漏排查构成完整的性能治理链条。
- 交叉：灰度开关这一篇的规则化思路，与 2021 年 6 月的运营配置安全是同一条演进线。
- 呼应：长列表优化与 2021 年 4 月的战令页面性能，都是「数量增长导致界面失控」的同一类问题。
推荐阅读路径
刚接手启动链路的同学：按「登录状态机 → 资源清单 → 场景切换 → 离线重试」顺序读，这四篇合起来就是一条完整的启动链路设计说明书。读的时候建议同步画出自己项目的启动时序图，对比差异。
战斗程序：先读输入缓冲，再读动画事件管线，最后读技能表现编排，顺序对应「输入 → 动画 → 表现」的实现层次。这三篇配合起来，能覆盖一次技能释放从按键到伤害数字的全部环节。
性能优化同学：内存水位和长列表优化两篇可以直接当检查表用，逐条对照当前项目的实现打分，先处理「有明确上限」的问题，再处理需要长期观测的问题。
版本管理与运营同学：灰度开关那一篇值得单独读，它解释了为什么开关不能临时加 if，以及开关失控的典型后果，对排期与回滚策略的设计同样有参考价值。
相关专题
- 游戏客户端专题导航：本月的笔记只是客户端大树的其中一枝，从这里可以看到全貌
- 2021 年 2 月客户端工程笔记：下个月继续讨论战斗 HUD、设备分档与时间线回放
- 游戏服务端专题导航：登录、重连、幂等这些客户端问题的服务端侧答案
- 游戏引擎专题导航：引擎能力决定了客户端在资源与渲染上还有多少优化空间