http://www.cnblogs.com/murongxiaopifu/p/4284988.html 深入浅出聊优化：从Draw Calls到GC
CPU优化
1.DrawCall优化
2.物理组件
3.GC
4.代码质量
GPU优化
1.填充率，可以简单的理解为图形处理单元每秒渲染的像素数量。
2.像素的复杂度，比如动态阴影，光照，复杂的shader等等
3.几何体的复杂度（顶点数量）
4.当然还有GPU的显存带宽
也可以概括为两点：1.减少绘制数目 2.优化显存带宽
内存优化
1.unity3D内部内存
2.Mono托管内存
两种情况GC会被触发：
堆的内存不足时自动调用GC。
手动的调用GC。
减少GC回收要注意一下问题：
字符串连接的处理。使用StringBuilder或String.Format来代替而不是用”+”来进行连接。因为将两个字符串连接的过程，其实是生成一个新的字符串的过程。而之前的旧的字符串就成为了垃圾。而作为引用类型的字符串，其空间是在堆上分配的，被弃置的旧的字符串的空间会被GC当做垃圾回收。
尽量不要使用foreach，而是使用for。foreach会涉及到迭代器enumerator的使用，而据传说每一次循环所产生的迭代器会带来24 Bytes的垃圾。那么循环10次就是240Bytes。
不要直接访问gameobject的tag属性。比如if (go.tag == “human”)最好换成if (go.CompareTag (“human”))。因为访问物体的tag属性会在堆上额外的分配空间。如果在循环中这么处理，留下的垃圾更多。
使用“池”，以实现空间的重复利用。
尽可能避免使用LINQ。部分功能无法在某些平台上使用，会分配大量GC Alloc。而且我很讨厌LINQ的一点就是它有可能在某些情况下无法很好的进行AOT编译。比如“OrderBy”会生成内部的泛型类“OrderedEnumerable”。这在AOT编译时是无法进行的，因为它只是在OrderBy的方法中才使用。所以如果你使用了OrderBy，那么在IOS平台上也许会报错。
缓存组件:
1.每次GetComponent均会分配一定的GC Allow.
2.每次Object.name都会分配39B的堆内存.
协程Coroutine，开启一个协程，至少分配373的内存。
尽量减少New的使用。
Lambda表达式，使用不当会产生内存泄漏。
用Struct代替Class。
