在已經過去的兩個月中花了3周，總結了下龍2中的優化內容，目標是爲了新的項目做前期的規劃；涉及相關的項目中細節內容，不詳說，說下哪些可以規避的問題
一.工具類開發
1.查找重複或冗餘未使用的資源
2.查找超過1024尺寸的圖片工具並加入每日檢查
3.添加對於資源檢查的工具
對於美術資源的檢測，對於資源的規範性的檢測，可以減少一些資源是否合理的檢測代碼。
二.最小的Dome測試
1.對於引入第三庫的測試
2.某個設備崩潰的定位
3.快速驗證某個方案是否可行
從某種角度就是排除法定位問題，其實快速測試的驗證
三.表格的膨脹
隨着內容的推進，表格的數量越來越多，表內的數段和行數也越多，會有表格遍歷的性能問題，其次是加載和內容的速度影響。
1.方式是用到時加載，之前的項目都是遊戲啓動的時候加載。但現在目前不能採用這個方式。不然會帶來啓動時間變長。
2.啓動的時候，加載表的索引的，在讀表的時候正在加載表格，在一段時間後卸載
3.對於複雜的表或者行數多的表，使用常駐索引表。減少遍歷的消耗
四.字符串的噩夢
字符串的拼接帶來的性能問題，一直被困擾。
解決方案有兩種適用兩種不同的情況
1.每秒變化的文字，例如倒計時顯示的文字,C#unsafe memcpy
2.文字拼接。string.Formate（）或者stringBuilder
【Unity優化】Unity字符串String優化
Unity3D研究院之字符串拼接0GC（一百零四）
總結思路：
1.使用C# unsafe memcpy，是實現C語言的內存拷貝函數，內存佔用會多一些;
2.用StringBuilder,也有性能問題上，但處於能接受的範圍，一個是擴容，一個是toString()的。
3.還有一種方式String.Concat,如果不能確定最終長度，但是能夠確定字符串的個數，可以將它們放在一個數組中，並調用String.Concat進行連接
項目的在初始分配一個較大的StringBuilder(256)。完美解決StringBuilder拼接的問題。
補充還有一份詳細的講解
重談字符串連接性能上
重談字符串連接性能中
重談字符串連接性能下
五.代碼優化
比如一些函數，之前使用覺得並沒有問題，但隨着內容推進，是性能的瓶頸了。如AddComponent，耗時巨大，會導致瞬卡。看源碼，因爲使用泛型，所以是把所有的組件遍歷一遍，然後找到對應的類。這是也我覺得很意外的地方，Unity還有提高的地方。
1.有些代碼寫法，有一點性能提升。例如，如果需要判斷包含並且要使用value值，則把myDictionary.Contains(oneKey)改爲myDictionary.TryGetValue(oneKey, out myValue)，可減少冗餘的哈希次數；字典的key枚舉用int代替
2.協程的使用上；協程執行Update接口，需要使用WaitForSeconds時，最好先將變量生成好，不要每次創建，會產生開銷（開啓關閉用函數名，方便查找引用）。
3.遊戲中儘量不使用AddComponent，可以先在prefab上添加好Component。如果必須動態添加的話，使用XComponentHelper，優化銷燬和檢查引用的耗時
六.UE優化
這個有點老生常談了，UWA關於的這樣的方面的內容不少。
1.動靜分離
2.合理規劃圖集
3.對象儘量避免高頻使用setActive，會帶來大GC問題，推薦使用setscale或者canvasgroup，但是使用setscale需要注意動畫問題。（SetActiveByScale：scale 和alpha爲0的時候就不會再畫了，區別就是腳本還有沒有在runtime）
4.異步加載或者分幀加載。
5.預製儘量小，對於複雜的預製進行拆分
七.網絡優化
我之前沒關注過的部分，隨便寫一定，歡迎交流
1.協議優化，網絡包體減少，數據結構和字段類型
2.網絡協議使用Pool,回收內存。減少內存分配及減少GC
3.客戶端協議註冊改爲代碼生成（避免調用GetAllTypes 及訪問.BaseType 導致IL2CPP加載大量數據）
八.渲染優化
個人知識體系很少觸及的部分，說一些優化點
1.遊戲渲染分級，適配不同類型的機型用戶，根據手機設備顯示合適的渲染效果
2.植被系統，對於草的數據結構體優化，草的分佈密度，是否棄用Gupinstance
3.陰影的優化在多人情況下測試，對於不同渲染基本調整方案
4.shader精度優化
總結
有些問題，是藉助工具定位。Heap Explorer，可以看到項目中表格佔用5M的內存空間，String確實是佔用最多的。有些的內容，需要提前規劃清楚，有些問題只有在性能優化測試的時候，才發現暴漏問題的。看了這些優化的內容，理解其中思路。這是一個綜合考慮做出的選擇，是最恰當的。才能清楚自己有哪些實確很少涉及。自己的完全不懂這一內容。
——————
參考
Understanding Automatic Memory Management
Memory Management Reference