• 纹理没有压缩

在很多情况下，美术会觉得纹理压缩后效果不理想。我们建议的是：可以把原图的分辨率长宽都扩大一倍，保持原有压缩格式。这样压缩过后的文件还是比不压缩的文件要小，并且视觉效果可以得到较大的改善。

• 纹理导入设置中的 Read/Write Enabled 处于勾选状态

开启纹理导入设置中 Read/Write Enabled，纹理在传到GPU之后，CPU端的数据也会一直保留在内存中。因为在移动端显存共享内存，会导致内存占用加倍。因此需要注意是否有需要在CPU端访问的纹理，比如：需要通过脚本获取纹理像素的情况下，就要开启纹理导入设置中的 Read/Write Enabled。

• 模型文件导入设置中 Read/Write Enabled 处于勾选状态

除了需要脚本中访问的网格，作为网格碰撞器中的网格，脚本中用StaticBatchingUtility.Combine静态合批的网格，以及粒子系统发射的网格之外，其它模型建议不要勾选此项 ，否则会在内存也保留一份网格实例占用内存。

• 模型导入设置［Rig］选项页中Optimize GameObject没有勾选

建议开启Optimize GameObject，这个选项可以把SceneManager中用于skinning的节点都去除，节省了场景节点树更新以及查询的CPU消耗，对于需要做挂点的节点可以添加到例外列表中。

• 使用第三方音频插件时没有禁用Unity内置音频

不需要使用Unity内置音频模块的时候，建议Editor中通过勾选Edit->Project Settings->Audio->Disable Unity Audio来完全禁用FMOD模块，避免不必要的CPU消耗

CPU常见性能问题

• 频繁调用的Camera.main

建议脚本做好Main Camera的Cache。Camera.main实际为GameObject.FindGameObjectsWithTag(“MainCamera”)调用，主要因为引擎无法得知用户通过脚本设置的MainCamera，CPU消耗较高。

• 脚本中大量UnityEngine.Object的判等操作

建议改为用InstanceID来判断即Object. GetInstanceID，运行期间保证唯一。 因为Object的判等还有额外的耗时操作，而Int类型的判等就非常快速了。同理，使用Object作为key的数据结构也建议改用InstanceID做key。

• 用于查询操作的数据使用list数据结构

List线性结构Contains的耗时非常高，建议改为hashset，hashtable之类的查询操作效率高的数据结构。

• 加载资源时每帧从Assetbundle加载的Asset数量没有限制

在场景内每帧从Assetbundle加载的Asset数建议限制在2到5个，数量高时耗时过长容易造成卡顿。

内存常见问题

• 加载场景的时候有 一段内存尖峰

常见的情况是有无索引的资源被加载进来，然后因为UnloadUnusedAssets被卸载掉。内存尖峰基本都是对游戏本身无用的内存，但是可能会因此造成游戏在内存紧张的机器上被强制关闭。

• 静态索引导致的内存泄漏

一些内存占用较大的资源如纹理，因为有静态索引而无法在切换场景或者调用UnloadUnusedAssets时被卸载掉，因此内存的泄漏量会随着用户切换场景的次数而增加。

• Mono内存池总大小与当前使用大小的差值较大

这个值越大说明有越多的不必要内存池扩展，比如说在同一帧内有加载大量资源，实例化大量对象等，可能让内存池瞬间膨胀的操作。

• GC分配量较大

项目Review过程中，除了CPU时间占用和内存分配量，我们还会留意脚本函数的GC分配。GC分配越频繁，量越大，由于Mono内存池可用内存不足导致的GC.Collect（造成卡顿原因之一）调用就越频繁，并且可能引起mono内存池不必要的扩展，因此脚本函数的GC分配量是既影响CPU也影响内存的重要参数。对于GC分配量。

我们建议的参考数值为：
对于基本每帧都会分配GC的函数，GC分配量大于2KB的建议都确认下是否有可能把临时变量抽取出来。
对于偶尔分配GC的函数，GC分配量大于10KB的建议都确认下分配的数据结构是否有优化空间。

GPU常见性能问题

• 特效渲染的Pass数量较多

一些特效的渲染可以合并到同一个Pass以节省GPU开销，另外RenderTexture在可以共用的情况下尽量共用

• 同屏面数过多

同屏面数建议在20W以下，较优情况是控制在10W以内

• UI元素在需要隐藏的时候使用了设置Alpha为0的方式

实际上GPU依然需要对UI mesh进行渲染，建议不要通过设置Alpha为0的方式来隐藏UI。

• 当使用网格作为地形时，适当切分地形网格

在网格顶点数很高情况下需要依靠硬件裁剪来剔除顶点，比较消耗GPU性能，建议按照大概的同屏可见范围来切分地形网格。

• UI元素过多依赖多层元素的混合来达到美术效果

这样会造成较多的Overdraw，建议尽量通过预制纹理来做到想要的效果。

资源导入设置检查

Project Review开始阶段，Unity技术支持工程师一般会先同开发团队沟通整个项目的情况，了解目前已知的性能问题，然后开始进入资源导入设置检查环节。最常见的检查项包括以下内容。

模型导入设置

• 检查Read/Write Enabled是否开启

开启Read/Write Enabled一般是用于运行时修改Mesh的顶点数据，开启这个选项会导致Mesh的内存占用翻倍。因此如果项目中不需要在运行时修改这些Mesh数据的话，我们建议把这个选项关闭。

• 检查Animation Type 有没有设置成None

