系列文章：
游戏性能优化（1）-why & benchmark
游戏性能优化（2）-budget
一、为什么做性能优化（why）
性能优化是游戏开发绕不开的重要环节。那么性能优化为什么重要？
- 大家都知道随着硬件的发展，游戏的画面水平和玩法复杂度都在提高。那么，换句话说，如果你拥有足够好的优化能力，你的游戏的画面水平和玩法都是可以领先于时代的。
- 受众群体大小。 玩家的客户端硬件性能水平是差异很大的，性能越好的游戏，受众群体越大。
- 马太效应。游戏市场竞争异常残酷，一个王者荣耀可以埋葬无数的MOBA品类的手游。9个80分，1个90分的同类游戏里，90分的可能就是唯一活下来的那个。而性能优化可能就是获得那多出来的10分的关键。
- 是不是游戏足够简单就可以不用做性能优化了？未必，参照1、2、3得出：做好性能优化，能赋予游戏更大的空间去提升效果和玩法、扩大受众群，让游戏从众多竞品中脱颖而出。
二、万事开头难，性能优化的开头是性能分析测量（benchmark）
理解性能问题
要解决问题，首先要找到问题，理解问题。通过对性能的测量，可以让我们更客观的理解游戏的性能问题，定位优化方向。
游戏是一个很复杂的系统，直觉和经验有时候会误导优化方向。比如一段看起来性能不是很好的代码，可能执行的频率是很低的，在全局来说，它并没有造成什么性能问题。如果靠经验判定这段代码需要优化，可能就会在这上面浪费精力。
通过大量的性能测量，也会逐渐建立我们更加正确的性能直觉和经验，帮助在早期规避性能问题。当然，注意不要过早优化。
基于底线和目标测量性能
做性能测量，要有一个底线（deadline），比如：手游内存必须小于350M，CPU占用率必须小于80%。另外，我们需要有一个优化目标（target），我们要努力将内存和CPU优化到多少。底线是达不到游戏就无法上线的指标，目标是我们要尽力达到的指标。
性能优化是一个迭代的过程，刚开始优化是很容易的，有很多优化点可以做，这个时候我们可以做一些无损效果、很容易做的优化。随着迭代的逐步进行，优化越来越难。难在两个方面：
- 优化本身需要比较大的工作量，需要付出时间成本
- 优化需要牺牲一定的游戏质量，降低画面效果或者砍玩法
只有我们建立了我们的底线和目标，我们才能判定一份性能数据是否达标，是否值得付出代价去优化。
能测量的性能问题才能优化
就向前文中提到的，游戏是一个复杂的系统，你如果没有具体的性能数据，就无法证明系统中某个功能点存在性能问题。同样，你即使盲改一个问题，也无法证明这个改动能否提升性能（甚至降低性能）。
建立可测量的优化对象
为了优化性能，我们需要建立这样的优化对象:
-
确定性能问题情形
游戏的性能问题只会在特定情形下才会出现，比如主城的某个视角、大量玩家作战等。我们需要优化的是游戏特性情形下的性能。 -
可快速重复执行
确定了性能问题情形后，我们需要可快速重复创建同样情形。这样，我们才可以在做出改动后，对性能数据进行对比，验证改动是否能够提升性能。创建情形最好是快速的，因为优化很多时候是一个反复尝试的过程，不要把时间浪费在等待中。
性能结构与车间流水线
整个游戏的执行过程很像车间的流水线，在每帧的开始，游戏系统接受各类输入，经过各个模块的运算，最后产出一帧画面。在整个过程的执行中，关于性能结构有两个重要的概念：
-
80/20原则
20%的代码耗费着80%的性能，这20%的代码往往存在于一个每帧被大量执行的循环中。 -
瓶颈
在流水线上，如果生成零件C需要一件零件A和一件零件B，零件A和零件B是同时生产的，零件A的生产速度是零件B的一倍。那么，这个时候生成零件C的瓶颈在于零件B的生产速度。游戏系统中，有很多类似的情况，我们只有对系统的瓶颈进行优化，才能提升性能。
测量级别分级
-
模块级
对各个子系统进行性能测量，比如CPU占用率、GPU占用率、内存总量、dc数目。 -
算法级
针对算法进行分析，根据核心算法的吞吐量和性能数据预测性能风险。 -
代码级
对代码级别进行性能测量，得到精确到行的性能数据。
测量环境维度
游戏性能的测量环境具有两个维度：
-
运行环境
运行环境又包括：硬件条件 、** 操作系统状态** 、** 网络状况等各种会影响游戏运行的环境。我们在优化性能时，一般是对目标环境**（具有普遍意义的运行环境）做重点优化，这些优化一般对所有运行环境都起作用。然后针对不同的游戏运行环境做一定的针对性优化。在做性能测量时，需要明确当前的运行环境。 -
游戏情形
游戏情形是指游戏内环境，包括普遍情形，指的所有游戏运行情形；又包括各类性能比较耗的重点情形，比如有大量角色和特效要渲染的战斗场景、有海量建筑群要绘制的主城场景。我们优化性能时，这两者情形下的性能问题都是优化的重点。
引用
- 《Video Game Optimization》
- 《Optimizaed C++》
