常说的游戏优化是哪些方面的优化？

发布日期：2024-03-12 13:32浏览次数：98

比如听朋友说某国产3D网游优化做的烂，即使是顶级配置机器也无法全特效流畅运行。这里的优化指的具体是哪些方面？

几个方面吧。按重要程度：

用户体验

故事流程

交互操作

游戏性能

游戏体积

……

其中用户体验很笼统，甚至包含了故事流程，交互操作，视觉效果（美术+技术），游戏性能等。

按你说的配置问题，那就是侧重于游戏性能的单机（纯客户端，基本不涉及网络）一侧。

在这一块，也包含了很多方面（不分轻重，想到啥写啥）：

程序运行效率，程序语言执行效率，模型优化程度，贴图/材质优化，数据解析优化，场景优化（灯光等），算法优化，以及其他暂时没想到或者想不起来的优化。

程序运行效率的优化大家都明白，不过很多程序员其实了解不深。这不光是一个算法，更是一个、架构设计/流程设计思路，和语言设计思路的问题。算法只局限于一个局部。而架构设计额和流程设计则影响了整个程序运行效率的全部。

纯客户端架构方面（这与服务器端的架构非常不一样），比如是否存在进程之间的协作、同步、数据传输，以及其效率如何；是否有不用语言之间的来回穿透，比如Java的游戏通过JNI频繁调取本地C/C++动态库处理数据，等等。

流程包括流程的合理性。比如，是否为了获取一个计算并不麻烦的整数，然后创建了一大堆中间临时对象等。比较贴切的例子（但也很无关）是数据库的多表联合查询。在网络公司，很多事为为了提高效率而故意的破坏范式，增加冗余数据或者表合并，就是为了尽量避免多表联合查询。

语言方面，你是否是存Java的？还是Python的？还是.Net的？Java有没有用JNI？有没有多次频繁穿透JNI？是否使用了C/C++？是否使用了顶点渲染？等等。以及是否为了OOP而OOP？（过多的抽象，过多的class。大部分的class极其简单和破碎，而且还是非静态的，需要来回创建。有必要么？）

开发人员的技术功底。

模型优化：

不必要的细节是否都被删去？模型定点是否在不明显影响渲染质量的情况下，降到最少？（每个顶点都需要被计算的。同一个人物模型，3000个顶点和100个定点，在同样的光照和材质下，哪个渲染更快？）

贴图/材质优化：

贴图是否尺寸恰好？不需要（或尽量避免）程序进行缩放？能不用透明材质的地方是否避免使用？能用贴图代替的镜面材质是否使用贴图代替？……

数据解析优化：

本地方面，数据存储的（对象）模型设计是否高效？使用JSON还是binaary存储数据？网络方面是否使用了xml这样体积膨大效率超级低下的格式进行传输？

能用float的地方是否还在使用double？能用int的地方是否还在使用float？三角函数/开方等的计算是否经量避免？用的矩阵函数库，或自己写的矩阵计算是否高效？

计算过程是否可以优化？减少中间环节，直接套用结果公式？

……

场景：

灯光/光源等是否优化，且尽量减少？每多一个光源，就得多计算一组光照，包含折射烦反射等等~~场景是否尽量切割，避免同时运算过多的模型和材质对象？是否使用了LOD？或者引擎自动生成，或自己自做的LOD模型效率如何？等等……

大致就这样吧，服务器端和非客户端性能相关方面有需要再问再答。吃饭先~~（马上该1点上班了）~~

优化几乎涵盖游戏开发的所有方面（我看这题目的其他答主就已经快分门别类地把底层到前端，从技术开发到游戏内容等方面都说尽了）

因为优化本身就是一个不确指的泛泛的概念，可以说任何在已经完成或初步完成的功能性开发基础上的调优，改善，修正，美化，填充，Debug，只要不是推翻重制或彻底的增添删除，都算优化（对应的反义词是劣化，一般来说我们不认为商业产品中会出现任何有意劣化的行为），其字面意思本身就是指使现有的东西变得更好，而整个产品开发的方向不就是这样吗。

而且这个优化的范围远不止游戏底层代码，整体架构；从数据储存，到外部接口；从游戏界面，到操作方式；从声画效果，到特效表现；甚至游戏体验，关卡难度，新手引导，任务设计。任何方面的调整改善都算作”优化“。

而且我们在开发中也确实会这么阐述——优化一下封包，优化一下前期，优化一下画面，优化一下特效，这些说法都是很泛泛的，往往只有在双方对实际需求非常清楚的情况下，这个说法会作为对一系列需求的统称：例如优化一下前期可能是指包含有从进入画面到login的方式，从角色建立到新手引导的一系列需求的统称而已。

的确，比如游戏的3d引擎效率低下、显存或渲染的资源占用过多、64位环境下Dx10支持不好、某个API存在Bug、特定显卡或驱动有兼容性问题。等等等问题都会造成画面fps大幅下降，进而造成不流畅，这些问题也都可以通过”优化“解决。

但并不是说“没优化好”这个非常不确切的概念，就可以变成一个问题的原因。

