http://www.cnblogs.com/murongxiaopifu/p/4284988.html 深入淺出聊優(yōu)化：從Draw Calls到GC
CPU優(yōu)化
1.DrawCall優(yōu)化
2.物理組件
3.GC
4.代碼質(zhì)量
GPU優(yōu)化
1.填充率，可以簡單的理解為圖形處理單元每秒渲染的像素數(shù)量硅堆。
2.像素的復(fù)雜度，比如動態(tài)陰影，光照好啰，復(fù)雜的shader等等
3.幾何體的復(fù)雜度（頂點(diǎn)數(shù)量）
4.當(dāng)然還有GPU的顯存帶寬
也可以概括為兩點(diǎn)：1.減少繪制數(shù)目 2.優(yōu)化顯存帶寬
內(nèi)存優(yōu)化
1.unity3D內(nèi)部內(nèi)存
2.Mono托管內(nèi)存
兩種情況GC會被觸發(fā)：
堆的內(nèi)存不足時自動調(diào)用GC缠犀。
手動的調(diào)用GC硬毕。
減少GC回收要注意一下問題：
字符串連接的處理。使用StringBuilder或String.Format來代替而不是用”+”來進(jìn)行連接颜及。因?yàn)閷蓚€字符串連接的過程，其實(shí)是生成一個新的字符串的過程蹂楣。而之前的舊的字符串就成為了垃圾俏站。而作為引用類型的字符串，其空間是在堆上分配的捐迫，被棄置的舊的字符串的空間會被GC當(dāng)做垃圾回收乾翔。
盡量不要使用foreach，而是使用for。foreach會涉及到迭代器enumerator的使用反浓，而據(jù)傳說每一次循環(huán)所產(chǎn)生的迭代器會帶來24 Bytes的垃圾萌丈。那么循環(huán)10次就是240Bytes。
不要直接訪問gameobject的tag屬性雷则。比如if (go.tag == “human”)最好換成if (go.CompareTag (“human”))辆雾。因?yàn)樵L問物體的tag屬性會在堆上額外的分配空間。如果在循環(huán)中這么處理月劈，留下的垃圾更多度迂。
使用“池”，以實(shí)現(xiàn)空間的重復(fù)利用猜揪。
盡可能避免使用LINQ惭墓。部分功能無法在某些平臺上使用，會分配大量GC Alloc而姐。而且我很討厭LINQ的一點(diǎn)就是它有可能在某些情況下無法很好的進(jìn)行AOT編譯腊凶。比如“OrderBy”會生成內(nèi)部的泛型類“OrderedEnumerable”。這在AOT編譯時是無法進(jìn)行的拴念，因?yàn)樗皇窃贠rderBy的方法中才使用钧萍。所以如果你使用了OrderBy，那么在IOS平臺上也許會報錯政鼠。
緩存組件:
1.每次GetComponent均會分配一定的GC Allow.
2.每次Object.name都會分配39B的堆內(nèi)存.
協(xié)程Coroutine风瘦，開啟一個協(xié)程，至少分配373的內(nèi)存公般。
盡量減少New的使用万搔。
Lambda表達(dá)式，使用不當(dāng)會產(chǎn)生內(nèi)存泄漏官帘。
用Struct代替Class蟹略。
