CPU方面性能考虑：引擎和代码

渲染模块、动画模块、物理模块、ui模块、粒子模块、加载模块、GC模块
最重要的是渲染模块、UI模块和加载模块

1、渲染模块

主要是：场景、物体和特效的渲染

a、降低Draw call

在unity中，每次CPU准备数据并通知GPU的过程就称之为一个DrawCall。
批处理Draw Call Batching
原理：每一帧把可以进行批处理的模型网格进行合并，再把合并后模型数据传递给GPU，然后使用同一个材质对其渲染。
动态批处理：条件是物体使用同一个材质，并且满足对应的特定条件，unity会自动为我们批处理
动态批处理限制：
1.顶点属性要小于900。例如，如果shader中需要使用顶点位置、法线和纹理坐标这三个顶点属性，那么要想让模型能够被动态批处理，它的顶点数目不能超过300。因此，优化策略就是shader的优化，少使用顶点属性，或者模型顶点数要尽可能少。
2.多Pass的shader会中断批处理。
3.在unity5中，动态批处理对于模型缩放的限制已经不存在了。
4.使用光照纹理的物体需要小心处理。为了让这些物体可以被动态批处理，需要保证它们指向光照纹理中的同一位置。
静态批处理：
原理：只在运行开始阶段，把需要进行静态批处理的模型合并到一个新的网格中，这意味着这些模型数据不可以在运行时刻被移动。
也是使用同一个材质，并且对象设置为static。这个是用内存换区性能
只要这些物体不移动，并且拥有相同的材质。因此，静态批处理比动态批处理更加有效，你应该尽量低使用它，因为它需要更少的CPU开销。
使用批处理需要注意并非draw call越小越好，还有用于传输渲染数据的总带宽。当我们使用Draw Call Batching将同种材质的网格模型拼合在一起时，可能会造成同一时间需要传输的数据（Texture、VB/IB等）大大增加，以至于造成带宽“堵塞”，在资源无法及时传输过去的情况下，GPU只能等待，从而反倒降低了游戏的运行帧率。
烘焙Lightmap、LOD、Occlusion Culling和Culling Distance

2、ui模块

NGUI：
UIPanel.LateUpdate为性能优化的重中之重，它是NGUI中CPU开销最大的函数
对于UIPanel.LateUpdate的优化，主要着眼于UIPanel的布局，其原则如下：
a、尽可能将动态UI元素和静态UI元素分离到不同的UIPanel中（UI的重建以UIPanel为单位），从而尽可能将因为变动的UI元素引起的重构控制在较小的范围内；
b、尽可能让动态UI元素按照同步性进行划分，即运动频率不同的UI元素尽可能分离放在不同的UIPanel中；
c、控制同一个UIPanel中动态UI元素的数量，数量越多，所创建的Mesh越大，从而使得重构的开销显著增加。比如，战斗过程中的HUD运动血条可能会出现较多，此时，建议研发团队将运动血条分离成不同的UIPanel，每组UIPanel下5~10个动态UI为宜。这种做法，其本质是从概率上尽可能降低单帧中UIPanel的重建开销。

3、加载模块

加载模块同样也是任何游戏项目中所不可缺少的组成成分。与之前两个模块不同的是，加载模块的性能开销比较集中，主要出现于场景切换处，且CPU占用峰值均较高。
场景切换时的主要性能开销主要体现在两个方面，前一场景的场景卸载和下一场景的场景加载

a、场景卸载

对于Unity引擎而言，场景卸载一般是由引擎自动完成的，即当我们调用类似Application.LoadLevel的API时，引擎即会开始对上一场景进行处理，其性能开销主要被以下几个部分占据：
Destroy
引擎在切换场景时会收集未标识成“DontDestoryOnLoad”的GameObject及其Component，然后进行Destroy。同时，代码中的OnDestory被触发执行，这里的性能开销主要取决于OnDestroy回调函数中的代码逻辑。
Resources.UnloadUnusedAssets
一般情况下，场景切换过程中，该API会被调用两次，一次为引擎在切换场景时自动调用，另一次则为用户手动调用（一般出现在场景加载后，用户调用它来确保上一场景的资源被卸载干净）。在我们测评过的大量项目中，该API的CPU开销主要集中在500ms~3000ms之间。其耗时开销主要取决于场景中Asset和Object的数量，数量越多，则耗时越慢。

b、场景加载