还是得说，您朋友的描述本身就没什么道理，类比于"这桌菜就是烹饪不行所以不好”，听起来好像没错，实则什么都没说。是原料不佳，还是加工不良，是火候不行，还是是搭配不当，是调味出了岔子，还是色香不够诱人？这些都可以算作“烹饪”的一个方面吧。

用可以涵盖全体的原因，描述一个具体的问题，其实是不那么合理的叙述方式。实际上也无助于解决问题。

”优化“是游戏开发过程中的一个重要组成部分，同时也为了感谢

@谢熊猫君

的精彩食谱，我来答一答吧。

本质上，游戏是一种实时交互程序。两个关键字——“实时交互”和“程序”。所谓“实时交互”就是计算机要在很短时间内对用户的输入做出反应，由于现代游戏主要都是基于图像和声音，所以在这个短时间内游戏引擎需要对大量的数据进行更新并输出。一般游戏的更新频率是30fps，也就是每秒钟内要完成30个数据更新周期，才能达到交互的实时感。帧数可以说是游戏程序运行效率的直接体现。所以对于游戏程序，帧数至关重要；所谓“程序”就是游戏必定是运行在某种硬件之上，一定会受到硬件的制约。在诸多限制中，内存是重要的一环——内存溢出的直接后果就是程序异常中断，这在商业游戏中是不可接受的质量问题，问题的性质远比低帧数严重。同时现代游戏的海量内容又要求尽可能塞满内存。所以对于游戏程序，内存的管理至关重要。

从广义上来说，如何让计算机程序运行的更快，处理的数据更多，都算得上是“优化”；但是从游戏开发的角度看，对于已有的成型的项目而言，优化就是两大方面——帧数和内存。

在展开详细谈之前我先要提一下不同平台和不同渠道对于优化的影响。按照“优化”要求的严格程度排序，有高到低，大致上是审核严格的封闭平台——比如Console游戏；审核较松的封闭平台——比如苹果的App Store；有审核的开放平台——比如Steam；完全无审核的开放平台——比如PC和Mac的自由开发原野。

Console平台的游戏审核最严——这是有任天堂从“雅达利大崩溃”以来首创的做法，Sony和微软也采取了同样的方法。目的就是为了保证自己平台上游戏的高质量。Console都是封闭平台，硬件规格延续数年不变，这创造了稳定的开发环境，让开发者可以通过数年累计出专门的优化经验和技巧。另外Console平台一般销量巨大，对质量和稳定性要求很高——当你的产品要呈现给几百万几千万人，创造几亿的销售额，“一流的体验”是很自然的事情，而优化正是用来保证这一点。

手机和平板其实也属于封闭平台——用户无法替换任何硬件部分，但是数代并存和厂家众多造成了相当数量的硬件规格同时存在。相对的iOS平台硬件比较整齐，分辨率相对统一，App Store的审核相比较Console宽松不少，但仍有一定要求。而Android阵营则比较混乱一些，硬件参差不齐，App销售平台纷繁芜杂，审批更加宽松。另外手机游戏的开发投入规模一般比较小，也不太会有过多的精力投入优化之中。总之优化的要求是Console>iOS>Android。

开放平台一般指的都是桌面系统，特别是PC。各种硬件规格的排列组合可以几乎说是无限多，所以相对的每个特定性能区间的配置获得优化的注意力是很有限的，除非资金充裕如暴雪，否则很少有公司会做到面面俱到，给主流配置优化一些，过高或者过低很有可能就忽略了。有审核的游戏发布平台会好一些，比方说Steam，会有起码的要求，无审核的完全就靠开发者对产品质量的追求了。国产3D网游就是属于末一种（新闻出版署的审核是政治审核和内容审核），在时间和成本压力下，很有可能出现问题描述中的情况。

