容易忽略的美術資源的優化:
優化的美術製作真是一種感覺和經驗的積累,能看出製作水平的不是做的效果多麼犀利,而是得看製作的效果與對機器的要求等的性價比。
關於合併: 100個三角形的MESH,在渲染時與1500個面數的物體是沒太大差別的,最佳的渲染設置應該在每個模型大約1500-4000個三角面。
材質共享: 如果需要通過腳本來訪問複用材質屬性,改變Renderer.material將會造成一份材質的拷貝。應該使用Renderer.sharedMaterial來保證材質的共享狀態。
批處理動態物體需要在每個頂點上進行一定的開銷,也有一些約束:
對VB的顯存大小也有一定限制,如果着色器使用頂點位置,法線和UV值三種屬性,那麼只能批處理300頂點以下的物體;如果着色器需要使用頂點位置,法線,UV0,UV1和切向量,那隻能批處理180頂點以下的物體了。
擁有lightmap的物體含有額外(隱藏)的材質屬性,比如:lightmap的偏移和縮放係數等。所以,擁有lightmap的物體將不會進行批處理(除非他們指向lightmap的同一部分)。
使用不同縮放(scale)的物體將不能批次。分別擁有縮放尺度(1,1,1)和(2,2,2)的兩個物體將不會進行批處理。
另外一個值得吸收的經驗是非均勻縮放動畫在unity中非常的慢,均勻縮放會快很多。
骨骼數量控制:一般來說遊戲中的骨骼數量爲15-60個。骨骼越少運行速度越快,一般來說30塊骨骼就可以讓角色動的很舒服了。建議每個角色30個骨骼,就按照這個規範吧。
嘗試用壓縮貼圖格式,或用16位代替32位。
程序開發層面的注意點:
垃圾回收器收集垃圾內存時負載較大,對移動設備是個大問題,因此要從代碼層面減少臨時內存的生成,
1) 移除代碼中的任何字符串連接,因爲這會給GC留下大量垃圾。
2) 用簡單的“for”循環代替“foreach”循環。由於某些原因,每個“foreach”循環的每次迭代會生成24字節的垃圾內存。一個簡單的循環迭代10次就可以留下240字節的垃圾內存。
3) 更改我們檢查遊戲對象標籤的方法。用“if (go.CompareTag (“Enemy”)”來代替“if (go.tag == “Enemy”)”
使用#pragma strict 簡單的添加#pragma strict在腳本頂部,之後Unity將禁用腳本的動態類型,強制你使用靜態類型。
緩存各種組件、Object查找
儘量使用固定的內置數組:內置數組是非常快的。ArrayList或Array類很容易使用,更方便使用。但是他們有完全不同的速度。內置數組還有好處是,內存連續,元素對齊。
不要使用System,System.Xml以及其他系統自帶的DLL,會多出幾兆空間,找找開源的。
儘量採用內置的高效的shader吧,例如(built-in)Shader mobile,如果自己寫,複雜的數學計算函數別用,alphatest慎重(美術幾何挖洞來實現吧)。shader中注意float/half/fixed的使用