聊“游戏优化”这四个字,不同岗位的人脑子里蹦出来的画面完全不一样。程序想到的是帧时间和内存曲线,美术想到的是贴图分辨率和面数,主策想到的是新手流程的流失漏斗,发行想到的是首包体积和买量成本。所以当有人问“游戏里的优化指的是什么”,这问题其实没法一句话答完,它至少横跨了性能、资源、体验、流程四条线。我做了这些年项目,踩过的坑里有一半不是技术不够,而是大家对“优化”的理解没对齐——程序在那边抠两毫秒,策划还在往场景里塞新特效;或者美术被告知“要优化”,结果只是把贴图从 4K 降到 2K,帧率纹丝不动。这篇就把游戏优化这件事从头到尾拆一遍:它到底在优化什么、帧预算怎么算、渲染和 CPU 侧的常见手段有哪些、加载和网络这两条容易被忽视的战线怎么处理,以及如何把它做成流程而不是每次都靠救火。不管你是刚入行的新人,还是做了几年但一直只负责一小块的同行,应该都能从里面找到能直接抄作业的部分。1. 同一个词,四种含义:先把“优化”拆开在项目里听到“优化”两个字,第一件事不是打开性能面板,而是先问清楚对方说的是哪一种。因为这四种优化目标不同、负责人不同、验收标准也完全不同,混在一起谈必然吵架。1.1 帧率优化:让画面稳定跑下去这是最狭义、也是最常被默认的一种。目标是让游戏在目标机型上稳定维持设计帧率,不出现明显掉帧和长帧。它的核心指标是帧时间(Frame Time),而不是帧率(FPS)。原因很简单:帧率是帧时间的倒数,是个平均值概念,而玩家感受到的卡顿来自某一帧特别长。60 帧下平均 16.7 毫秒看着漂亮,但只要每两秒蹦出一帧 80 毫秒的长帧,手感就是“一顿一顿”的。这一类优化的负责人通常是客户端程序,涉及渲染、逻辑、物理、动画多个子系统。它的难点不在于手段少,而在于定位瓶颈比解决问题难十倍。同样掉帧,可能是 Draw Call 太多、可能是半透明过度绘制、可能是每帧在托管堆上分配导致回收、可能是某个物理体的碰撞层配错导致全场景遍历。手段就那几种,但你得先知道该用哪一种。注意:帧率优化最忌讳“凭经验猜”。我见过太多次“肯定是渲染问题”,结果关掉渲染画质帧率没变,最后发现是某个计时器每帧在拼字符串。1.2 内存与包体优化:让东西装得下、跑得开这一条在小屏幕上尤其致命。移动设备的进程可用内存是有硬上限的,中低端机往往在 1.5G 到 2G 这个量级徘徊,超了就是系统直接杀进程,玩家看到的是“闪退”,而不是“卡”。而包体则直接影响了下载转化率——用户在看到安装包大小的那一秒,就已经在决定要不要装了。内存优化的核心是峰值和常驻两个数。很多团队只看平均占用,结果进某个特效爆炸的场景瞬间峰值翻倍,直接崩。包体优化的核心是首包和增量,首包决定能不能装、愿不愿意装,增量决定更新体验。这两块的负责人通常是主程加技术美术,工作量集中在资源规范、压缩策略、加载卸载策略上。1.3 体验优化:让操作跟手、流程不烦这一层经常被技术同学忽略,但它对留存的影响往往比多两帧还大。所谓体验优化,包括输入到画面的响应延迟、动画过渡是否顺滑、镜头跟随是否让人晕、UI 点击反馈是否明确、新手引导是否能在一分钟内让人明白要干什么。举个最常见的例子:按钮点下去没有立即反馈,哪怕实际逻辑已经执行了,玩家的第一反应也是“没点到”,于是再点一次,造成重复操作。这类问题的修复成本极低,但需要有人真正把自己当玩家去玩一遍。1.4 商业与流程优化:让项目活下来最后一层不在代码里,在项目管理和商业设计里。比如付费点的出场节奏、广告的展示频次、日常任务的时长控制、版本迭代的排期。这些也叫“优化”,而且往往是老板最关心的那种。它们的共同点是:用数据说话,而不是用感觉说话。这里要多说一句,很多技术同学会觉得这一层“不纯粹”。但现实是,一个帧率 60 但没人付费的项目活不下去,一个帧率 45 但留存健康的项目能一直迭代。把技术指标放在商业目标的对立面,是新人最容易犯的错。优化类型核心指标主要负责人典型手段帧率优化帧时间 P95、长帧数量客户端程序合批、剔除、降分辨率、GC 控制内存包体峰值内存、首包体积主程、技术美术贴图压缩、按需加载、资源规范体验优化输入延迟、流程流失点客户端程序、策划手感调校、UI 反馈、引导精简商业流程留存、付费率、LTV策划、运营节奏设计、频次控制、A/B 测试2. 帧预算:所有性能讨论的起点没有预算概念的优化都是耍流氓。这一节把账算清楚,后面所有手段才有意义。2.1 把“多少帧”换算成“多少毫秒”帧预算的算法很朴素:单帧可用时间 1000 毫秒 ÷ 目标帧率。30 帧 → 33.3 毫秒60 帧 → 16.67 毫秒90 帧 → 11.1 毫秒120 帧 → 8.33 毫秒但这是理论上限,不是可用预算。实际要扣掉三块:操作系统和后台进程占用的时间、引擎固定开销(比如渲染管线的基础提交、动画系统的基础更新)、以及给波动留的余量。我一般的做法是打八折,甚至在中低端机上打七折。举例:60 帧目标,理论 16.67 毫秒,打八折是 13.3 毫秒。这 13.3 毫秒里,再按子系统切分:渲染 6 到 7 毫秒、逻辑与动画 3 到 4 毫秒、物理 1 到 2 毫秒、剩下 1 到 2 毫秒留给波动和系统抖动。当然这个比例随游戏类型变化很大,竞技类手游的逻辑占比会更高,场景重的开放世界则渲染占大头。提示:预算表要写下来,贴在项目文档里,并且每个子系统有明确的“超预算告警线”。没有这张表,评审时永远是“我觉得还能再塞点”。2.2 先定位瓶颈,再谈手段帧预算超了,第一反应不该是优化,而是定位。最基本的一刀是切分 CPU 侧和 GPU 侧。做法很直接:把渲染分辨率降到极低(比如降到 25%),如果帧时间几乎没变,说明瓶颈在 CPU;如果帧时间大幅下降,说明瓶颈在 GPU。反过来,把逻辑更新频率减半或者关掉一部分 AI,如果帧时间下降,那就是 CPU 逻辑侧的问题。这个判断的意义在于:CPU 瓶颈和 GPU 瓶颈的解决手段几乎不重叠。CPU 瓶颈你去做贴图压缩是白费劲,GPU 瓶颈你去优化脚本逻辑也是白搭。我见过一个组连续两周优化脚本,最后发现是阴影贴图分辨率开太高导致的填充率问题——一个参数的事。再往下细分,CPU 侧看主线程、渲染线程、工作线程的耗时曲线;GPU 侧看各渲染阶段的耗时分布,重点看基础几何、阴影、后处理、半透明这几块谁占得多。这套流程走完,基本能锁定到具体模块。2.3 平均帧率是骗人的,看 P95 和长帧这一点必须单独强调。平均 FPS 是最没有参考价值的指标,因为它会把长帧平滑掉。一局游戏平均 58 帧听起来很稳,但如果这 58 帧是“56 帧的流畅 偶尔一帧 200 毫秒”,玩家感受就是持续卡顿。正确的看法是三个数:P95 帧时间:95% 的帧都在这个时间以内,代表“大多数时候的体验”P99 帧时间:尾部体验,代表“最难受的那部分”长帧占比:超过某个阈值的帧占总帧数的比例,比如超过 33 毫秒的帧有多少我给项目定过的验收线大致是:目标 60 帧的机型上,P95 帧时间不超过 20 毫秒,长帧占比低于 0.5%,并且不允许出现单帧超过 100 毫秒的情况——因为那是肉眼可见的“卡一下”。统计周期也要注意。跑 30 秒的采样根本不够,起码要覆盖完整的战斗循环、场景切换、UI 弹窗这些场景,采样时长 5 分钟以上。短采样容易把冷启动和缓存命中混在一起,数据没有代表性。3. 渲染侧优化:最容易见效也最容易翻车渲染是绝大多数游戏的主要开销,也是优化手段最丰富的地方。但这一块也是最容易“改了没效果”或者“改完画面崩了”的地方。3.1 Draw Call 与合批的真实成本Draw Call 的本质是 CPU 向 GPU 提交一次绘制指令。它贵的不是 GPU,而是 CPU 侧的提交开销——每次提交都要做状态校验、参数准备。所以 Draw Call 的优化目标是减少 CPU 提交次数,方式是合批。合批能成立的条件很苛刻,大致是三条同时满足:使用相同的材质与着色器变体使用相同的渲染状态(混合模式、深度测试、剔除模式等)在提交顺序上连续任何一条断了,合批就断了。常见断点包括:中间插了一个使用不同图集的 UI 元素、给某个物体单独设了材质实例、排序被半透明队列打乱。数量上给个参考区间(不是绝对标准,只是经验值):中低端移动设备每帧控制在 150 到 200 个 Draw Call 比较安全,高端设备可以到 300 到 500。超过这个量级,CPU 提交就会成为可见的瓶颈。注意:合批不是越多越好。过度合并会导致一个大网格无法剔除,视锥外的东西也被提交。所以合批要配合空间分组,按区域而不是按全场合并。还有一点容易被忽略:动态合批的开销在 CPU 上。某些引擎提供的动态合批需要每帧在 CPU 侧做顶点变换,顶点数一大反而更慢。所以动态合批适合小物件,大物件要么静态合批,要么用实例化绘制。3.2 填充率与半透明:看不见的开销如果说 Draw Call 是“提交贵”,那填充率就是“画得贵”。它指的是每个像素被着色多少次。全屏特效、粒子、半透明叠加都是填充率杀手。一个直观的例子:屏幕上有一层全屏的雾效,再叠一层全屏的色调后处理,再加一片覆盖半个屏幕的粒子特效,那么这半个屏幕的像素至少被处理了三次。在低端 GPU 上,这足以让帧率掉 10 帧以上,而 Draw Call 只增加了 3 个,你在提交列表上根本看不出来。处理思路上有三条:减少层数:能合并的后处理合并,能烘焙进贴图的雾效就别实时算减小面积:粒子特效的发射范围收紧,避免大范围铺满屏幕;全屏后处理改用半分辨率渲染控制顺序:不透明物体先画(利用深度测试提前剔除),半透明后画,并且半透明内部按从近到远排序,减少无效覆盖半透明的排序还有个隐藏成本:排序本身是 CPU 侧的事,粒子数量上万的时候,排序耗时就能吃掉一两毫秒。这时候要考虑把粒子改成用顶点动画的网格,或者干脆减少粒子数量改用心跳式的低频更新。3.3 贴图与模型:内存和带宽的大头贴图是内存占用的第一大户,也是显存带宽的主要消耗者。算笔账就明白了:一张 2048×2048 的 RGBA8 未压缩贴图 2048 × 2048 × 4 字节 ≈ 16MB。如果项目里有 100 张这样的贴图,就是 1.6GB,这在移动设备上是不可能承受的。压缩之后就完全不一样了。用块压缩格式,常见的 4x4 块、每像素 8 比特的方案,压缩比是 4:1,同样一张图变成 4MB,100 张就是 400MB。如果是 4x4 块、每像素 4 比特的方案,压缩比到 8:1,只要 2MB 一张。代价是画质损失,尤其在法线贴图和带明显渐变的贴图上会出现块状伪影。所以贴图策略的核心是分类分级:贴图类型建议策略说明UI 图集高质量压缩,严格控制图集数量UI 常驻内存,必须精简角色主贴图中等压缩,按屏幕占比分级主角用高精度,杂兵降级场景贴图强压缩 流式加载可随场景卸载法线贴图谨慎压缩,必要时用双通道压缩伪影在法线上最明显遮罩/灰度图走单通道或合并通道一张图塞多个通道,省三份内存模型侧的重点是面数分级(LOD)。同一棵树,近处用高模、中距离用中模、远处用一张交叉面片甚至直接剔除。LOD 的切换距离要按屏幕投影面积来定而不是按世界距离,否则在广角镜头下会看到明显的跳变。还有一个很多人忽略的点:顶点属性不要塞太多。位置、法线、切线、两套 UV、顶点色、骨骼权重和索引,加起来每顶点可能超过 60 字节。十万面的模型就是 6MB 的顶点数据。能砍的砍,能用半精度的用半精度。3.4 阴影、后处理与实时反射的取舍这三样是“画面提升最明显、性能代价最大”的典型。它们几乎没有中间态,要么开要么关,要么高要么低。实时阴影的代价主要在两方面:阴影贴图的渲染(相当于把场景再画一遍)和阴影采样(每个受光像素都要查表)。降低代价的手段有:缩小阴影贴图分辨率、减少投射阴影的物体数量(远景物体不投影)、用级联阴影把精度集中在近处、把静态物体的阴影烘焙进光照贴图。后处理同理。全屏泛光、景深、屏幕空间反射、色调映射,一层层叠上去,每层都是全屏的像素处理。常见的做法是提供画质档位,低档位直接关掉景深和屏幕空间反射,只保留色调映射和抗锯齿。这里我要说个反常识的观察:画质档位对玩家体验的影响,远小于帧率稳定性的影响。同一个游戏,高画质 45 帧和低画质稳定 60 帧,后者评价明显更好。所以档位设计的思路应该是“优先保帧率,画质在预算内尽量给”,而不是“画质砍一刀换十帧”。4. CPU 侧:主线程、GC与逻辑开销GPU 侧的问题往往好定位,因为工具齐全、指标明确。CPU 侧的问题就阴险得多,尤其是内存分配导致的卡顿,现象和原因隔得很远。4.1 每帧分配是卡顿的头号嫌疑这个坑几乎所有用托管语言的团队都踩过。逻辑代码里随手一个new、一次字符串拼接、一次匿名闭包捕获、一次装箱,单次开销微不足道,但每帧累积起来,托管堆就会不断增长,触发垃圾回收。而回收的瞬间(尤其是不分代的全量回收)可能产生几毫秒到几十毫秒的停顿,表现就是一卡一卡的。判断方法很简单:看托管堆的分配曲线。如果每帧稳定增长几十 KB,那就是持续的分配热点。找到热点之后,手段是固定的几种:对象池:高频创建销毁的对象(子弹、特效、飘字、列表项)一律池化避免在更新循环里拼字符串:调试信息、显示数值的格式化要缓存或延迟避免闭包捕获:回调里捕获了外部变量就会产生分配,改成传参或缓存委托小心隐式装箱:值类型塞进 object 参数、字典用值类型做 key 但没实现比较器,都可能装箱容器预分配:列表扩容会分配新数组,容量能预估就提前给一段典型的池化写法长这样,思路比具体语法重要:public class BulletPool { private readonly StackBullet _idle new StackBullet(256); private readonly ListBullet _active new ListBullet(256); public Bullet Spawn(Vector3 pos) { Bullet b _idle.Count 0 ? _idle.Pop() : new Bullet(); b.Position pos; b.Alive true; _active.Add(b); return b; } public void Tick(float dt) { // 倒序遍历,避免 RemoveAt 造成索引错位 for (int i _active.Count - 1; i 0; i--) { Bullet b _active[i]; if (!b.Alive) { _active.RemoveAt(i); _idle.Push(b); // 回收而不是丢弃 } } } }提示:池子要有上限。不限量的池子会把内存吃满,最后变成“为了省 GC 而爆内存”,得不偿失。超过上限的回收直接丢弃,让 GC 去处理,反而更健康。4.2 对象池与分帧实例化池化解决的是“反复创建”的问题,分帧解决的是“一次创建太多”的问题。典型场景是关卡加载:一次性实例化两百个敌人和上千个场景物件,主线程直接卡住半秒。做法是把创建过程摊到多帧:用一个队列保存待创建的对象,每帧只处理固定数量(比如 20 个)或者固定时间片(比如 2 毫秒),超时就停,下一帧继续。这个技巧叫时间分片,几乎适用于一切“批量操作”:批量设置材质、批量生成寻路数据、批量解析配置表。代价是加载时间会略微变长,但玩家感知的是“没有卡顿的加载”,体验反而更好。这里的关键是别在战斗中途分帧,否则会出现“敌人陆续出现”的诡异现象。分帧要用在加载期或者过场期。4.3 逻辑与 AI 的时间片逻辑开销的大头往往是那些“每帧都在跑但没必要每帧跑”的东西。寻路重算、目标选择、视线检测、UI 数值刷新,这些操作大部分时候结果不变,没必要每帧算。常见做法是给这些系统设更新频率分级:玩家自身和近距离敌人:每帧更新中距离单位:每 0.1 秒更新一次远距离单位:每 0.3 到 0.5 秒更新一次,或者干脆冻结逻辑只保留动画屏幕外单位:完全冻结,只保留必要的状态推进这套分级带来的收益非常可观。一个同屏 200 单位的场景,如果全部每帧跑完整 AI,主线程轻松吃掉 8 毫秒;分级之后能压到 2 毫秒以内,而且玩家完全看不出区别——因为远处的敌人你本来也看不清动作。物理同理。碰撞层要配清楚,别让装饰物参与物理检测;能用地形数据算的别用碰撞体;静态碰撞体一定要标记成静态,否则每帧都要重建空间结构。5. 加载、包体与网络:另外两条容易被忽视的战线性能优化做得再好,加载慢、包太大、联机卡,玩家一样给差评。这两条战线经常被归到“运营”或“后端”那边,但它对体验的影响一点都不比帧率小。5.1 首包与加载时间首包体积的目标要看渠道和品类,但大致的原则是:越小转化越好,每多 100MB 下载转化就明显掉一档。所以首包必须只放“进游戏第一分钟必须用到的东西”:登录界面、新手关卡、基础角色、基础 UI。其余资源全部走增量下载或按需加载。这需要一套资源管理机制支撑:资源分级:首包资源、章节资源、活动资源分开打包依赖分析:加载一个角色要知道它依赖哪些贴图、动画、特效,避免加载到一半缺资源引用计数:资源用完要能卸载,卸载时机按“离开场景后延迟几秒”比较稳妥,太激进会导致反复加载预加载:在玩家看剧情、看结算的时候偷偷加载下一段,别等他点了“开始”才加载加载时间的构成也要拆开看:解压耗时、IO 耗时、实例化耗时、首帧渲染耗时(着色器编译)。很多时候加载慢不是 IO 慢,而是着色器编译慢——第一次见到某个材质,编译要几百毫秒,表现就是“加载完成但卡住一瞬”。解决办法是加载期做预热渲染,把所有会用到的材质变体提前编译一遍。注意:着色器变体爆炸是个隐蔽的坑。一个材质如果支持十几种开关组合,变体数量会指数增长,包体和编译时间都会失控。变体要严格控制在真正用到的组合上。5.2 网络同步的优化思路联机游戏的优化维度里,网络是独立的一块。它的核心矛盾是:同步精度和带宽之间的取舍。同步方案大致分两类:状态同步(服务器下发状态,客户端表现)和帧同步(只同步输入,各端本地计算)。状态同步的优化重点是压缩和降频:只同步变化了的字段,没变的不发位置用相对坐标和定点数压缩,别直接发浮点远处单位降低同步频率,或者只同步粗略位置视野外的单位不同步,靠兴趣区域管理状态快照做差量,只发增量帧同步的优化重点是确定性和输入延迟。所有逻辑必须走定点数,浮点在不同设备上结果不一致会导致不同步;输入要尽早发出,同时用预测和回滚掩盖延迟。延迟的表现也要区分对待。网络延迟高(比如 150 毫秒)但稳定,玩家的体验是“有点粘”但能适应;延迟忽高忽低(抖动),体验就非常糟糕。所以优化网络的第一优先级往往是降低抖动,比如加缓冲队列、平滑插值,而不是单纯追低延迟。6. 体验层优化:手感、UI与数值节奏技术指标都达标了,不代表游戏“好玩”。这一层经常被技术同学忽略,但它才是玩家真正在评价的东西。6.1 输入延迟与手感调校输入延迟指的是从手指按下到画面出现变化的时间。这个链路很长:触摸采样 → 输入事件分发 → 逻辑处理 → 动画切换 → 渲染提交 → 屏幕显示。每一环都会加几毫秒,累积起来可能超过 100 毫秒,玩家就会觉得“不跟手”。压缩延迟的手段:采样频率:触摸采样尽量每帧都读,别攒着减少中间层:输入事件别经过太多转发和队列立即反馈:按下瞬间先给视觉或音效反馈,逻辑结果可以晚几帧动画前置:攻击动作的前摇要短,判定框要早于视觉动作的“到位”帧后摇可取消:允许用下一个动作打断后摇,这是动作游戏手感的关键镜头的调校也是同理。第三人称跟随如果完全刚性绑定,画面会抖;加平滑又会有延迟感。常见的解法是位置用较快跟随、朝向用较慢跟随,并且对加速度做衰减,让镜头“有重量但不迟钝”。这些参数没有标准值,只能在真机上反复调,而且要针对不同灵敏度设置分别调。6.2 UI 的性能与易用性UI 是性能重灾区,因为它天然是半透明、频繁重建、层级复杂的。常见问题:每个元素单独一个图集,导致合批全断。解法是把同一界面的 UI 图打进一张图集文本频繁刷新,每次刷新都重建网格。解法是数值变化时做节流,或者只更新变化的部分列表一次性创建全部条目,一百个道具就创建一百个节点。解法是用循环列表,只创建可见区域的条目全屏遮罩叠多层,填充率暴涨。解法是合并遮罩层易用性方面的坑更多:按钮太小点不中、弹窗关不掉、加载时没有进度提示、操作没有撤销。这些不叫性能问题,但修复成本和收益比都远高于抠两毫秒。6.3 数值与付费节奏的“优化”这一层已经不是技术活了,但既然讲“游戏优化”,绕不开。新手前十分钟的节奏、第一次获得稀有物品的时机、日常任务的时长、付费点的位置,这些设计的调整往往能带来比技术优化大得多的数据变化。技术侧能提供的支持是数据埋点和实验框架:关键节点埋点、留存漏斗、A/B 分组、快速的配置热更新。有了这套东西,策划改数值不需要等版本,当天就能看到效果。这件事的价值,做过的团队都懂。7. 怎么把优化做成流程而不是救火上面讲的都是“怎么优化”,这一节讲“怎么让优化持续发生”。我待过的项目里,优化做得好的都不是靠某个高手,而是靠流程。7.1 建立基准场景与指标门禁第一步是有一个固定的基准场景:同一段战斗、同一个视角、同一批单位、同样的操作序列。所有人测性能都跑这个场景,数据才有可比性。没有基准场景,两个人报的帧率能差 20 帧,讨论就失去意义。第二步是把指标写进流程:每次提交代码自动跑基准场景,帧时间 P95、峰值内存、包体大小超过阈值就告警。门禁的阈值要留一点余量,不然天天误报,大家就都无视了。第三步是性能预算表跟着需求走。策划要加一个新特效,先看这个特效占多少预算;美术要加一套新模型,先确认面数和贴图尺寸在预算内。预算不是用来卡人的,是用来让取舍有依据的。7.2 真机矩阵与自动化采集模拟器和高端机跑得再好都没意义,必须上真机。机型矩阵不用铺太满,但要有代表性:档位定位关注点低端三五年前的入门机能不能跑起来,内存会不会爆中端主力用户机型帧率稳定性,发热降频后表现高端新旗舰高画质档位是否达标特殊大屏、折叠、低内存分辨率适配、内存上限自动化采集的价值在于批量。手动一台台测,一天测不了几台;自动化脚本可以一晚上跑完一轮,第二天直接看报表。采集的内容至少包括:帧时间分布、峰值内存、加载耗时、发热后的帧率衰减曲线。发热这一项特别重要,也特别容易被忽略。很多手机跑三分钟很稳,跑十分钟因为降频直接掉 20 帧。所以性能测试的时长要覆盖真实使用场景,不能只测一分钟。7.3 跨岗位协作的约定优化最难的其实不是技术,是协作。程序说美术资源超标,美术说你引擎不优化,策划说你们别砍我的特效。要避免这种局面,得提前约定几件事:资源规范文档化:贴图尺寸上限、面数上限、材质数量上限,写清楚,评审时对照检查提交前自检:提供一个检查工具,美术导出资源时自动检查规范,不合规直接报错性能评审进流程:新功能上线前走一次性能评审,而不是上线后被玩家骂了再回头改数据共享:性能报表对全组开放,谁都能看到自己负责的部分占多少我个人体会最深的一点是:优化要趁早,但不能太早。项目早期结构还在变,过早优化会白做;但等到上线前一个月才开始,又来不及。比较合理的节奏是:原型期不管,垂直切片期建立基准场景和预算表,量产期持续跑门禁,上线前做专项攻坚。这个节奏踩准了,优化就不会变成救火。8. 常见问题速查与踩坑实录最后这部分是我这些年攒下来的排查经验,按现象归类,遇到问题时可以对着表先过一遍。8.1 现象与原因速查表现象常见原因快速验证方式处理方向帧率整体偏低但很稳GPU 填充率或 Draw Call 到顶降分辨率看帧率是否上升降低后处理、减少半透明、合批每隔一两秒卡一下托管堆分配触发回收看托管堆分配曲线池化、消除每帧分配进入新场景瞬间卡死一次性实例化过多对象记录加载各阶段耗时分帧创建、预加载战斗后期越来越卡对象泄漏、容器无限增长看对象计数是否只增不减补回收逻辑、加计数上限只有部分机型卡机型特性(分辨率、GPU 型号)分机型对比帧时间按机型分画质档位跑十分钟后掉帧发热降频记录温度与帧率曲线降低持续负载、加动态分辨率首次进入某技能特效卡着色器编译记录首帧耗时加载期预热编译内存持续上涨直至闪退资源引用计数没减、贴图未卸载看资源常驻列表修引用计数、加卸载时机联机时角色瞬移网络抖动、同步频率低记录往返延迟与抖动加插值缓冲、提高关键状态频率UI 界面打开明显掉帧UI 图集分散、文本重建看 UI 阶段的 Draw Call合并图集、列表循环复用8.2 几条血泪经验第一条:先测量,再动手。我见过最典型的浪费是一个组花了两周做贴图压缩,最后帧率提升不到 2 帧,因为瓶颈根本在逻辑侧。每次动手前花半小时做切分测试,能省下两周。第二条:优化要有对照数据。改之前测一遍,改之后用同样的场景、同样的机型、同样的操作序列再测一遍。凭感觉判断“好像流畅了”是最不可靠的,我至少有三次以为优化有效,数据一对比发现是噪声。第三条:别一次改十个地方。改一处测一处,否则出问题不知道是哪一处引起的。性能优化和调试一样,变量要控制。第四条:动态分辨率是保底手段,不是首选。它确实能救帧率,但画面糊起来的观感损失很大,而且分辨率频繁跳变会让玩家觉得画面在“呼吸”。要用就设一个下限,并且用较慢的调整速度,别让它每帧都在变。第五条:别为了指标牺牲可维护性。有些优化写法极其晦涩,比如把手写汇编塞进热路径、把逻辑拆成状态机硬编码。这类代码三个月后没人敢动,最后反而拖慢迭代。优化的前提是代码还能维护,除非这一段真的十年不变。第六条:玩家反馈的“卡”和你测的“卡”可能不是一回事。玩家说的卡,可能是网络延迟、可能是加载慢、可能是 UI 响应迟钝,也可能确实是帧率。收到反馈先问清楚在什么场景、什么操作下卡,别一上来就查渲染。第七条:留出性能余量。上线前把预算用满的项目,上线后一定出问题——因为真实用户机型比你测试的机型更杂、后台进程更多、存储更满。留 20% 余量不是浪费,是保险。写到这里,我自己的习惯是每次新项目立项时,先把基准场景、预算表、机型矩阵这三样东西建起来,哪怕当时只有个白模。这三样东西建得越早,后面省的心力越多。至于具体每一项怎么调,那是手艺活,得在真机上一点点磨出来——工具会变,引擎会换,但“先测量、定预算、控变量、看尾部”这套思路,我用了这么多年还没过时。
聊“游戏优化”这四个字,不同岗位的人脑子里蹦出来的画面完全不一样。程序想到的是帧时间和内存曲线,美术想到的是贴图分辨率和面数,主策想到的是新手流程的流失漏斗,发行想到的是首包体积和买量成本。所以当有人问“游戏里的优化指的是什么”,这问题其实没法一句话答完,它至少横跨了性能、资源、体验、流程四条线。我做了这些年项目,踩过的坑里有一半不是技术不够,而是大家对“优化”的理解没对齐——程序在那边抠两毫秒,策划还在往场景里塞新特效;或者美术被告知“要优化”,结果只是把贴图从 4K 降到 2K,帧率纹丝不动。这篇就把游戏优化这件事从头到尾拆一遍:它到底在优化什么、帧预算怎么算、渲染和 CPU 侧的常见手段有哪些、加载和网络这两条容易被忽视的战线怎么处理,以及如何把它做成流程而不是每次都靠救火。不管你是刚入行的新人,还是做了几年但一直只负责一小块的同行,应该都能从里面找到能直接抄作业的部分。1. 同一个词,四种含义:先把“优化”拆开在项目里听到“优化”两个字,第一件事不是打开性能面板,而是先问清楚对方说的是哪一种。因为这四种优化目标不同、负责人不同、验收标准也完全不同,混在一起谈必然吵架。1.1 帧率优化:让画面稳定跑下去这是最狭义、也是最常被默认的一种。目标是让游戏在目标机型上稳定维持设计帧率,不出现明显掉帧和长帧。它的核心指标是帧时间(Frame Time),而不是帧率(FPS)。原因很简单:帧率是帧时间的倒数,是个平均值概念,而玩家感受到的卡顿来自某一帧特别长。60 帧下平均 16.7 毫秒看着漂亮,但只要每两秒蹦出一帧 80 毫秒的长帧,手感就是“一顿一顿”的。这一类优化的负责人通常是客户端程序,涉及渲染、逻辑、物理、动画多个子系统。它的难点不在于手段少,而在于定位瓶颈比解决问题难十倍。同样掉帧,可能是 Draw Call 太多、可能是半透明过度绘制、可能是每帧在托管堆上分配导致回收、可能是某个物理体的碰撞层配错导致全场景遍历。手段就那几种,但你得先知道该用哪一种。注意:帧率优化最忌讳“凭经验猜”。我见过太多次“肯定是渲染问题”,结果关掉渲染画质帧率没变,最后发现是某个计时器每帧在拼字符串。1.2 内存与包体优化:让东西装得下、跑得开这一条在小屏幕上尤其致命。移动设备的进程可用内存是有硬上限的,中低端机往往在 1.5G 到 2G 这个量级徘徊,超了就是系统直接杀进程,玩家看到的是“闪退”,而不是“卡”。而包体则直接影响了下载转化率——用户在看到安装包大小的那一秒,就已经在决定要不要装了。内存优化的核心是峰值和常驻两个数。很多团队只看平均占用,结果进某个特效爆炸的场景瞬间峰值翻倍,直接崩。包体优化的核心是首包和增量,首包决定能不能装、愿不愿意装,增量决定更新体验。这两块的负责人通常是主程加技术美术,工作量集中在资源规范、压缩策略、加载卸载策略上。1.3 体验优化:让操作跟手、流程不烦这一层经常被技术同学忽略,但它对留存的影响往往比多两帧还大。所谓体验优化,包括输入到画面的响应延迟、动画过渡是否顺滑、镜头跟随是否让人晕、UI 点击反馈是否明确、新手引导是否能在一分钟内让人明白要干什么。举个最常见的例子:按钮点下去没有立即反馈,哪怕实际逻辑已经执行了,玩家的第一反应也是“没点到”,于是再点一次,造成重复操作。这类问题的修复成本极低,但需要有人真正把自己当玩家去玩一遍。1.4 商业与流程优化:让项目活下来最后一层不在代码里,在项目管理和商业设计里。比如付费点的出场节奏、广告的展示频次、日常任务的时长控制、版本迭代的排期。这些也叫“优化”,而且往往是老板最关心的那种。它们的共同点是:用数据说话,而不是用感觉说话。这里要多说一句,很多技术同学会觉得这一层“不纯粹”。但现实是,一个帧率 60 但没人付费的项目活不下去,一个帧率 45 但留存健康的项目能一直迭代。把技术指标放在商业目标的对立面,是新人最容易犯的错。优化类型核心指标主要负责人典型手段帧率优化帧时间 P95、长帧数量客户端程序合批、剔除、降分辨率、GC 控制内存包体峰值内存、首包体积主程、技术美术贴图压缩、按需加载、资源规范体验优化输入延迟、流程流失点客户端程序、策划手感调校、UI 反馈、引导精简商业流程留存、付费率、LTV策划、运营节奏设计、频次控制、A/B 测试2. 帧预算:所有性能讨论的起点没有预算概念的优化都是耍流氓。这一节把账算清楚,后面所有手段才有意义。2.1 把“多少帧”换算成“多少毫秒”帧预算的算法很朴素:单帧可用时间 1000 毫秒 ÷ 目标帧率。30 帧 → 33.3 毫秒60 帧 → 16.67 毫秒90 帧 → 11.1 毫秒120 帧 → 8.33 毫秒但这是理论上限,不是可用预算。实际要扣掉三块:操作系统和后台进程占用的时间、引擎固定开销(比如渲染管线的基础提交、动画系统的基础更新)、以及给波动留的余量。我一般的做法是打八折,甚至在中低端机上打七折。举例:60 帧目标,理论 16.67 毫秒,打八折是 13.3 毫秒。这 13.3 毫秒里,再按子系统切分:渲染 6 到 7 毫秒、逻辑与动画 3 到 4 毫秒、物理 1 到 2 毫秒、剩下 1 到 2 毫秒留给波动和系统抖动。当然这个比例随游戏类型变化很大,竞技类手游的逻辑占比会更高,场景重的开放世界则渲染占大头。提示:预算表要写下来,贴在项目文档里,并且每个子系统有明确的“超预算告警线”。没有这张表,评审时永远是“我觉得还能再塞点”。2.2 先定位瓶颈,再谈手段帧预算超了,第一反应不该是优化,而是定位。最基本的一刀是切分 CPU 侧和 GPU 侧。做法很直接:把渲染分辨率降到极低(比如降到 25%),如果帧时间几乎没变,说明瓶颈在 CPU;如果帧时间大幅下降,说明瓶颈在 GPU。反过来,把逻辑更新频率减半或者关掉一部分 AI,如果帧时间下降,那就是 CPU 逻辑侧的问题。这个判断的意义在于:CPU 瓶颈和 GPU 瓶颈的解决手段几乎不重叠。CPU 瓶颈你去做贴图压缩是白费劲,GPU 瓶颈你去优化脚本逻辑也是白搭。我见过一个组连续两周优化脚本,最后发现是阴影贴图分辨率开太高导致的填充率问题——一个参数的事。再往下细分,CPU 侧看主线程、渲染线程、工作线程的耗时曲线;GPU 侧看各渲染阶段的耗时分布,重点看基础几何、阴影、后处理、半透明这几块谁占得多。这套流程走完,基本能锁定到具体模块。2.3 平均帧率是骗人的,看 P95 和长帧这一点必须单独强调。平均 FPS 是最没有参考价值的指标,因为它会把长帧平滑掉。一局游戏平均 58 帧听起来很稳,但如果这 58 帧是“56 帧的流畅 偶尔一帧 200 毫秒”,玩家感受就是持续卡顿。正确的看法是三个数:P95 帧时间:95% 的帧都在这个时间以内,代表“大多数时候的体验”P99 帧时间:尾部体验,代表“最难受的那部分”长帧占比:超过某个阈值的帧占总帧数的比例,比如超过 33 毫秒的帧有多少我给项目定过的验收线大致是:目标 60 帧的机型上,P95 帧时间不超过 20 毫秒,长帧占比低于 0.5%,并且不允许出现单帧超过 100 毫秒的情况——因为那是肉眼可见的“卡一下”。统计周期也要注意。跑 30 秒的采样根本不够,起码要覆盖完整的战斗循环、场景切换、UI 弹窗这些场景,采样时长 5 分钟以上。短采样容易把冷启动和缓存命中混在一起,数据没有代表性。3. 渲染侧优化:最容易见效也最容易翻车渲染是绝大多数游戏的主要开销,也是优化手段最丰富的地方。但这一块也是最容易“改了没效果”或者“改完画面崩了”的地方。3.1 Draw Call 与合批的真实成本Draw Call 的本质是 CPU 向 GPU 提交一次绘制指令。它贵的不是 GPU,而是 CPU 侧的提交开销——每次提交都要做状态校验、参数准备。所以 Draw Call 的优化目标是减少 CPU 提交次数,方式是合批。合批能成立的条件很苛刻,大致是三条同时满足:使用相同的材质与着色器变体使用相同的渲染状态(混合模式、深度测试、剔除模式等)在提交顺序上连续任何一条断了,合批就断了。常见断点包括:中间插了一个使用不同图集的 UI 元素、给某个物体单独设了材质实例、排序被半透明队列打乱。数量上给个参考区间(不是绝对标准,只是经验值):中低端移动设备每帧控制在 150 到 200 个 Draw Call 比较安全,高端设备可以到 300 到 500。超过这个量级,CPU 提交就会成为可见的瓶颈。注意:合批不是越多越好。过度合并会导致一个大网格无法剔除,视锥外的东西也被提交。所以合批要配合空间分组,按区域而不是按全场合并。还有一点容易被忽略:动态合批的开销在 CPU 上。某些引擎提供的动态合批需要每帧在 CPU 侧做顶点变换,顶点数一大反而更慢。所以动态合批适合小物件,大物件要么静态合批,要么用实例化绘制。3.2 填充率与半透明:看不见的开销如果说 Draw Call 是“提交贵”,那填充率就是“画得贵”。它指的是每个像素被着色多少次。全屏特效、粒子、半透明叠加都是填充率杀手。一个直观的例子:屏幕上有一层全屏的雾效,再叠一层全屏的色调后处理,再加一片覆盖半个屏幕的粒子特效,那么这半个屏幕的像素至少被处理了三次。在低端 GPU 上,这足以让帧率掉 10 帧以上,而 Draw Call 只增加了 3 个,你在提交列表上根本看不出来。处理思路上有三条:减少层数:能合并的后处理合并,能烘焙进贴图的雾效就别实时算减小面积:粒子特效的发射范围收紧,避免大范围铺满屏幕;全屏后处理改用半分辨率渲染控制顺序:不透明物体先画(利用深度测试提前剔除),半透明后画,并且半透明内部按从近到远排序,减少无效覆盖半透明的排序还有个隐藏成本:排序本身是 CPU 侧的事,粒子数量上万的时候,排序耗时就能吃掉一两毫秒。这时候要考虑把粒子改成用顶点动画的网格,或者干脆减少粒子数量改用心跳式的低频更新。3.3 贴图与模型:内存和带宽的大头贴图是内存占用的第一大户,也是显存带宽的主要消耗者。算笔账就明白了:一张 2048×2048 的 RGBA8 未压缩贴图 2048 × 2048 × 4 字节 ≈ 16MB。如果项目里有 100 张这样的贴图,就是 1.6GB,这在移动设备上是不可能承受的。压缩之后就完全不一样了。用块压缩格式,常见的 4x4 块、每像素 8 比特的方案,压缩比是 4:1,同样一张图变成 4MB,100 张就是 400MB。如果是 4x4 块、每像素 4 比特的方案,压缩比到 8:1,只要 2MB 一张。代价是画质损失,尤其在法线贴图和带明显渐变的贴图上会出现块状伪影。所以贴图策略的核心是分类分级:贴图类型建议策略说明UI 图集高质量压缩,严格控制图集数量UI 常驻内存,必须精简角色主贴图中等压缩,按屏幕占比分级主角用高精度,杂兵降级场景贴图强压缩 流式加载可随场景卸载法线贴图谨慎压缩,必要时用双通道压缩伪影在法线上最明显遮罩/灰度图走单通道或合并通道一张图塞多个通道,省三份内存模型侧的重点是面数分级(LOD)。同一棵树,近处用高模、中距离用中模、远处用一张交叉面片甚至直接剔除。LOD 的切换距离要按屏幕投影面积来定而不是按世界距离,否则在广角镜头下会看到明显的跳变。还有一个很多人忽略的点:顶点属性不要塞太多。位置、法线、切线、两套 UV、顶点色、骨骼权重和索引,加起来每顶点可能超过 60 字节。十万面的模型就是 6MB 的顶点数据。能砍的砍,能用半精度的用半精度。3.4 阴影、后处理与实时反射的取舍这三样是“画面提升最明显、性能代价最大”的典型。它们几乎没有中间态,要么开要么关,要么高要么低。实时阴影的代价主要在两方面:阴影贴图的渲染(相当于把场景再画一遍)和阴影采样(每个受光像素都要查表)。降低代价的手段有:缩小阴影贴图分辨率、减少投射阴影的物体数量(远景物体不投影)、用级联阴影把精度集中在近处、把静态物体的阴影烘焙进光照贴图。后处理同理。全屏泛光、景深、屏幕空间反射、色调映射,一层层叠上去,每层都是全屏的像素处理。常见的做法是提供画质档位,低档位直接关掉景深和屏幕空间反射,只保留色调映射和抗锯齿。这里我要说个反常识的观察:画质档位对玩家体验的影响,远小于帧率稳定性的影响。同一个游戏,高画质 45 帧和低画质稳定 60 帧,后者评价明显更好。所以档位设计的思路应该是“优先保帧率,画质在预算内尽量给”,而不是“画质砍一刀换十帧”。4. CPU 侧:主线程、GC与逻辑开销GPU 侧的问题往往好定位,因为工具齐全、指标明确。CPU 侧的问题就阴险得多,尤其是内存分配导致的卡顿,现象和原因隔得很远。4.1 每帧分配是卡顿的头号嫌疑这个坑几乎所有用托管语言的团队都踩过。逻辑代码里随手一个new、一次字符串拼接、一次匿名闭包捕获、一次装箱,单次开销微不足道,但每帧累积起来,托管堆就会不断增长,触发垃圾回收。而回收的瞬间(尤其是不分代的全量回收)可能产生几毫秒到几十毫秒的停顿,表现就是一卡一卡的。判断方法很简单:看托管堆的分配曲线。如果每帧稳定增长几十 KB,那就是持续的分配热点。找到热点之后,手段是固定的几种:对象池:高频创建销毁的对象(子弹、特效、飘字、列表项)一律池化避免在更新循环里拼字符串:调试信息、显示数值的格式化要缓存或延迟避免闭包捕获:回调里捕获了外部变量就会产生分配,改成传参或缓存委托小心隐式装箱:值类型塞进 object 参数、字典用值类型做 key 但没实现比较器,都可能装箱容器预分配:列表扩容会分配新数组,容量能预估就提前给一段典型的池化写法长这样,思路比具体语法重要:public class BulletPool { private readonly StackBullet _idle new StackBullet(256); private readonly ListBullet _active new ListBullet(256); public Bullet Spawn(Vector3 pos) { Bullet b _idle.Count 0 ? _idle.Pop() : new Bullet(); b.Position pos; b.Alive true; _active.Add(b); return b; } public void Tick(float dt) { // 倒序遍历,避免 RemoveAt 造成索引错位 for (int i _active.Count - 1; i 0; i--) { Bullet b _active[i]; if (!b.Alive) { _active.RemoveAt(i); _idle.Push(b); // 回收而不是丢弃 } } } }提示:池子要有上限。不限量的池子会把内存吃满,最后变成“为了省 GC 而爆内存”,得不偿失。超过上限的回收直接丢弃,让 GC 去处理,反而更健康。4.2 对象池与分帧实例化池化解决的是“反复创建”的问题,分帧解决的是“一次创建太多”的问题。典型场景是关卡加载:一次性实例化两百个敌人和上千个场景物件,主线程直接卡住半秒。做法是把创建过程摊到多帧:用一个队列保存待创建的对象,每帧只处理固定数量(比如 20 个)或者固定时间片(比如 2 毫秒),超时就停,下一帧继续。这个技巧叫时间分片,几乎适用于一切“批量操作”:批量设置材质、批量生成寻路数据、批量解析配置表。代价是加载时间会略微变长,但玩家感知的是“没有卡顿的加载”,体验反而更好。这里的关键是别在战斗中途分帧,否则会出现“敌人陆续出现”的诡异现象。分帧要用在加载期或者过场期。4.3 逻辑与 AI 的时间片逻辑开销的大头往往是那些“每帧都在跑但没必要每帧跑”的东西。寻路重算、目标选择、视线检测、UI 数值刷新,这些操作大部分时候结果不变,没必要每帧算。常见做法是给这些系统设更新频率分级:玩家自身和近距离敌人:每帧更新中距离单位:每 0.1 秒更新一次远距离单位:每 0.3 到 0.5 秒更新一次,或者干脆冻结逻辑只保留动画屏幕外单位:完全冻结,只保留必要的状态推进这套分级带来的收益非常可观。一个同屏 200 单位的场景,如果全部每帧跑完整 AI,主线程轻松吃掉 8 毫秒;分级之后能压到 2 毫秒以内,而且玩家完全看不出区别——因为远处的敌人你本来也看不清动作。物理同理。碰撞层要配清楚,别让装饰物参与物理检测;能用地形数据算的别用碰撞体;静态碰撞体一定要标记成静态,否则每帧都要重建空间结构。5. 加载、包体与网络:另外两条容易被忽视的战线性能优化做得再好,加载慢、包太大、联机卡,玩家一样给差评。这两条战线经常被归到“运营”或“后端”那边,但它对体验的影响一点都不比帧率小。5.1 首包与加载时间首包体积的目标要看渠道和品类,但大致的原则是:越小转化越好,每多 100MB 下载转化就明显掉一档。所以首包必须只放“进游戏第一分钟必须用到的东西”:登录界面、新手关卡、基础角色、基础 UI。其余资源全部走增量下载或按需加载。这需要一套资源管理机制支撑:资源分级:首包资源、章节资源、活动资源分开打包依赖分析:加载一个角色要知道它依赖哪些贴图、动画、特效,避免加载到一半缺资源引用计数:资源用完要能卸载,卸载时机按“离开场景后延迟几秒”比较稳妥,太激进会导致反复加载预加载:在玩家看剧情、看结算的时候偷偷加载下一段,别等他点了“开始”才加载加载时间的构成也要拆开看:解压耗时、IO 耗时、实例化耗时、首帧渲染耗时(着色器编译)。很多时候加载慢不是 IO 慢,而是着色器编译慢——第一次见到某个材质,编译要几百毫秒,表现就是“加载完成但卡住一瞬”。解决办法是加载期做预热渲染,把所有会用到的材质变体提前编译一遍。注意:着色器变体爆炸是个隐蔽的坑。一个材质如果支持十几种开关组合,变体数量会指数增长,包体和编译时间都会失控。变体要严格控制在真正用到的组合上。5.2 网络同步的优化思路联机游戏的优化维度里,网络是独立的一块。它的核心矛盾是:同步精度和带宽之间的取舍。同步方案大致分两类:状态同步(服务器下发状态,客户端表现)和帧同步(只同步输入,各端本地计算)。状态同步的优化重点是压缩和降频:只同步变化了的字段,没变的不发位置用相对坐标和定点数压缩,别直接发浮点远处单位降低同步频率,或者只同步粗略位置视野外的单位不同步,靠兴趣区域管理状态快照做差量,只发增量帧同步的优化重点是确定性和输入延迟。所有逻辑必须走定点数,浮点在不同设备上结果不一致会导致不同步;输入要尽早发出,同时用预测和回滚掩盖延迟。延迟的表现也要区分对待。网络延迟高(比如 150 毫秒)但稳定,玩家的体验是“有点粘”但能适应;延迟忽高忽低(抖动),体验就非常糟糕。所以优化网络的第一优先级往往是降低抖动,比如加缓冲队列、平滑插值,而不是单纯追低延迟。6. 体验层优化:手感、UI与数值节奏技术指标都达标了,不代表游戏“好玩”。这一层经常被技术同学忽略,但它才是玩家真正在评价的东西。6.1 输入延迟与手感调校输入延迟指的是从手指按下到画面出现变化的时间。这个链路很长:触摸采样 → 输入事件分发 → 逻辑处理 → 动画切换 → 渲染提交 → 屏幕显示。每一环都会加几毫秒,累积起来可能超过 100 毫秒,玩家就会觉得“不跟手”。压缩延迟的手段:采样频率:触摸采样尽量每帧都读,别攒着减少中间层:输入事件别经过太多转发和队列立即反馈:按下瞬间先给视觉或音效反馈,逻辑结果可以晚几帧动画前置:攻击动作的前摇要短,判定框要早于视觉动作的“到位”帧后摇可取消:允许用下一个动作打断后摇,这是动作游戏手感的关键镜头的调校也是同理。第三人称跟随如果完全刚性绑定,画面会抖;加平滑又会有延迟感。常见的解法是位置用较快跟随、朝向用较慢跟随,并且对加速度做衰减,让镜头“有重量但不迟钝”。这些参数没有标准值,只能在真机上反复调,而且要针对不同灵敏度设置分别调。6.2 UI 的性能与易用性UI 是性能重灾区,因为它天然是半透明、频繁重建、层级复杂的。常见问题:每个元素单独一个图集,导致合批全断。解法是把同一界面的 UI 图打进一张图集文本频繁刷新,每次刷新都重建网格。解法是数值变化时做节流,或者只更新变化的部分列表一次性创建全部条目,一百个道具就创建一百个节点。解法是用循环列表,只创建可见区域的条目全屏遮罩叠多层,填充率暴涨。解法是合并遮罩层易用性方面的坑更多:按钮太小点不中、弹窗关不掉、加载时没有进度提示、操作没有撤销。这些不叫性能问题,但修复成本和收益比都远高于抠两毫秒。6.3 数值与付费节奏的“优化”这一层已经不是技术活了,但既然讲“游戏优化”,绕不开。新手前十分钟的节奏、第一次获得稀有物品的时机、日常任务的时长、付费点的位置,这些设计的调整往往能带来比技术优化大得多的数据变化。技术侧能提供的支持是数据埋点和实验框架:关键节点埋点、留存漏斗、A/B 分组、快速的配置热更新。有了这套东西,策划改数值不需要等版本,当天就能看到效果。这件事的价值,做过的团队都懂。7. 怎么把优化做成流程而不是救火上面讲的都是“怎么优化”,这一节讲“怎么让优化持续发生”。我待过的项目里,优化做得好的都不是靠某个高手,而是靠流程。7.1 建立基准场景与指标门禁第一步是有一个固定的基准场景:同一段战斗、同一个视角、同一批单位、同样的操作序列。所有人测性能都跑这个场景,数据才有可比性。没有基准场景,两个人报的帧率能差 20 帧,讨论就失去意义。第二步是把指标写进流程:每次提交代码自动跑基准场景,帧时间 P95、峰值内存、包体大小超过阈值就告警。门禁的阈值要留一点余量,不然天天误报,大家就都无视了。第三步是性能预算表跟着需求走。策划要加一个新特效,先看这个特效占多少预算;美术要加一套新模型,先确认面数和贴图尺寸在预算内。预算不是用来卡人的,是用来让取舍有依据的。7.2 真机矩阵与自动化采集模拟器和高端机跑得再好都没意义,必须上真机。机型矩阵不用铺太满,但要有代表性:档位定位关注点低端三五年前的入门机能不能跑起来,内存会不会爆中端主力用户机型帧率稳定性,发热降频后表现高端新旗舰高画质档位是否达标特殊大屏、折叠、低内存分辨率适配、内存上限自动化采集的价值在于批量。手动一台台测,一天测不了几台;自动化脚本可以一晚上跑完一轮,第二天直接看报表。采集的内容至少包括:帧时间分布、峰值内存、加载耗时、发热后的帧率衰减曲线。发热这一项特别重要,也特别容易被忽略。很多手机跑三分钟很稳,跑十分钟因为降频直接掉 20 帧。所以性能测试的时长要覆盖真实使用场景,不能只测一分钟。7.3 跨岗位协作的约定优化最难的其实不是技术,是协作。程序说美术资源超标,美术说你引擎不优化,策划说你们别砍我的特效。要避免这种局面,得提前约定几件事:资源规范文档化:贴图尺寸上限、面数上限、材质数量上限,写清楚,评审时对照检查提交前自检:提供一个检查工具,美术导出资源时自动检查规范,不合规直接报错性能评审进流程:新功能上线前走一次性能评审,而不是上线后被玩家骂了再回头改数据共享:性能报表对全组开放,谁都能看到自己负责的部分占多少我个人体会最深的一点是:优化要趁早,但不能太早。项目早期结构还在变,过早优化会白做;但等到上线前一个月才开始,又来不及。比较合理的节奏是:原型期不管,垂直切片期建立基准场景和预算表,量产期持续跑门禁,上线前做专项攻坚。这个节奏踩准了,优化就不会变成救火。8. 常见问题速查与踩坑实录最后这部分是我这些年攒下来的排查经验,按现象归类,遇到问题时可以对着表先过一遍。8.1 现象与原因速查表现象常见原因快速验证方式处理方向帧率整体偏低但很稳GPU 填充率或 Draw Call 到顶降分辨率看帧率是否上升降低后处理、减少半透明、合批每隔一两秒卡一下托管堆分配触发回收看托管堆分配曲线池化、消除每帧分配进入新场景瞬间卡死一次性实例化过多对象记录加载各阶段耗时分帧创建、预加载战斗后期越来越卡对象泄漏、容器无限增长看对象计数是否只增不减补回收逻辑、加计数上限只有部分机型卡机型特性(分辨率、GPU 型号)分机型对比帧时间按机型分画质档位跑十分钟后掉帧发热降频记录温度与帧率曲线降低持续负载、加动态分辨率首次进入某技能特效卡着色器编译记录首帧耗时加载期预热编译内存持续上涨直至闪退资源引用计数没减、贴图未卸载看资源常驻列表修引用计数、加卸载时机联机时角色瞬移网络抖动、同步频率低记录往返延迟与抖动加插值缓冲、提高关键状态频率UI 界面打开明显掉帧UI 图集分散、文本重建看 UI 阶段的 Draw Call合并图集、列表循环复用8.2 几条血泪经验第一条:先测量,再动手。我见过最典型的浪费是一个组花了两周做贴图压缩,最后帧率提升不到 2 帧,因为瓶颈根本在逻辑侧。每次动手前花半小时做切分测试,能省下两周。第二条:优化要有对照数据。改之前测一遍,改之后用同样的场景、同样的机型、同样的操作序列再测一遍。凭感觉判断“好像流畅了”是最不可靠的,我至少有三次以为优化有效,数据一对比发现是噪声。第三条:别一次改十个地方。改一处测一处,否则出问题不知道是哪一处引起的。性能优化和调试一样,变量要控制。第四条:动态分辨率是保底手段,不是首选。它确实能救帧率,但画面糊起来的观感损失很大,而且分辨率频繁跳变会让玩家觉得画面在“呼吸”。要用就设一个下限,并且用较慢的调整速度,别让它每帧都在变。第五条:别为了指标牺牲可维护性。有些优化写法极其晦涩,比如把手写汇编塞进热路径、把逻辑拆成状态机硬编码。这类代码三个月后没人敢动,最后反而拖慢迭代。优化的前提是代码还能维护,除非这一段真的十年不变。第六条:玩家反馈的“卡”和你测的“卡”可能不是一回事。玩家说的卡,可能是网络延迟、可能是加载慢、可能是 UI 响应迟钝,也可能确实是帧率。收到反馈先问清楚在什么场景、什么操作下卡,别一上来就查渲染。第七条:留出性能余量。上线前把预算用满的项目,上线后一定出问题——因为真实用户机型比你测试的机型更杂、后台进程更多、存储更满。留 20% 余量不是浪费,是保险。写到这里,我自己的习惯是每次新项目立项时,先把基准场景、预算表、机型矩阵这三样东西建起来,哪怕当时只有个白模。这三样东西建得越早,后面省的心力越多。至于具体每一项怎么调,那是手艺活,得在真机上一点点磨出来——工具会变,引擎会换,但“先测量、定预算、控变量、看尾部”这套思路,我用了这么多年还没过时。
解法)
