19 客户端架构与性能基础
本章目标：把「前端的事」讲成后端工程师能拿来做决策的知识。渲染、UI、动画、资源加载各有各的成本模型，性能会上门找你——「卡不卡」的争论里，后端经常是被怀疑对象。这一章不教你写渲染代码，只讲三件事：客户端的钱花在哪（预算表）、界面怎么承受网络的坏消息（三态交互）、性能出问题怎么分锅（归因分层）。平台与引擎的总体约束在第 03 讲已经铺过，本章往下钻一层。
参考书籍：渲染与引擎部分的成本口径参考各引擎官方性能文档（Unity Performance Optimization、Unreal Scalability 指南）；UI 与加载的工程实践参考《游戏引擎架构》（Jason Gregory）资源管理章节。
1. 渲染管线基础：帧时间是怎么花掉的
1.1 一次绘制的成本模型
每一帧的时间预算是固定的：60 帧率下 16.6 毫秒，30 帧率下 33.3 毫秒。这笔钱花在三个地方——逻辑更新（游戏脚本、物理）、渲染提交（CPU 准备并提交绘制命令）、GPU 执行（真正的像素与顶点计算）。渲染慢通常不是某一处"算得慢"，而是三处加起来超了预算。
服务端工程师最容易误解的是 Draw Call（DC）：它不是"画了多大一片画面"，而是 CPU 向 GPU 提交的一次绘制命令。画 1000 个同样的草，如果分 1000 次提交，就是 1000 个 DC——每一次提交都有固定的 CPU 开销（状态切换、命令缓冲写入），画面本身可能只占屏幕几个像素。所以低端机上真正的瓶颈经常是 CPU 提交侧而不是 GPU 算力：GPU 还没开始忙，CPU 已经在准备命令时把帧时间烧完了。
判断口径：
- DC 数量是第一个要看的预算项。移动端常见健康线在几百以内（低端机更紧），超线后加机器没有用——这是客户端单机内的问题，与服务器负载无关。
- 面数（三角形数）影响 GPU 顶点处理，贴图大小与格式影响显存与带宽。
- 这三项都写在项目的资源预算表里（每个角色多少面、每张贴图多大、单屏 DC 上限多少）——第 03 讲说过平台约束反向决定设计空间，预算表就是这份约束的具体形态。
1.2 合批与烘焙：把多次变少、把实时变离线
工程上对抗 DC 开销的手段是一族的，思路都是把 N 次提交合并成 1 次：
- 静态合批：不动的物体（建筑、地形装饰）启动时合并一次，运行时零额外成本，代价是内存与打包体积。
- 动态合批：每帧把小物体合并提交，CPU 反而要多干一遍活——只对顶点数极少的小物体划算，滥用会负优化。
- GPU Instancing（实例化）：同一份网格画很多份（草、树、子弹壳），一次提交画全部。大批量重复物体首选。
- SRP Batcher 一类管线级合批：按材质着色器兼容性合批，现代引擎的默认方向。
另一条思路是把实时计算搬到离线：光照烘焙把复杂光照预先算好存成贴图（Lightmap），运行时直接采样；遮挡剔除烘焙预先算好"什么能看见什么"。烘焙的本质与后端的缓存同构——用构建期的计算换运行时的预算，代价是"静态"：光源一动烘焙就作废，所以动态光永远不会被完全烘焙掉。
边界要说清：合批能省的是提交开销，省不了过高的面数与超分辨率贴图；烘焙能省光照，省不了动态阴影。任何一项手段都有它的适用面和反向代价，"开了合批所以随便画"和"没做缓存所以不能加缓存"是同一种错误。
1.3 LOD：远处的东西不配拥有细节
LOD（Level of Detail，多层次细节）指同一物体准备多档模型：近处用高模，远了自动切低模，再远切成公告板。这是对"屏幕上一个角色只占 20 像素却背着 5 万面"的浪费的直接回应。LOD 的切换距离与各档面数比，是资源管线的约定值，美术出资源时就要按档产出。
后端工程师需要从 LOD 类比里带走的东西：分层降级不是妥协，是容量设计。LOD、合批、烘焙、以及你在服务端做的降级采样、分级推送（第 11 讲好友状态合并推送），是同一个思想在不同层的投影——按观察距离/按需要给付细节。
1.4 后端工程师要拿走的三件事
- 要预算表：参与性能对齐时，先问客户端要资源预算表（单屏 DC、面数、贴图内存、包体大小），就像你要先看容量规划再谈扩容（压测口径见附录 A4）。
- 认得出假线索：「服务器卡」的玩家投诉，相当比例最后定位在客户端 DC 爆表、UI 重建风暴或资源加载阻塞（本章第 5 节的归因表）。
- 管住自己能管的：响应体积、下发数据量、推送频率——这些是服务端直接写进客户端帧时间的变量（第 4.4 节展开）。
2. UI/UX 工程：网络问题的第一现场
2.1 UI 框架层级与重建成本
现代引擎的 UI 都是层级树 + 每帧批处理渲染的模型（UGUI/NGUI/Unreal UMG 大同小异）：界面是嵌套的节点树，变化时引擎重算布局并重建绘制批次。关键的成本规律是：一个节点变化可能污染整棵合批——列表里一行字变了，整个 Canvas 的批次可能都要重建。所以成熟团队会按"变化频率"拆分 UI 画布：血条一个 Canvas、聊天一个 Canvas、静态面板一个 Canvas，让高频变化的影响范围圈死在自己那层。
判断：UI 卡顿的典型形状是"不连续的小刺"（每次刷新重建一批），而不是持续的高负载。看到帧时间曲线上周期性尖峰，先查 UI 刷新再查服务器。
2.2 事件穿透与射线检测
点击在引擎里是一次射线检测（从屏幕点向场景投射，问"打中了谁"）。两类常见事故：
- 透明图挡点击：一张盖满全屏的透明图（渐变遮罩、装饰层）开着射线检测，玩家点"什么都没有"的地方却没反应——因为点击被它吃掉了。
- 该挡的不挡：弹窗背后的 3D 场景仍然接收点击，玩家在弹窗边缘"点到"了场景里的角色。
规范是射线检测按需开关：纯展示节点一律关闭 Raycast Target；拦截层显式声明"我吃点击"。这看似纯客户端细节，但它解释了大量"我明明点了按钮"的客诉形态——归因时别急着查服务端日志。
2.3 界面与网络的三态交互
UI 是服务端延迟与错误的变现出口。任何一个依赖网络的界面操作，都必须有三种状态的完整设计：
| 状态 | 内容 | 后端契约 |
|---|---|---|
| 加载态 | 请求已发出：禁用按钮 + 进度/骨架，让玩家知道"点了有用" | 接口要有可预期的延迟上限；超过 UI 等待上限（如 3 秒）前端主动转错误态 |
| 错误态 | 明确失败：错误码映射的玩家可读文案 + 补救入口 | 错误码体系要为 UI 文案设计（第 04 讲协议设计的错误码部分），不能只有内部堆栈 |
| 重试态 | 不确定成败（超时/断线）：提示"正在重试"或让玩家手动重试 | 重试必须幂等——服务端没有幂等键（第 10 讲结算、第 11 讲领取的重放防御），客户端重试就会变成重复下单 |
最常见的线上事故形态是三态缺一：没有加载态→玩家狂点→服务端收到 N 连击请求；没有幂等→N 连击变成 N 次发货。客户端的按钮防抖只是第一道闸，服务端幂等才是最终裁决——这个责任划分写进接口文档，而不是留在口头上。
边界：不是所有界面都要三态俱全。本地即时反馈的操作（拖拽背包格）不该有网络依赖；反过来，付费、结算、交易类操作必须三态 + 幂等全配齐。按操作的"出错代价"分级，不要一刀切。
3. 动画状态机与逻辑状态机
3.1 两台状态机的分工
客户端里实际跑着两台状态机：
- 逻辑状态机：角色"处于什么状态"——待机/移动/攻击/眩晕/死亡。它驱动玩法判定（能不能受击、能不能交互），是第 09 讲状态模式管的对象。
- 动画状态机：角色"看起来在干什么"——动画片段、过渡、混合树。它只管表现，跑在动画系统里。
两者的关系是单向供血：逻辑状态变化驱动动画状态切换；动画系统反过来的唯一合法通道是动画帧事件（某一帧触发的定点回调，如挥刀第 8 帧出伤害判定）——而且这条通道必须经过逻辑层校验，不能直接改业务数据。
3.2 失配的三个经典坑
- 过渡时间吞掉响应：动画状态机有过渡混合（0.2 秒渐变很常见），逻辑切了状态、动画还在渐出——玩家觉得"手感延迟"。表现问题在动画层调参解决，不要为手感去改逻辑状态机的时序，否则判定和表现一起乱。
- 逻辑写在动画事件里：把"造成伤害""播放音效之后的扣血"挂在动画帧回调上。动画被降级（低配机裁剪动画、卡顿丢帧）时，事件不触发，逻辑凭空丢失。纪律：帧事件只允许触发"表现补全"（音效、特效），一切影响判定与数值的逻辑放在逻辑状态机的迁移点上。
- 回滚与重连的动画黑洞：断线重连、局内回滚（第 04 讲同步模型）后，逻辑状态机直接跳到当前状态，动画层却停留在旧状态——出现"站着挨打"的鬼畜。规范是重连/回滚后动画状态机做硬切（跳过过渡直接对齐），并在对齐点补一次表现校准。
3.3 权威在哪
竞技与强对抗玩法里，逻辑状态机的权威在服务端（服务端裁决状态迁移，客户端表现跟随，见第 04 讲状态同步）；单机感强的玩法（换装、家园）可以客户端权威 + 服务端存档。判断口诀：状态影响判定的，服务端权威；只影响观感的，客户端自治。动画层永远不参与权威裁决——它是最容易被裁剪、降帧、打断的一层。
4. 资源加载与内存预算
4.1 分包与首包
第 03 讲说过小游戏的硬约束：微信小游戏主包 4MB（整包上限以平台当前规则为准），引擎本体加上首场景就快贴线。分包的本质是把"必须开机就有"压缩到最小，其余按需取：
- 主包：引擎 + 启动场景 + 登录——能立刻让玩家看到"游戏开了"。
- 远程资源：场景、角色、配置走 CDN 按需下载，带版本号与差量更新（第 17 讲版本体系的服务端配套就在这里接上）。
口径要对齐的是"首包"这个词：包体首包（下载渠道评的那个）与首包时间（第 5.3 节，启动到可玩的耗时）不是一回事，两个都要管。
4.2 加载策略与卸载
资源管理的全部难点可以浓缩成一个问题：什么东西留在内存里、留多久。常见策略：
- 场景级卸载：切场景时整体释放旧场景资源——粗但可靠，是默认底座。
- 常驻池 + 引用计数：高频复用的小资源（图标、音效、弹窗 prefab）进常驻池，引用计数归零才真正卸载。引用计数多减一次就是"野指针式"的资源丢失（下次用到重新加载，表现为偶发卡顿），少减一次就是泄漏。
- 加载打桩与排队：加载请求合并、去重、限流——同一帧里 20 个系统同时请求各自的资源，会把 IO 与解码挤爆在一帧里，制造加载卡顿。
内存泄漏的隐蔽性在于它不崩在案发现场：内存是慢慢涨上去的，几个小时后 OOM（系统杀进程）闪退，现场什么都没有。解法不是猜，是内存水位监控（下一节）。
4.3 内存水位
低端机的内存红线是硬的：超过系统给进程的上限就是 OOM 闪退。工程口径是把内存预算写进资源管线——目标机型的内存上限倒推各模块配额（UI 多少、战斗场景多少、音频多少），超配额的资源进不了包。运行时做水位分级：到黄色水位开始主动卸载低频资源、降贴图档位；到红色水位放弃缓存保命。
与容量的类比：这是客户端版的"水位扩缩"（附录 A4 讲的是服务器侧的水位与扩缩）——两边共享同一个思想：预算前置，而不是事后救火。
4.4 与后端下发数据量的协同
服务端写给客户端的每一个字节，最终都落在客户端的某一笔预算里：
- 登录全量下发：登录时把背包、邮件、好友、任务一次推完——客户端解析 + UI 构建的时间全部记进首包时间。改成按界面懒加载（打开背包才拉背包），首包立省一截。这是前后端一起改的典型项：服务端提供分页/增量接口，客户端改加载时机。
- 配置表体积：全量配置表几十 MB 是常见的"历史遗产"。拆分（按模块/按版本差量）+ 压缩，是第 17 讲配置管线与客户端加载的直接交汇点。
- 推送频率：聊天、状态、排行榜的推送节奏直接冲击 UI 重建（2.1 节的合批污染）。第 11 讲的合并推送不只是省服务端带宽，也是在保护客户端帧时间。
判断：凡是"客户端一进大厅就卡"的问题，先看服务端首屏下发的字节量与结构，再看客户端解析与 UI 构建——两边各有一半责任是常态。
5. 前端性能：按「谁的责任」归因
5.1 帧率预算
性能问题的第一张表是帧时间分解：16.6ms 里，逻辑更新占多少、渲染提交占多少、GPU 占多少、UI 重建占多少、等待（含网络等待）占多少。引擎的 Profiler 能给出这行分解——没有分解的争论全是嗓门。约定俗成的口径：掉帧分两种，持续低帧率（负载长期超预算，资源规格问题）与间歇卡顿（偶发尖峰，加载/UI 重建/GC 问题）。两者的病因和处理完全不同。
5.2 卡顿归因分层
玩家说"卡"，可能是五种完全不同的病。归因按下表分层，从上往下排，上面的先证伪：
| 层 | 典型症状 | 证据在哪 |
|---|---|---|
| 客户端渲染 | 画质相关：人多、特效多时掉帧；DC 爆表 | 抓帧分析（Frame Debugger/RenderDoc）看 DC 与过绘制 |
| 客户端逻辑 | 周期性小刺：GC、UI 重建、加载解码挤在一帧 | Profiler 的帧时间分解；GC 日志 |
| 网络 | 操作到反馈的延迟固定且稳定（RTT 量级），波动跟随网络环境 | 客户端 ping/丢包统计 + 服务端 trace 对时 |
| 服务端 | 所有玩家同时反馈慢，且慢在同一个接口 | 服务端 trace 与慢查询日志（知识库"可观测性、性能、容量与稳定性"一章的口径） |
| 资源管线 | 特定场景/机型卡：冷启动、首次进新地图 | 加载打桩数据 + 机型分布 |
两条纪律：单点复现优先于群体感受（拿到能复现的机型+场景+操作序列，价值超过一百条"卡"的客诉）；两端对表（客户端时间线与服务端 trace 的时间对齐，才能把"网络慢"和"服务端慢"切开——对时口径见第 12 讲埋点的 server_ts 字段）。
5.3 首包时间
首包时间（点击图标到可交互大厅）是玩家对"这游戏卡不卡"的第一印象，它的预算分解是一条流水线：
启动 → SDK 初始化 → 版本检查 → 热更下载 → 登录鉴权 → 拉取首屏数据 → 进大厅每一环都有归属：SDK 初始化慢找平台接入方（登录 SDK 串行初始化是常见病灶，能并行就并行）；版本检查与登录鉴权是服务端接口——这两个接口必须按"低延迟 + 可降级"设计（版本检查接口挂了要不要拦启动？拦截策略要在服务端预案里写死，见第 13 讲开服实战）；热更下载慢看 CDN 与差量策略；首屏数据慢回到 4.4 节的下发协同。
监控口径：首包各环节打桩上报（事件分层里属于系统事件，第 12 讲 2.1 节），按机型与网络分位数（P50/P90）看，不看好运的平均值。
6. 实战建议
给后端工程师的行动清单，按场景：
- 评审接口时：问一句"这个接口的响应会被谁在什么时机消费？"——登录首屏的接口按首包预算设计，战斗内接口按帧预算设计。大响应默认要求分页或增量。
- 设计协议时：错误码面向三态设计（2.3 节），写操作一律带幂等键语义——客户端一定会重试，这不是如果，是何时。
- 排障时：先跑第 5.2 节的归因分层，拿证据再发言；"服务器卡"三个字在拿到两端对表的数据之前，只是个假设。
- 性能联测时：客户端资源预算表与首包打桩数据，应当和压测报告（附录 A4）一起出现在性能验收材料里——性能是一张两端合账，不是两本分开的账。
7. 常见陷阱总结
| 陷阱 | 说明 | 缓解 |
|---|---|---|
| 把所有卡顿当服务端问题 | 客户端 DC 爆表、UI 重建、GC 各自都能造出"卡"的体感 | 第 5.2 节归因分层，证据先行 |
| 逻辑写在动画事件里 | 动画降级/丢帧时逻辑凭空丢失 | 帧事件只做表现补全，逻辑放状态机迁移点 |
| 重连后动画不对齐 | 逻辑已跳转，动画还在旧状态渐变 | 重连/回滚后动画硬切对齐 |
| 无加载态的按钮 | 玩家狂点产生请求风暴 | 三态交互必备，服务端幂等兜底 |
| 登录全量下发 | 首包时间被解析与 UI 构建吃掉 | 按界面懒加载，服务端给增量接口 |
| 内存只涨不管 | 数小时后 OOM 闪退，无现场 | 水位分级 + 泄漏归因例行化 |
| 合批/缓存滥用 | 动态合批负优化、缓存击穿回源 | 每种手段记适用面与反向代价（1.2 节） |
| 首包只测旗舰机 | 低端机真实耗时是旗舰机数倍 | 按机型分位数监控，P90 定预算 |
8. 小结
本章把客户端拆成四本账：渲染的帧时间账、UI 的重建与三态账、动画的两台状态机账、资源的内存水位账。贯穿四账的主线只有一句：客户端的每个字节与每次刷新，都是服务端决策的下游后果；客户端的每种卡顿，也都是一次归因练习的起点。后端工程师不需要画好一帧，但需要知道一帧多少钱、钱花在哪、以及当它超支时，怎么证明不是自己挪用的。
下一章进入第 20 讲 游戏测试与质量保障：这些性能预算怎么变成验收门槛，客户端与服务端的测试各管什么。
9. 实战案例：一次「新地图 24 帧」的渲染指令归因
案例为教学示例（非摘自真实项目），数字经过取整简化。它把 1.1 的帧时间账、1.2 的合批工具箱与第 5 节的归因表用到深水区：逐条渲染指令回答「帧时间花在了哪」——这是前端性能的指令级排查，也是 1.4 节「服务器卡」假线索的终极自证。
背景与现象：新地图「沉没之城」上线 3 天，中端机玩家工单涌入「进图就卡」，客服定性「服务器卡」。服务端一片干净：网关 RTT 正常、帧同步无积压、CPU 平稳。客户端性能埋点：平均帧率 42，但 P05 尾帧只有 24（P05 分位 = 5% 的帧比它更慢）——平均口径又把长尾藏了（与第 13 讲监控口径同一课）。卡帧判定口径先行：帧耗时 > 33ms（即低于 30fps）计为卡帧，当前卡帧占比 11%。
第一步：口径与预算——先定 bound 方向，再翻指令账本
中端机目标 30fps，帧预算 = 33.3ms（1000/30）；实测尾帧 41.7ms——正是 1000/24，超预算 8.4ms（25%）。先判 bound：帧时间拆分 CPU 提交 21ms / GPU 38ms——GPU 主导（GPU bound），但 CPU 21ms 也已吃掉预算的一大半：双侧都在超支，不是单点问题。归因从指令级账本开始。
第二步：维度拆分——指令级账本
Draw Call 旧地图 210 → 新地图 480（2.3 倍，超预算表单屏上限 300）
材质/合批 480 个 DC 里 260 个因独立材质无法合批（植被与装饰物各带材质实例）
过绘 半透明水面与雾效叠加，屏幕平均过绘 3.8 层（基线 1.6 层）
实时阴影 全场景动态阴影未设距离分级，远山也投 2048 阴影贴图
三角形 120 万/帧（预算 80 万），超支主要来自远景未切 LOD- 按场景：只有新地图超标，旧地图持平——是内容问题，不是版本问题
- 按档位：高端机 55 帧（预算 60 只差 5）——规格没有按档位分级，中端机扛了全量
第三步：根因——三件事同时吃满 GPU，且没有一条防线拦住它们
- 直接原因：DC 480 超预算上限 300（×1.6）、过绘 3.8 层、远景 LOD 未切——GPU 渲染时间被三件事叠加吃满
- 机制原因：美术管线没有「单场景 DC / 材质数 / 过绘」的资产审计门禁（第 21 讲美术管线四件事里的审计缺位）——规格违规资源直接进了包
- 预算原因：资源预算表只有内存水位（4.3 节），没有渲染预算（DC/面数/过绘按机型档位分级）——中端机没有降级路径可走
第四步：处置与回填
处置按「收益 / 成本」排序：
- 植被与装饰改 GPU Instancing + 共享材质：DC 480 → 260（−46%，回到预算线内）
- 阴影分级：40m 外切低分辨率阴影贴图
- 半透明水面改预处理噪声图：过绘 3.8 → 2.1 层
- 中端机后处理整体降级为画质选项
复核：尾帧 24 → 41 fps，平均 42 → 47，卡帧占比 11% → 3%；高端机维持 55+ 帧不受影响。
回填清单（呼应第 14 讲复盘回填纪律）：
| 回填项 | 归属 | 完成标准 |
|---|---|---|
| 资产审计门禁：单场景 DC ≤ 300 / 材质数 / 过绘层数进美术出包检查（呼应第 21 讲 2.4 审计门禁） | 美术/工具 | 门禁上线并跑全场景 |
| 渲染预算表按机型档位分级（DC/面数/过绘），与内存水位同表管理（4.3） | 客户端 | 预算表评审通过 |
| 帧率监控按分位（P05）× 档位上报，替代平均值大盘（呼应第 13 讲口径） | 客户端/数据 | 看板改版 |
| 新场景上线前 GPU/CPU bound 基准测试进验收（呼应第 20 讲性能门槛） | QA/客户端 | 基准脚本入库 |
案例的三个教训
- 平均帧率是给运营看的，分位帧率才是给玩家看的。42 的平均配上 24 的尾帧，玩家活在 P05 里——第 13 讲「平均值口径」的客户端版
- 指令级账本是把「卡」变成「哪条指令贵」的唯一路径。DC、材质、过绘、LOD 四本小账对上，根因不需要猜
- 渲染预算与内存水位同权。4.3 节给内存设了水位，DC 与过绘同样需要按档位的红线——否则美术管线的审计无据可查