资源加载：资源加载几乎占据了整个加载过程的90%时间以上，其加载效率主要取决于资源的加载方式（Resource.Load或AssetBundle加载）、加载量（纹理、网格、材质等资源数据的大小）和资源格式（纹理格式、音频格式等）等等
Instantiate实例化：在场景加载过程中，往往伴随着大量的Instantiate实例化操作，比如UI界面实例化、角色/怪物实例化、场景建筑实例化等等。在Instantiate实例化时，引擎底层会查看其相关的资源是否已经被加载，如果没有，则会先加载其相关资源，再进行实例化，这其实是大家遇到的大多数“Instantiate耗时问题”的根本原因，这也是为什么我们在之前的AssetBundle文章中所提倡的资源依赖关系打包并进行预加载，

4、代码效率

即80%的性能开销都集中在20%的函数上

5、GC模块

虽然GC是用来处理内存的，但的确增加的是CPU的开销。因此它的确能达到释放内存的效果，但代价更加沉重，会加重CPU的负担，因此对于GC的优化目标就是尽量少的触发GC。
首先我们要明确所谓的GC是Mono运行时的机制，而非Unity3D游戏引擎的机制，所以GC也主要是针对Mono的对象来说的，而它管理的也是Mono的托管堆。而放到托管堆上的就是引用类型。
那么GC什么时候会触发呢？两种情况：
首先当然是我们的堆的内存不足时，会自动调用GC。
其次呢，作为编程人员，我们自己也可以手动的调用GC。

GC处理的是托管堆，而不是Unity3D引擎的那些资源，所以GC的优化说白了也就是代码的优化。需要注意：
a、字符串连接的处理。因为将两个字符串连接的过程，其实是生成一个新的字符串的过程。而之前的旧的字符串自然而然就成为了垃圾。而作为引用类型的字符串，其空间是在堆上分配的，被弃置的旧的字符串的空间会被GC当做垃圾回收。
b、尽量不要使用foreach，而是使用for。foreach其实会涉及到迭代器的使用，而据传说每一次循环所产生的迭代器会带来24 Bytes的垃圾。那么循环10次就是240Bytes。
c、不要直接访问gameobject的tag属性。比如if (go.tag == “human”)最好换成if (go.CompareTag (“human”))。因为访问物体的tag属性会在堆上额外的分配空间。如果在循环中这么处理，留下的垃圾就可想而知了。
d、使用“池”，以实现空间的重复利用。
e、最好不用LINQ的命令，因为它们会分配临时的空间，同样也是GC收集的目标。而且我很讨厌LINQ的一点就是它有可能在某些情况下无法很好的进行AOT编译。比如“OrderBy”会生成内部的泛型类“OrderedEnumerable”。这在AOT编译时是无法进行的，因为它只是在OrderBy的方法中才使用。所以如果你使用了OrderBy，那么在IOS平台上也许会报错。
f、最好不要频繁使用GetComponent，尤其在循环
g、善于使用OnBecameVisible()和OnBecameVisible(),来控制物体的update()函数的执行以减少开销。
h、使用内建的数组，比如用Vector3.zero而不是new Vector(0, 0, 0);
k、对于方法的参数的优化：善于使用ref关键字。值类型的参数，是通过将实参的值复制到形参，来实现按值传递到方法，也就是我们通常说的按值传递。复制嘛，总会让人感觉很笨重。比如Matrix4x4这样比较复杂的值类型，如果直接复制一份新的，反而不如将值类型的引用传递给方法作为参数。

 

6、材质实例数量

我们发现材质实例数量特别多，想问下这个对性能的影响如何，有没有什么建议？

Material的内存占用一般很小，所以大量的Material资源对于内存的压力其实很小的。但是，它本身对于场景的切换时间是有影响的，即资源冗余得越多，切换场景时，UnloadUnusedAssets的开销越大，进而增加了场景的切换时间，同时也会影响DrawCall的拼合

Unity3D内部内存
资源：纹理、网格、音频等等
GameObject和各种组件。
引擎内部逻辑需要的内存：渲染器，物理系统，粒子系统等等
Mono托管内存
值类型：int型啦，float型啦，结构体struct啦，bool啦之类的。它们都存放在堆栈上（注意额，不是堆所以不涉及GC）。
引用类型：其实可以狭义的理解为各种类的实例。比如游戏脚本中对游戏引擎各种控件的封装。其实很好理解，C#中肯定要有对应的类去对应游戏引擎中的控件。那么这部分就是C#中的封装。由于是在堆上分配，所以会涉及到GC。