近期項目即將上線，爲了抗住數量衆多的玩家，流暢的進行多人同屏對戰，我們不得不對遊戲進行一次徹底的優化。
這個系列就是我對於此次優化的一些總結吧。
首先優化是足夠了解原理的基礎上並且輔以相應的工具才能順利進行，在優化GC裏，我們用到了Unity自帶的Profiler，這是一個非常優秀的工具，不僅僅支持編輯器下的調試，還可以看到在設備上的信息。
那麼，爲什麼要進行GC優化呢？
因爲GC積累到一定的量，Mono會自動回收內存，當自動回收的時候，會造成一定的卡頓，如果GC產生的速度非常快，這個過程就不斷頻繁的發生，就會導致遊戲不停的卡頓。
關於GC優化，我認爲有兩個部分是GC優化的重點：
1.Update中的GC優化
2.頻繁使用和銷燬的GO的緩存池
最終的目的就是，我們希望儘可能的把Mono自動回收內存這個過程放到加載中做，遊戲正常運行中儘量幹掉這個玩意。
先說說Update中產生的GC，Update中的GC是非常重要的而且是可以完全避免的，很多說到優化的文章都會寫到，如果Update中有10K的GC的話，每秒60幀，就有600K的GC，每分鐘36M，這是一個非常恐怖的量級，所以0GC的Update是遊戲穩定運行的核心。
再說說GC產生的原理，很簡單：向堆裏申請內存
無論是通過哪種途徑產生的GC，原理都是向堆裏申請內存。
另外GC的產生方式有下面幾種：
1. New Class ，注意 結構體New出來是不產生GC的，因爲結構體存在棧中
2. 裝箱拆箱
3. 字符串操作
4. 匿名函數(匿名函數本身並不會造成GC，但是一旦用到了閉包，也就是在匿名函數中使用了棧中的變量，C#就會自動將棧中的變量拷貝到堆裏面，進而實現閉包，具體我會在後面單獨寫一篇例子分析這個現象。)
值得注意的一點就是，Unity爲了讓用戶調試更加方便，或者是基於跨平臺的目的，在Editor中產生的GC可能在設備上並不會產生，所以真正要驗證是否存在GC或者是否消滅了GC，必須要到設備上驗證。