游戏优化拆解：帧率、卡顿与性能排查的平衡之道

做游戏这行被问得最多的一个问题就是“游戏中的优化指的是什么”。每次听到这个我脑子里冒出来的不是某个具体技术点而是一堆互相打架的账本画面要更好看、帧率要更稳、包体要更小、手机不能烫手、三年前的老机器还得能跑起来。这几个目标天然互相拉扯所谓游戏优化本质就是在这堆矛盾里找一个你能接受、玩家也能接受的平衡点而不是把某一项指标刷到极限。这篇内容我想把“优化”这个词彻底拆开讲清楚它到底在优化什么、怎么判断该优化哪里、常见的几个大头开销分别怎么处理、以及在真实项目里最容易踩的坑是什么。适合刚入行不久、被安排去做性能排查的同学也适合做了几年但一直靠“感觉”优化的老手——我自己就曾经靠感觉优化了两个月最后发现瓶颈根本不在我以为的地方。全文是经验向的具体的数值都是常见区间不同平台、不同引擎会有差异看思路比抄数字更重要。1. 先把“优化”这个词拆开它到底在优化什么很多人以为优化就是“让帧率变高”这个理解太窄了。帧率只是最终呈现出来的一个表面指标它背后是一整套资源调度和计算分配的结果。我习惯把优化目标分成四类每一类的衡量方式、排查手段、可用的手段都完全不同混在一起谈就会乱。第一类是流畅度衡量它的不只是平均帧率更重要的是帧时间的稳定性。第二类是响应速度包括输入延迟、场景加载时间、菜单切换的等待感。第三类是资源占用包括内存峰值、包体大小、显存占用、电量与发热。第四类是画质与表现的性价比也就是同样的算力预算下怎么让画面看起来更“贵”。这四类目标之间经常是冲突的。你把阴影分辨率调高画面立刻好看但显存和带宽开销上去了你把贴图压得很狠包体下来了但近景物体开始糊你为了省电把帧率锁到 30发热好了但操作手感变钝。所以真正专业的做法不是“全都优化”而是先明确这个项目当前最痛的是哪一项然后有取舍地分配预算。1.1 帧率、帧时间与卡顿的真实关系帧率是帧时间的倒数。60 帧对应每帧 16.67 毫秒90 帧对应 11.1 毫秒120 帧对应 8.33 毫秒。这个换算关系决定了你的性能预算有多紧张在 60 帧的目标下CPU 和 GPU 各自能分到的时间大概只有 12 到 14 毫秒剩下的要留给系统调度、垂直同步、后台任务。如果你在移动端还想留一点余量防发热降频实际可用预算可能只有 10 毫秒出头。但帧率是个平均值它会把卡顿藏起来。一秒钟里如果 59 帧都是 10 毫秒有 1 帧是 500 毫秒平均帧率依然接近 59可玩家的体感就是“卡了一下”。所以真正要盯的是帧时间曲线尤其是 P99 和最大值。我的习惯是在性能面板上同时看三个数平均帧时间、95 分位帧时间、单帧最大值。平均值决定整体手感分位数决定有没有“顿挫感”最大值决定会不会出现明显的卡死。还有一个容易被忽略的点卡顿的成因往往和低帧率的成因完全不同。持续低帧率通常是渲染压力大或者逻辑太重而偶发卡顿更可能是资源加载、垃圾回收、着色器编译、动态内存分配这类“尖峰型”开销。你拿一个持续低帧的项目去做 Draw Call 优化可能一点效果都没有因为它的瓶颈在别处。1.2 优化的三本账CPU、GPU、内存我习惯让团队里每个人都记住这三本账遇到问题先判断是哪本账超支了。CPU 这本账管的是逻辑更新、物理模拟、动画计算、场景管理、渲染提交。它的特点是单帧内的工作必须串行完成所以最怕的是“某个模块突然变重”。GPU 这本账管的是顶点处理、光栅化、像素着色、后处理。它的特点是高度并行所以最怕的是“总工作量”和“带宽”而不是某一次调用慢。内存这本账管的是资源驻留、临时对象、缓存策略它最怕的是碎片和峰值。判断哪本账超支的方法很朴素看 GPU 时间和 CPU 时间的比例。如果 CPU 帧时间远大于 GPU 帧时间说明瓶颈在逻辑侧你去降分辨率毫无意义反过来如果 GPU 时间顶着帧预算那你再怎么优化代码逻辑也没用。这个判断只要做对一次能省下好几周的无效工作。2. 为什么优化必须从“测量”开始我见过太多项目组的优化流程是这样的老板说卡主程说那我们把贴图压一压程序说那我们把阴影关一关美术说那我们把特效减一减。三轮下来帧率涨了两帧画面丑了一半大家还很累。问题出在第一步——没有人真的测量过瓶颈在哪。性能排查的第一原则是先定位再动手。定位的核心是分层排除。我会先做一个最极端的测试把渲染全部关掉只留逻辑更新看 CPU 时间是多少再把逻辑更新冻结只渲染一个空场景看 GPU 时间是多少。这两个数字一出来问题的轮廓基本就有了。2.1 性能分析工具的选择与使用不同平台的工具生态差别很大但思路是通用的。我一般会分三层来看层级看什么典型手段判断依据宏观层整帧时间分布引擎自带性能面板、系统级帧率统计CPU/GPU 谁顶着预算中观层各模块耗时占比分段打点、渲染管线各阶段计时哪个阶段超过 30%微观层单次调用开销逐 Draw Call 分析、着色器指令统计是否有明显异常项宏观层最容易被忽略因为它太简单了。但我强烈建议每次优化前先花十分钟把宏观数据记录下来形成一个基线。没有基线你后面所有改动的效果都无法验证——你可能优化了 A同时不小心恶化了 B两相抵消最后得出“优化没用”的错误结论。中观层的打点要注意一点打点本身有开销。如果你在每帧里插了几十个时间戳查询尤其在移动平台上这个开销可能吃掉你本来就紧张的预算导致测出来的数据是失真的。我的做法是把打点做成可开关的编译选项只在性能构建里打开并且在分析时把打点开销本身也估算进去。微观层是最后才做的。只有当你知道瓶颈在某个具体阶段才值得去逐调用分析。上来就把 Draw Call 列表拉出来看几千条除了眼睛疼没有别的收获。2.2 建立可复现的基准场景这一条我要重点强调因为它比工具重要得多。优化最怕的是测量结果不可复现。你今天测出来 45 帧明天同样的机器同样的版本测出来 52 帧那所有结论都是不可信的。我的做法是固定一个“基准场景”选一个能代表游戏最重负载的真实关卡片段固定摄像机路径、固定角色动作、固定特效触发时机用脚本自动跑一段固定时长的回放记录帧时间序列。这个场景要满足几个条件能覆盖主要玩法、能触发最重的渲染负载、跑一遍不超过两分钟、不依赖人工操作。有了这个场景任何一次改动都可以快速验证。我甚至会把基准场景的结果做成每次构建自动出的一份报告只要帧时间 P95 超过了阈值就报警。这套东西搭起来大概需要两三天但它能在后面的几个月里反复救你。注意基准场景一定要用真机跑不能只看编辑器里的数据。编辑器往往有额外的开销而且图形 API 的行为和真机差别很大编辑器里流畅不代表真机流畅反过来也一样。3. CPU 侧的优化逻辑、提交与内存管理CPU 侧的问题通常不是“算得慢”而是“做了太多没必要做的事”或者“在错误的时机做了事”。这个区分很重要因为前者需要算法层面的改动后者往往只需要调整结构。3.1 Draw Call 与批处理先把提交次数压下来Draw Call 是渲染提交的基本单位每一批使用相同材质和相同渲染状态的物体可以合并成一次提交。它的开销主要来自两个部分一是引擎到图形 API 的调用开销二是渲染状态切换带来的开销。状态切换的代价在不同平台上差异巨大所以你会看到同样的游戏在桌面端跑得很轻松在移动端却卡顿。预算方面经验值大概是这样的移动端希望控制在 100 到 300 次提交之间桌面端可以放宽到一两千次但这只是粗略参考具体要看目标机型和图形 API 的实现。真正准确的做法是在你的基准场景里做一组对照实验人为把提交次数翻倍看帧时间涨多少就能算出每次提交在这个项目里的实际成本。降低提交次数的常见手段按性价比排序合并材质把多个小贴图打包成图集让原本需要不同材质的物体可以合批。这是收益最大的一步通常能砍掉一半以上的提交。静态合批把不会动的场景物件预先合并成一个大网格运行时只提交一次。代价是内存占用增加、无法单独剔除所以要挑那些确定长期可见的物体。实例化渲染同一模型画很多份的时候草木、子弹、粒子用实例化把数据打包提交这个几乎是必做的。减少渲染状态切换把使用相同状态的对象排在一起渲染避免来回切换。排序逻辑本身也是 CPU 开销要权衡。有个反直觉的点合批不是越激进越好。把一个巨大的静态合批拆成几个中等大小的批次往往比合成一个整体更好因为可以保留视锥剔除和遮挡剔除的能力。我有一次把一个关卡的场景全合成了三个巨大网格提交次数降到了两位数结果帧率反而掉了——因为摄像机一转三个网格全都在渲染剔除完全失效。3.2 托管堆与垃圾回收卡顿的隐形杀手如果你的项目用的是带自动内存管理的运行时垃圾回收几乎必然是偶发卡顿的头号嫌疑人。它的特点是平时看不出来一到关键时刻给你来一下几十毫秒的停顿而且停顿时间和堆上的存活对象数量正相关——也就是说游戏运行越久卡顿越明显。排查方法很直接看每帧的托管堆分配量。理想状态下稳定运行时每帧的分配应该接近零。如果每帧稳定分配几百 KB 到几 MB那就是在给垃圾回收器喂料。常见的泄漏源我按出现频率列一下分配源典型场景处理方式字符串拼接每帧更新 UI 文本拆分静态部分与动态部分缓存格式化结果装箱值类型被当作通用对象传递用泛型容器替代通用容器避免隐式转换闭包与委托每帧注册回调、临时 Lambda缓存委托实例避免捕获外部变量临时数组与列表物理查询、寻路、射线检测用对象池复用或改用不分配的重载接口迭代器每帧遍历集合注意部分遍历接口会产生分配改用索引遍历对象池这个东西听起来很土但在实战里极其有效。子弹、特效、飘字、伤害数字、临时碰撞体凡是“高频创建销毁且结构固定”的对象都值得进池子。我自己做过一个项目光是给飘字加了个池子卡顿投诉就少了一大半——因为战斗最激烈的时候恰恰是飘字最多的时候也恰恰是玩家最不能容忍卡顿的时候。3.3 逻辑更新的分帧与降频不是所有逻辑都需要每帧更新。AI 决策、寻路重算、UI 数据刷新、小地图更新这些通常可以降到每秒 10 次甚至 5 次。这个思路叫分帧处理做法是把一个大任务拆成若干小片分摊到连续多帧里执行每帧只做一部分。举个具体的例子一个场景里有 200 个 NPC每个 NPC 每帧要做一次距离检测和状态判断假设单个开销是 0.02 毫秒200 个就是 4 毫秒直接吃掉了四分之一的 60 帧预算。改成每 10 帧更新一轮、每帧只更新 20 个单帧开销降到 0.4 毫秒而玩家完全感知不到延迟——因为 NPC 的状态变化本来就不是毫秒级的。分帧也有代价任务完成的总时长变长了某些情况下会出现“反应慢半拍”的手感。所以战斗相关、输入相关、镜头相关的逻辑绝对不能分帧分帧只适用于那些对时间精度不敏感的模块。4. GPU 侧的优化填充率、Overdraw 与着色器GPU 侧的瓶颈比 CPU 侧更隐蔽因为它没有一个“调用次数”这样直观的计数器。很多人第一反应是“降多边形”但实际上现代 GPU 处理顶点早就不是什么难事真正的杀手通常是像素级的开销和带宽。4.1 Overdraw看不见的像素浪费Overdraw 指的是同一个像素在一帧内被重复绘制的次数。天空盒画一遍、地面画一遍、建筑画一遍、角色画一遍、粒子再叠几层最后这个像素可能被写了七八次。每次写入都要走一遍完整的像素着色和混合代价相当可观。算一笔账会更有感觉1080p 分辨率下假设全屏平均 Overdraw 是 4 层每层写一次 8 位四通道的颜色数据那一帧的写入量就是 1920 × 1080 × 4 字节 × 4 层约 33 MB。按 60 帧算每秒就是 2 GB 的写入带宽这还没算深度缓冲、纹理采样和各类后处理。移动平台的显存带宽本来就不宽裕这个数字足以让帧率崩掉。降低 Overdraw 的手段效果从强到弱调整渲染顺序先画不透明物体从近到远让被遮住的像素提前被深度测试拒绝。透明物体必须从远到近这个是硬性的没法改。剪裁掉不可见部分粒子特效是 Overdraw 重灾区很多特效的贴图有大片透明区域这些区域依然要跑像素着色。把贴图的透明区域裁掉、把特效的发射范围收紧收益立竿见影。优化 UI 层级全屏半透明遮罩、多层叠在一起的面板、带模糊的全屏背景这些都是隐形的 Overdraw 大户。有时候一个看似无害的“全屏渐变蒙层”就能吃掉好几毫秒。控制后处理链长度每加一个后处理就是一次全屏 pass bloom、景深、色调映射、抗锯齿、屏幕空间反射叠起来轻松十几次全屏读写。4.2 着色器与后处理复杂度的真实代价着色器的开销和指令数、纹理采样次数、数学运算类型都相关。经验上移动端一个像素着色器里的纹理采样次数最好控制在 4 次以内超过之后开销增长很快。一些看起来“免费”的操作其实很贵三角函数、幂运算、归一化、条件分支在大量像素上执行时都会被放大。我遇到过一个典型例子某个材质为了做“边缘发光”在像素着色器里对每个像素做了三次不同方向的法线采样再混合。单看这个材质没什么问题问题是这个材质被用在了场景里几百个小物件上累积起来占掉了整个 GPU 预算的三成。后来改成用一张预烘焙的边缘贴图视觉效果差别很小开销直接降到原来的十分之一。后处理方面我的原则是每一个都要能说清楚它在解决什么问题。很多项目的后处理链是一层层加上去的每加一个都“感觉画面更好了”但没人回头算过总成本。定期做一次“关掉所有后处理”的对比你会发现有些效果对画面的贡献远小于它的开销。注意着色器变体数量也是个隐形成本。材质的关键字组合会编译出大量变体导致包体膨胀和首次使用的编译卡顿。控制关键字组合数量、在加载阶段预编译、把高频变体打进包体这几步能显著减少“第一次遇到某种效果就卡一下”的情况。5. 资源与内存纹理、模型、包体与加载资源侧的优化往往是最容易被拖延的因为它需要美术、程序、策划一起配合而且改动周期长。但它的收益也最大尤其是对包体大小和加载时间的影响。5.1 纹理压缩与 Mipmap 的内存账纹理通常是显存占用的第一大户。算一下就知道为什么一张 2048×2048 的未压缩四通道 8 位纹理占 2048 × 2048 × 4 字节 16.8 MB。听起来还行但一个场景里几十上百张这样的纹理加上 Mipmap 增加的约三分之一很容易就上到几百 MB。换成压缩格式之后差距非常夸张。以常见的块压缩格式为例4×4 块、每像素 8 位的方案占用量直接降到原来的四分之一也就是 4.2 MB加 Mipmap 约 5.6 MB。视觉上在正常观看距离几乎看不出差别。这个转换几乎没有理由不做。纹理规格未压缩压缩后约加 Mipmap 后的压缩版本1024×10244.2 MB1.0 MB1.4 MB2048×204816.8 MB4.2 MB5.6 MB4096×409667 MB16.8 MB22.4 MBMipmap 本身的取舍也值得说。它会增加约三分之一的内存但能显著改善远景的闪烁和摩尔纹同时提升纹理缓存的命中率——因为远处的小物体采样的是小尺寸的 Mip 层级缓存友好度大幅提升。对于绝大多数场景纹理Mipmap 是必须开的只有 UI 贴图和某些特殊用途的贴图可以考虑关掉。5.2 模型、动画与包体控制模型的成本主要在两方面顶点数据和骨骼动画。顶点数本身在现代 GPU 上不算大问题但顶点属性越多位置、法线、切线、多套 UV、顶点色带宽占用越高。合并属性、减少不必要的通道、用更紧凑的数据类型都能省下可观的开销。骨骼动画的开销容易被低估。一个角色几十根骨骼每帧要做蒙皮矩阵计算几十个角色同时在屏幕上CPU 那边就是实打实的开销。常见的优化手段包括远处的角色降骨骼数量、降低动画更新频率15 帧的动画更新对远景角色完全够用、把不需要动的角色切换到静态姿势。包体控制方面我觉得最有效的不是压缩技术而是资源清理机制。项目做久了一定会积累大量废弃资源改版前的旧模型、试做但没采用的特效、重复的贴图。我习惯每个大版本做一次资源审计把没有被任何配置引用的资源列出来通常能清出 10% 到 20% 的冗余。这件事没什么技术含量但收益非常直接。5.3 加载时间把等待藏起来加载时间的优化思路和帧率优化完全不同它的核心是并行和隐藏。把资源按使用时机分优先级首屏只加载必须的剩下的在后台异步补把解码、解压、上传显存这些耗时操作分散到多帧在加载过程中插入有意义的过场或可交互内容让玩家的主观等待感降低。我个人的经验是加载时间超过 8 秒玩家的流失率就会明显上升超过 15 秒基本就是灾难。但这个数字不是绝对的如果加载过程中有好看的过场动画或者可以操作的内容玩家能容忍更久。所以与其死磕加载速度不如同时考虑“加载体验”。6. 常见问题与排查实录这一节我把这些年遇到过的典型问题整理成一份速查表都是真实踩过的坑按症状分类方便对着查。症状最可能的原因排查方向处理方式整体帧率低且平稳GPU 像素开销过大逐层关闭渲染特性做二分降 Overdraw、简化着色器、减少后处理偶尔卡顿几十毫秒垃圾回收、资源加载、着色器编译记录卡顿帧的时间点对照日志减少分配、异步加载、预编译变体战斗时掉帧、平时正常特效 Overdraw、单位数量激增单独压测战斗场景特效降级、单位分帧更新、距离裁剪只有某些机型卡特定硬件或驱动的性能差异分机型建立性能档案按机型分级画质动态降级玩久了越来越卡内存泄漏、资源未释放长时间挂机监控内存曲线排查引用持有、加资源生命周期管理首次进入某场景卡着色器编译、纹理上传记录首次进入的耗时分解预热、加载期预编译、渐进式上传帧率够但手感发飘输入延迟、帧时间抖动测输入到显示的端到端延迟减少缓冲帧数、稳定帧时间、优化输入采样6.1 一个真实的排查过程有个项目反馈“中端机型在特定关卡会莫名其妙掉到二十几帧但高端机型完全正常”。第一反应是 GPU 压力大于是降了阴影和分辨率结果几乎没变化。这时候就应该意识到判断错了方向。改成用分层排除先关渲染帧率恢复正常说明确实是渲染相关再只保留不透明物体正常加上透明物体掉帧加上粒子特效大幅掉帧。定位到粒子。进一步看粒子的参数发现这个关卡的特效为了做“雾气弥漫”的效果用了一个覆盖大半屏幕的大型粒子而且粒子数量不少Overdraw 直接爆掉。问题在于这个特效在高端机型上看不出问题因为它的 GPU 填充率富余很多。这就是为什么性能测试必须覆盖目标机型的最低配只在高配机器上测等于没测。最后的处理是把大范围雾气改成低分辨率的屏幕空间效果用一个全屏 pass 替代大量粒子叠加视觉上更柔和开销降到原来的五分之一。6.2 几个反直觉的经验第一条降分辨率不是万能药。它只对像素填充率瓶颈有效如果瓶颈在 CPU 逻辑或者顶点处理降分辨率一点用都没有。我见过有人为了提帧把渲染分辨率降到 0.5 倍画面糊得没法看帧率只涨了 2 帧。第二条帧率上限不是越高越好。移动端如果无脑放开帧率GPU 会一直满负荷跑发热上来之后触发降频帧率反而会剧烈波动。锁一个稳定但略低的帧率体感往往比忽高忽低的高帧率更好。第三条优化要留出余量。你在实验室里测出来刚好 60 帧那上线之后一定会有大量玩家跑到 45 帧因为真实设备的温度、后台应用、存储碎片都会影响性能。我的习惯是让基准场景跑出 20% 以上的余量再交付。第四条不要为了跑分优化。有些优化只在特定测试场景里有效一旦进入真实玩法就失效甚至带来副作用。优化的验收标准应该是真实玩法下的体验而不是某个跑分数字。7. 我在实际项目里的一些做法和体会最后分享几个我自己一直在用的习惯都是踩坑之后总结出来的不一定适合所有团队但思路可以参考。第一个习惯是给每个平台定一份性能预算表写清楚 CPU 多少毫秒、GPU 多少毫秒、内存多少 MB、包体多少 MB、加载多少秒然后每个版本对照检查。这份表不需要很精确但必须有因为它能让所有人对“什么叫做超了”有共同语言。没有这份表的时候美术加一个特效、策划加一个系统、程序加一段逻辑每个人都觉得“就一点点”加起来就爆了。第二个习惯是优化优先级按“收益除以成本”排序而不是按“技术含量”排序。有些优化特别朴素比如把一张用不到的 4K 贴图换成 512收益巨大成本极低有些优化很酷比如自己写一套剔除算法收益可能只有 1 毫秒但要花两周。前者应该立刻做后者要看有没有更值得做的事。第三个习惯是每次优化都记录“改了什么、为什么改、效果多少”。这件事听起来很形式主义但它的价值在于半年后你回头看能知道哪些手段在这个项目里真的有效。我自己有一份持续维护的优化日志里面记录的很多结论都是反直觉的比如某个项目里降阴影分辨率的效果远不如降阴影更新频率因为瓶颈在 CPU 侧的阴影渲染提交而不是 GPU 的像素填充。第四个习惯是在开发早期就把性能监控埋进去而不是等上线前再补。真机上的帧时间、内存、发热数据如果能持续采集并汇总你会发现很多问题在爆发之前就有苗头。等到玩家投诉再查成本和难度都是几倍。说到底游戏优化这件事没有银弹它是一个持续的、需要全团队配合的工程习惯。技术手段只是工具真正决定成败的是你有没有建立“测量—定位—改动—验证”这个闭环。我见过技术很强的团队因为不做测量而反复走弯路也见过技术一般的团队靠着严格执行这套流程把项目调得相当稳。前者缺的是纪律后者赢的也是纪律。