容易忽略的美術資源的優化：
優化的美術製作真是一種感覺和經驗的積累，能看出製作水平的不是做的效果多麼犀利，而是得看製作的效果與對機器的要求等的性價比。
關於合併： 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的使用