Unity默认的Animation Type是Generic，对包含动画数据的FBX文件是适用这个选项的。但是如果FBX文件中没有包含动画数据，而只是普通静态Mesh的话，设置为Generic会导致引擎自动为这个Mesh的GameObject添加一个Animator组件，导致不必要的消耗。因此对于不包含动画数据的模型文件，我们建议把这个选项设置为None。

纹理导入设置

• 检查Generate Mipmaps选项有没有开启

对3D物体，关闭Mipmap会导致远处的纹理有闪烁感，而且渲染性能较低，因此建议开启3D物体上纹理的Mipmap。开启Mipmap的缺点是会导致纹理的内存占用更大。对2D物体，Mipmap并不会导致闪烁和性能问题，所以建议关闭2D以及UI纹理上的Mipmap选项。

音频导入设置

• 音频压缩格式

对IOS平台，建议采用mp3格式压缩音频文件，安卓平台建议使用Vorbis格式，因为这两种格式分别在这两个平台上有硬件解码的支持。

• Force to Mono

手机游戏往往对声音质量要求不高，如果不需要立体声效果，可以把这个选项打开，将音频文件导入为单声道音频。

动画导入设置

• 动画帧率

在Animation页面检查动画的帧率，一般30FPS足够满足大部分游戏的效果，如果发现有制作成60FPS的，建议美术重新制作成30FPS。

Project Review常用性能分析工具

Project Review最主要的工作是使用各种工具来分析项目中存在的性能问题，最长用的工具包括Unity Profiler，Unity Memory Profiler, XCode Instrument. XCode Instrument内又包含了很多工具，其中最常用的有Time Profiler，Allocation以及Capture GPU Frame。

Unity Profiler

Unity Profiler中最常检查的内容是CPU Usage，其中GC Alloc和Time ms最为重要。GC Alloc展示了每帧在Mono堆上进行内存分配的代码，过于频繁的在堆上分配内存会导致Mono定期触发GC.Collect操作，进而导致游戏卡顿。因此我们建议对单帧2K以上的内存分配，以及每帧20B以上的内存分配进行排查。如果能把堆内存的分配降到最低是最好的。Time ms展示了每一帧CPU耗时最高的函数，通过这项可以找到耗时不合理的代码，然后进一步最代码进行优化。
  
Unity Memory Profiler

Unity为5.3以上的版本提供了一个新的Memory Profiler工具，这个工具目前还是以外部插件方式提供的。这个工具通过图形的方式展示了工程中占用内存最高的资源类型，因此可以很方便的进行资源内存的优化。另外还可以在游戏的不同时间点抓取多个快照，通过比较内存占用的不同，来发现某些资源内存泄漏的情况。

XCode Instrument – Time Profiler

左上角是Instrument的Time Profiler工具，右下角是Unity Profiler，可以发现它们非常想像。区别在于Time Profiler可以分析一段时间范围内不同函数的时间消耗，而Unity Profiler只能分析一帧内代码的时间消耗。另外Time Profiler可以显示引擎底层耗时高的代码堆栈，非常方便从底层去理解性能问题的原因。Unity Profiler只能显示引擎代码中添加标签的函数耗时，因此往往在Instrument Time Profiler中可以看到更多有用的数据。

XCode Instrument – Allocation

Allocation是用于分析内存分配的工具。默认情况下，它会开启Created & Persistent选项，这代表它会记录一段时间内分配出来但是没有释放的内存。因为有了这个功能，我们可以很方便的检查游戏中存在的内存泄露。一般的使用方法是在游戏主菜单界面开启Allocation检测，进入战斗场景测试一段时间再回到主菜单界面，然后检查有哪些内存分配但是没有被释放。这部分内存就可能包含存在泄漏的内存。

Capture GPU Frame

从XCode内启动游戏在真机运行，通过XCode内的Capture按钮可以抓取当前渲染帧的全部数据。界面左边展示了所有的Drawcall列表，中间上方是当前Drawcall渲染出的画面，下方是当前Drawcall的相关数据，右上方是当前Drawcall用到的纹理数据。这个工具可以显示每个Drawcall的耗时，因此可以用来检查哪些对象渲染耗时太高。进而分析是Shader原因，还是网格体太复杂等等。

其他

在安卓平台下并没有XCode中这么全面的性能分析工具。最常用的工具有Adreno Profiler和Mali Graphics Debugger，这两个工具都是用来进行GPU性能分析的。

三、游戏优化步骤：

1.从美术资源，面片，顶点，骨骼数，Mipmaps,Animation，材质

2.逻辑方面，不用的资源释放，加载时是否一直在消耗内存，该缓存的缓存

3.GPU  shader 是否shader比较耗

4.drawCall   动态 ：材质一致时，整体优化   静态：unity中标志static，或者代码编程合并优化 材质一直，并且都有meshfilter且不能时static

批处理优化  .DrawCallBatching批处理
  1.首先理解为什么两个没有使用相同材质的物体计时使用批处理，也无法实现DrawCall数量的下降和性能提升？

因为：被批处理的两个物体使用相同材质的目的，是在于纹理要相同，这样才能达到同时渲染的目的，故才打包图集，使纹理相同。

2.动态批处理注意点？

（1）动态批处理仅支持肖于900顶点的网格物体。

3. 对物理组件的优化：

能少用，则少用

4. 对CPU的优化：

5. 代码优化：

代码善于使用ref来传值，而不是复制传值，比如mat矩阵，复制显的笨重