Unity性能优化

Unity性能优化专栏第一期

---

---

橙子前言

大家好，我是橙子，今天为大家带来的是Unity性能优化的教程。

由于性能优化不是一两句就可以讲清楚的，我会写一个基于性能优化的专栏，会详细聊聊各种性能相关的问题。欢迎大家点赞、收藏、转发！

★,♫◦★,♫◦★,♫◦★,--------------------华丽的分割线--------------------♫◦★,♫◦★,♫◦★,♫◦★,♫◦

Unity 3D手机游戏优化提出了许多挑战，我们已经完成了一些工作，并且非常容易解决这些问题。移动设备的广泛选择和种类以及极其多样化的硬件和规格足以让我们中最好的人头疼。此教程可帮助您更好地了解Unity3D游戏优化。

---

一、性能优化概念

随着手机游戏开发管线的不断成熟，越来越多的事情开始需要专业化和精细化，比如几年前的TA。

现在，手游的性能优化逐渐也开始成为一个独立的岗位，甚至可以和TA、图形程序员待遇相当。
这导致的影响就是游戏程序员的分支路线开始呈现多元化。

Unity 3D 游戏优化瓶颈归根结底是开发过程中内存分配和使用不佳的结果。

所有的性能问题都可以归结于一句话：硬件受委屈了。

1、它们承担了它们这个级别不应该有的压力。

例如：CPU计算压力过大，GPU的绘制压力过大，CPU和GPU数据交互过大，过频繁，内存消耗太大等等。

但是造成这些硬件委屈的原因则有很多很多种情况：
– CPU的委屈可能来自于：

• 不合理的代码循环
• 不必要的逻辑运算
• 频繁的内存申请导致的GC
• 过多的蒙皮动作
• 大量的粒子计算
• 超多的物理模拟
• 超多、超大的文件加载等等。

内存的原因可能来自：过大的纹理、资源、文件、数据，过多的托管内存申请，不恰当的内存管理和释放机制，不恰当的缓存管理，过多的SDK和工具引入，冗余的三方代码和库，没有做变体剥离的Shader等等。

GPU的问题则可能来自于，过多的顶点和三角面，过多的OverDraw，过大的纹理，过复杂的Shader计算，过多的纹理采样，复杂的后处理效果等等。

2、它们没有受到应有的尊重。

硬件：本来我可以做的更好，但是由于你不懂我，或者你的失误，导致我的能力没有得到最佳发挥（喂，不是这么用的！）。
最典型的就是DrawCall。大部分都知道DC越高，性能越差，却有很多人无法真正回答正确DC高为什么会有性能问题（至少我面试过的人里占一大半），实际上它最大的原因是因为GPU需要等待，也就是处于空闲状态。另外一个就是不同类型的GPU纹理格式压缩，大家或许都知道，要把纹理设置成ETC1，ETC2，ASTC，PVRTC，却很少人（我面试过的人中）知道为什么。还有对于Mono内存的申请机制不了解，就不知道为什么要先申请大内存的，然后再申请小内存等等。

3、性能问题的具体表现

知道了性能问题的根源，也知道造成性能问题的原因，那么怎么样把它们和具体的表现挂上钩，从而能够快速排查性能问题呢？

或者说，有关于性能问题的具体表现是啥，怎么样才知道项目遇到了性能问题？

这里我把性能问题的具体表现总结为两个方面， 卡和慢 。
卡表现在那些地方？

• 当你打开某个界面的时候，界面是一顿一顿的从边缘滑动进来，或者打开之后过比较长时间才能加载出来。
• 进入一个场景的时候，loading了很久，进度条一直不动,进入场景之后，看别人走路跟滑冰一样。
• 手机发烫，耗电量急剧增加，运行的好好的突然ANR一下。
• 一到团战闪退了。要么就是卡死不动了。
• 更极端一点，场景其他地方都很流畅，只要一到这个水坑边上就掉帧。
• 更早的时候，流量资费没降下来之前，数据流量也会算作性能的一个部分。

但这里要提一嘴，并不是只要遇到上述情况就归于性能问题。游戏开发一般会有一个参照的适配机型，

分为高中低配三个档次
{
中配：就是要能够展现出所有项目预期的设计和效果。
高配：会在中配的基础上适当调高效果和帧率，比如增加描边，更好更好的纹理，更多更华丽的特效等等。
低配：我们一般只保证功能，不保证效果。那些比低配机型更低的，就不会考虑了，能玩你就将就玩，不能玩请你换机器。
}

Unity 3D 游戏开发中的内存使用问题通常是游戏环境中优化不佳以及资源使用和应用效率低下的问题。通过本专栏性能优化中的一些优化技术并正确设置您的游戏，内存需求将大大减少，您将在游戏和更广泛的设备（包括新旧设备）中体验到更高的性能。

二、优化常见的误区

误区1：我的游戏很简单，不需要优化

例如一个开发者，用了1-2小时就开发出一款游戏，游戏运行的很棒，毫无卡顿，但是Unity打出的包一般是20MB-40MB左右，发行商要求必须10MB，所以只能从文件进行优化。

如果一个开发者在开发游戏中，碰到了性能黑点的情况，就必须要做优化。

性能黑点：本身并不是有问题的代码，但是由于缺乏开发经验，把代码放到错误的地方，造成游戏在运行中造成预料之外的情况，因为Unity的一些方法运行的是非常快的，例如Update，可能一秒就运行30次左右，如果把代码放进Update，1秒完成的代码，却运行了30次，就会造成毁灭性的后果，最终游戏就无法正常运行了。

误区2：优化工作尽早进行

不为5%的优化，而花费95%的时间

我们知道一个项目往往不是一个人在开发，是一个团队在开发，而做优化肯定会改动代码，这种改动 可大可小，在这种改动的时候，可能会影响游戏的主体结构，如果在游戏早期就开始优化，肯定就会改变主体结构的方向，这对于其他的项目成员来说，肯定不是一个好消息。
对于早期就进行优化项目，会浪费很多时间，在无关紧要的地方，甚至都不是瓶颈的地方。

误区3：性能优化=Debug

实际在工作中，性能优化就是性能优化，Debug就是Debug，他俩没有实际上的关系。
有人可能不知道Debug是什么？

Debug就是让程序可以正确的运行，消除BUG，并不是我们的Debug.Log哦。
假如我们做一个游戏，去算1+1等于几，如果在测试中，1+1=3，这就说明有BUG，没有正常运行，我们就要去Debug。

性能优化是什么呢，我们现在算出了1+1=2，程序正确运行了，然而1+1=2 算了5年的时间才算出来，这个就会非常尴尬，虽然结果是正确的，但是运行的效果非常差，性能优化的所在就是去优化这个程序。

我们常说 性能优化就是在一个没有BUG的项目中进行优化的，如果在程序的优化中，发现了BUG，那只能先Debug (去掉BUG后) 再进行优化的工作。
如果一个开发者，在一个有BUG的项目优化，可能会出现错误的优化方式，甚至是反向优化。

所以 性能优化和Debug完全是两码事，应该先要Debug 再去性能优化

---

三、总结

此章节讲述了：
1.性能优化概念
2.性能优化的三个误区
性能的话题暂时先聊这么多，我会写一个基于性能优化的专栏，会详细聊聊各种性能相关的问题。

四、结束语

不及硅步，无以至千里。
不积小流，无以成江海。
每天进步一点点 谢谢您的观看。

觉得对自己有帮助，欢迎关注、收藏、转发！我们下期再见