(待续）

主要针对手游优化方面做些回答，希望能有帮助。

评价一款游戏的性能好坏，我们通常会用到帧率（每秒钟的渲染帧数）作为主要参考指标。当然，手游这块功耗也是一个重要因素，但主要还是看帧率。像MOBA、FPS类的游戏，帧率肯定是越高越好，出于功耗与显示设备的限制，一般跑满也就在60fps左右。而像其他的棋牌、放置类游戏，帧率只要有30fps就足够了。

性能优化要谨遵二八原则：20%的代码影响80%的性能瓶颈。因此要合理地找出性能瓶颈所在，避免负优化。下面就三个比较常见的方面：bandwidth、drawcall、overdraw 来分别阐述渲染阶段是如何造成性能瓶颈以及对应的解决办法。

移动端的GPU设计之初，优先注重的肯定是功耗问题，然而在实际渲染一帧图像的时候，对功耗影响最大的因素就是带宽（bandwidth）。

为什么会是带宽呢？

这是因为出于空间的考虑，手机芯片的设计上采用了SoC架构，因此内存与显存实际上是共享在一块物理内存上的，在OpenGL ES规范中，内存与显存中的数据却不能共享。在有限带宽的前提下，我们不妨计算一下，一台分辨率为1920*1080的移动设备，按60帧率来算，每秒钟1次overdraw产生的数据量为：

1920 * 1080 * 32 * 60 / (1024 * 1024)=3.7 Gb

如果遇到了大量的半透明物体或是粒子特效，那么数据量上可能会成倍的增长。

如此大量的数据存储在显存的FrameBuffer中，GPU要以高昂地代价频繁地去显存访问FrameBuffer里的数据，这显然是很难接受的。因此在移动端的显卡硬件上，想到了一种优化方式，就是将FrameBuffer拆分成不同的小块(tile)，每次可以先将这一小块的数据放到访问速度更快的On-Chip Memory中去，GPU会先从tile中一块块地去进行渲染，等整体渲染完成之后，再将数据搬回显存上。

我们将这种模式称为 TBR（Tile Base Rendering）。

然而在TBR模式下，可能存在着这样的一个问题，如果对于CPU每一次传来的绘制命令都进行渲染的话，那么GPU必定会频繁、大量地对tile数据进行搬迁操作，这显然是不可接受的。为了解决这个问题，TBR一般的策略是：对于CPU提交的Draw Call请求，先只做顶点处理，将Vertex Shader计算的结果暂存到一个叫 FrameData 的地方。等到执行 Swap Buffer 的时候，再对整个数据做光栅化，进行绘制。

既然是等所有的FrameData数据处理好后一次性进行绘制，GPU硬件上便进一步做了些延迟渲染相关的优化。例如iOS上的PowerVR，专门有一个叫 ISR 的硬件，会去处理FrameData中那些诸如深度测试、模板测试没有通过的数据，尽可能地只去渲染那些最终影响FrameBuffer的物体。

我们将这种模式称为 TBDR（Tile Base Deffered Rendering）。

基于移动端GPU特有的架构模式，需要我们做哪些优化方面的事情或是注意事项呢？

使用压缩的纹理格式，如ETC、PVR等
打开Mipmap（内存与带宽的权衡）
减少Shader中的采样次数，尽量合并一些通道图
控制总顶点数量
不要频繁地切换FrameBuffer（后处理效果）

手机上CPU与GPU的关系，就好像客户端与服务端的CS架构。所谓Drawcall，可以理解为Client端的CPU向Server端的GPU发送的一次绘制命令，同时会传递需要被渲染的图元列表。现代GPU就为了高并发处理数据而生的，一般Drawcall的绘制数据计算起来应该还是绰绰有余。但由于CPU传递的渲染数据得通过PCI-E总线才能传到GPU显存中的全局存储区域，频繁且大量地提交绘制相对简单的绘制命令，会造成GPU端的“ 产能过剩 ”，CPU无法及时提供渲染数据而造成性能瓶颈。

与此同时，TBR架构下优化过的GPU，会先将顶点数据存储到FrameData队列，如果Drawcall数量过多，且顶点数量巨大，万一FrameData承装的内存放不下了，就得先将数据移动到别处，进而大大降低了访问速度。这也是我们需要控制DrawCall数量和顶点数的一个重要原因。

游戏开发中，常见的降低Drawcall的方式，无非以下几种：

在每一帧都对需要的网格进行合批处理，这样的好处就是合批的物体仍然可以各自移动，但是必须使用同一个材质。当所需合批的顶点数过多时，其实会对CPU产生额外的计算开销。因此在做动态合批的时候，通常会有顶点数的限制，需要根据实际需要做好取舍。

只进行一次合批处理，生成一个大的网格，性能优于动态合批，但没有动态合批灵活（只能作用于静态物体），并且会有较高的内存占用。

根据机型或摄像机距离，使用不同的材质shader，尽可能地降低细节表现，去除不必要的渲染Pass以及计算开销。

常见于大世界场景的游戏中，对于摄像机可视范围之外的物体可以进行视锥体剔除，但是可视范围内的那些已经被遮挡住了的物体，可能仍然会去进行绘制，造成不必要的性能损耗。

对需要绘制的物体进行排序，是游戏引擎规避性能开销的一种常见手段。非透明物体相对摄像机由近及远地排序绘制，可以有效剔除那些深度测试不通过的片元。但对于那些未被遮挡（深度测试通过）的透明物体，由于需要开启混合计算，因此在Early-Z阶段也没法剔除掉那些背后的图元数据，这就造成了同一个像素的多次(过度)绘制，即我们常说的 Overdraw 。

GPU中跟Overdraw有关的指标可以参考像素填充率，即每秒所能渲染的最大像素数量。在确保带宽没有遇到性能瓶颈后（改用压缩纹理格式），如果降低设备分辨率后，帧率一下子上去了，那么很可能就是像素填充率遇到了瓶颈。这时候就需要看看Overdraw是否在一个合理的范围内，是否有优化的空间。

实际的游戏开发中，最常见的Overdraw大户莫过于粒子特效了。美术同学在制作粒子特效的时候，往往会为了追求细节效果而忽略掉Overdraw的问题。大量的透明粒子相叠加，造成的性能开销是十分可怖的。为此，我们最好在立项之初就设定好一些粒子特效的制作规范，或是一些建议要求来约束美术设计粒子效果。