游戏性能问题，往往是我们游戏程序员最关心的问题，对于这个问题，我在这里总结一下我关于游戏性能优化的八个理念：
理念一：善于从问题的表象上出发进行优化
游戏出现问题时，最直接的表现就是卡，造成卡顿的问题又有很多不同的情况。在解决卡顿问题前，我们应该最先排除是否是外部问题造成的卡顿，外部问题：网络差，硬件差，系统问题等。排除是外部问题导致的卡后，我们可以根据卡顿的现象来定位问题。
1.轻微的较频繁卡顿
1）帧率
根据游戏自身来设定帧率范围，一般游戏建议30帧就够了
2）Drawcall
在了解什么是drawcall后，我们知道，过高的drawcall会导致卡顿，这里就介绍一些减少drawcall的方法：
A.查看drawcall
在layabox中，添加代码DebugTool.showStatu = true;
B.连续渲染相同图集里的图，只会执行一次drawcall
C.UI上drawcall优化
优化的思路就是尽可能让相同图集里的图一次性连续渲染完，举例来说：在layabox中打开一个UI，层级窗体里看到界面里的子对象，如下图：
我们可以看到看每一个子对象前边，都有一个小圆点，这个圆点的颜色代表了他来自哪个图集，相同颜色的圆点代表是同一个图集。渲染UI时，UI上的每个子对象是按照自上而下的顺序去渲染的。在不影响界面的情况下，把界面里各元件的层级调整一下，可以达到减少drawcall的目的。调整后，如图所示：
优化前：会有6次drawcall
优化后：只有3次drawcall
D.场景上的drawcall优化
拿场景中的人物来举例：
假设一个人物的某套装资源在一个图集里。
那么场景里连续渲染穿这个套装的人物，只用1次drawcall。实际上在游戏里，穿着相同套装的人不会理想的按顺序出现。一个场景里会有许多穿着不同套装的人物，而每个套装在一个图集。也就是说，场景里，渲染N个这样的人物就需要无限接近于N次drawcall。
当每个人物还有影子，影子的资源，肯定是在不同于各个套装资源的图集里。
情况1：人物和影子是在同一个容器里处理，每一个容器就是一个人物，这种情况就会出现，渲染单位A，会使用两个图集套装图集+影子图集有两次drawcall。当渲染N个人物，就有N*2次drawcall。
情况2：把渲染影子拆出来，当渲染完所有人物后，再根据所有人物的位置，绘制影子。这种情况，渲染N个人物，只会有N+1次drawcall显然情况2的处理方式更优。
当每个人物还有名字、称号、血条等等元素，若这些元素是按照上面情况1的处理，那drawcall就有N*M次。把这些元素按照上面情况2的处理，显然可以减少大量的drawcall。
E.其他减少drawcall的方法
如：减少被遮挡的单位渲染
图集的控制
3）有较高消耗运算，特别是enterframe和for循环里面的
注意代码逻辑优化，减少算法复杂度
4）资源加载缓存有问题/资源太零散，造成I/O过高
优化资源加载策略
5）日志打印
减少日志打印
6）限制底层绘制分辨率
2.突然大卡顿
某些不定时的操作，循环里复杂度高
可能是执行到一些复杂度高的循环处，导致突然大卡顿
协议包过大
注意协议包优化，优化方式诸如：
1.删除不用字段
2.整合小字段
如某协议中的字段
var a:int;
var b:int;
var c:int;
假如上述a,b,c的值只会是十位数以下时，可以整合成一个字段:
var d:int;
d的每一位为ABCDEF
AB为a的值，CD为b的值，EF为c的值
比如d = 123456
那么a为12，b为34，c为56
这样做的好处，原来需要12个字节的数据，现在只用4个字节就可以了。
3.字段类型选择
如用int还是short
只有两个值的情况选择用boolean
4.尽量避免使用字符串
协议中的字符串，尽量通过ID发送
ID对应的字符串在代码里做好映射或配置
垃圾回收负荷过重
单位是否是频繁初始化，用完后就销毁？
是否需要使用对象池
如果卡顿发生UI上：
面板内容初始化分帧处理
图片和特效尺寸，图集依赖规划是否合理
UI面板是否分页签
UI内特效，3D模型等次要元素延迟初始化
List优化，动态初始化，循环使用
3.持续地越来越严重卡顿
是否有对象/物件用完了隐藏掉，而没有被删除，越积越多
如：飘血、事件监听等
内存泄漏，GC越来越频繁
4.卡顿到闪退
内存过高，内存有泄漏
检测是否有报错或死循环等问题
理念二：内存为主
很多能感知的较大卡顿都是垃圾回收引起的；
内存问题往往比CPU问题更难解决，甚至需要大规模重构；
降低内存会使得游戏更加轻快，可以缓解其他较小问题。
理念三：内存使用策略比内存释放策略更重要
关于内存使用的策略，往往在项目的初期就应该制定好，下面有几点建议：
new对象必须由Factory或者Manager进行统一管理，这点做好了，对后期排查内存问题尤为重要；
View和Model要完全分离；
View的创建细化到每帧，根据性能情况创建；
FpsManager按照帧率动态调整阀值；
合理地运用对象池：“频繁创建和销毁”的“小型”对象采用对象池。
理念四：重视资源压缩
游戏程序中，大量的内存来自于资源，合理的压缩资源是减小内存行之有效的办法。关于资源压缩，这里提一些建议：
重视制定制作流程，技术标准
资源的制作不能随心所欲，必须拥有一定的标准，例如：
原始图片资源使用jpg还是png
是否是可以用镜像处理的图片资源
相似的资源是否可以统一
避免程序上使用滤镜和灰化等
一些图片资源上不起眼的光效或羽化效果等是否可以不用
美术字体图片中，相同文字的拆分与组合
九宫格拉伸图片的概念
合理优化动作、特效等资源序列帧
许多人物动作、特效等资源，美术给出的效果十分精细。在处理内存问题上，可以考虑对这些资源做如下处理：
1.抽帧
一些影响不大的关键帧是否可以删除。
2.缩小再放大
一些不起眼的部位，序列帧可以按比例缩小，程序使用时，再放大。
3.砍方向
人物向左和向右的资源是否可以通过旋转其中一个动作实现？
是否所有方向的资源都要用到？
对称的资源砍半/四分之一镜像使用
序列帧特效用IDE制作替代
UI全屏分辨率选择 1024像素
icon尽量使用 64*64 的格式
使用pvrtc etc ，png8格式
UI背景使用最接近的某个2的次方的尺寸
背景图不要打到图集中，并且尽量用jpg
少用遮罩
音效使用单声道
理念五：屏蔽策略
在游戏出现性能瓶颈的时候，我们不得不考虑屏蔽一些游戏内容的显示，比如一些次要的场景单位、特效等。屏蔽必然会减弱玩家的游戏体验，但是，比起卡顿甚至是闪退，适当的屏蔽规则是必要的。
加入屏蔽设置，性能差的时候自动开启
屏蔽策略要覆盖各类显示对象
某些场景使用统一模型
理念六：不要忽略看起来小的地方
正所谓积少成多，一些看起来小的地方，却用了不太合理的处理方式，往往也影响着游戏的性能，在《大天使之剑H5》中，我们就对如下这些地方做了些优化：
配置表数据优化
String数组方案
相似String的处理
版本号文件，采用树形存储减少URL字段的重复度
数值类型广泛使用变长
解析战报，分段解析
理念七：深入学习开发者工具的使用
在调试游戏时，我们往往要依赖开发者工具来获悉游戏的内存变化、CPU的使用、游戏内对象的整体情况、资源的应用情况、甚至是我们关注的变量值等等。善于使用各种开发者工具能让我们事半功倍。
使用谷歌浏览器的开发者工具
layabox开发的H5游戏默认是用谷歌浏览器调试的，这里我们稍微讲下谷歌浏览器的开发者工具的运用。游戏运行在谷歌浏览器时，按F12可以打开开发者工具，他的一些常用功能有：
1.console的使用
Console的界面如上图所示，它主要显示着我们游戏运行时的日志等信息。每条日志的后面，有链接可以快速跳转到输出日志的代码处，在console的下方，有输入框功能，我们可以通过这里输入代码改变当前游戏内的数值、用不同方式打印日志等。
2.调试
我们可以在工具的Sources选项卡下找到我们要调试的JS，进行断点或条件断点调试。
3.NetWork
NetWork面板提供了有关已经下载和加载过的资源的详细信息。
在这里我们可以很直观的找到一些加载耗时较长的资源进行优化。
4.TimeLine
TimeLine界面中，我们可以看到关于时间开销的完整概述。
如图所示，通常我们在游戏性能表现差的情况下，在TimeLine界面点击左上角的录制按钮，录制一段时间后，点击完成，它会帮我们搜集到在录制的这段时间里，游戏每一帧的运行状况。
绿色的帧是在帧时间内处理完需求处理的事情的。
红色的帧是处理时间大于帧应该有的时间的，也就是卡了的帧。
我们可以重点看下红的帧，在下边可以看到是哪个方法占了多少时间，以及这个文件里又是调用哪些方法，分别调多少时间。
在图中左下部分，我们还可以看到代码逻辑和渲染的比重，可以用来判断可以做什么优化，怎么优化。这个功能，对程序的参考决不止我提到这些，这里有很多信息帮我们分析找到问题，可以对我们优化提供很多帮助。
5.Profiles
Profiles界面中，我们可以使用快照功能。最常用的还是Take Heap Snapshot功能。它可以记录当前内存分布的详细信息，多张内存快照还可进行比对，分析在不同的时间点，内存具体有哪些变化。
理念八：抓大放小，先抗住再优化
没有一个性能问题是由单一问题造成的；
单次单点修改，注意记录便于前后对比找到关键问题；
调试崩溃的时候一定要注重日志，一行一行看总会找到Keyword。
转载地址：https://mp.weixin.qq.com/s/4UUM6YBf33iOpp5jQqbGcQ
作者：哈森森
链接：https://www.jianshu.com/p/00913bbf3e86
來源：简书
简书著作权归作者所有，任何形式的转载都请联系作者获得授权并注明出处。