http://www.58player.com/blog-635-122.html

最近一段時間一直在做Unity 在IOS設備上的資源優化，結合Unity的官方文檔以及自己遇到的實際問題，我把自己認为一些重要的信息罗列在下面，並盡可能對將其量化，以方便更多需要做優化的朋友。

1、角色

每個角色盡量使用一個Skinned Mesh Renderer

這是因为當角色僅有一個Skinned Mesh Renderer時，Unity會使用可見性裁剪和包圍體更新的方法來優化角色的運動，而這種優化只有在角色僅含有一個Skinned Mesh Renderer時才會启動。

角色Material數量

2-3個

骨骼數量

小於30個

面片數量

300-1500

一般角色應該沒有IK結點

這是因为角色的動作大多數都是事先設定好的，並不需要經過IK操作來進行實時計算（Rogdoll除外），所以在模型導入時，不要將IK結點一起導入。

2、靜態實體

不要附加Animation Component

在靜態實體上附加Animation部件雖然對結果沒有影響，但卻會增加一定的CPU開銷來調用這一組件，所以盡量去掉該組件。

網格頂點數

小於500

UV值範圍盡量不要超過（0, 1）區間

盡量保證UV值不越界，這對於將來的紋理拼合優化很有幫助。

3、地形

地形的分辨率大小

長寬均盡量小於257。這是因为地形太大，會造成大量頂點數據，给你的內存帶寬造成一定的影響，在目前的ios設備中，內存帶寬是非常有限的，需要盡量節省。同時，如果用Unity自帶的地形，一定也要使用Occlusion Culling，因为Unity的刷地形工具雖然方便，但卻是framekiller，刷過之後，你會發現drawcall增加的非常多。

混合紋理數量

不要超過4。地形的混合操作是很耗時的，應該盡量避免。能合並的紋理盡量合並。

4、紋理

紋理格式

建議png或tga。不用轉成ios硬件支持的PVRTC格式，因为Unity在發布時會幫你自動轉的。

紋理尺寸

長寬小於1024。同時應該盡可能地小，夠用就好，以保證紋理對內存帶寬的影響達到最小。

支持Mipmap

建議生成Mipmap。雖然這種做法會增加一些應用程序的大小，但在遊戲運行時，系統會根據需求應用Mipmap來渲染，從而減少內存帶寬。

檢查Alpha值

如果紋理的alpha通道均为1，則用RGB的24位紋理來代替RGBA的32位紋理。（據說Unity內部會進行自動檢測）

5、光源

光源“Important”個數

建議1個，一般为方向光。“Important”個數應該越小越少。個數越多，drawcall越多。

Pixel Light數目

1-2個。

6、粒子特效

屏幕上的最大粒子數

建議小於200個粒子。

每個粒子發射器發射的最大粒子數

建議不超過50個。

粒子大小

如果可以的話，粒子的size應該盡可能地小。因为Unity的粒子系統的shader無論是alpha test還是alpha blending都是一筆不小的開銷。同時，對於非常小的粒子，建議粒子紋理去掉alpha通道。

盡量不要開启粒子的碰撞功能。

非常耗時。

7、音頻

遊戲中播放時間較長的音樂（如背景音樂）

使用.ogg或.mp3的壓縮格式。

較短音樂（如槍聲）

使用.wav和.aif的未壓縮音頻格式。

8、相機

裁剪平面

將遠平面設置成合适的距離。遠平面過大會將一些不必要的物體加入渲染，降低效率。

根據不同的物體設置不同的遠裁剪平面

Unity提供了可以根據不同的layer來設置不同的view distance，所以我們可以實現將物體進行分層，大物體層設置的可視距離大些，而小物體層可以設置地小些，另外，一些開銷比較大的實體（如粒子系統）可以設置得更小些等等。

9、碰撞

盡量不用MeshCollider

如果可以的話，盡量不用MeshCollider，以節省不必要的開銷。如果不能避免的話，盡量用減少Mesh的面片數，或用較少面片的代理體來代替。

10、其他

Drawcall

盡可能地減少Drawcall的數量。IOS設備上建議不超過100。減少的方法主要有如下幾種：Frustum Culling，Occlusion Culling，Texture Packing。Frustum Culling是Unity內建的，我們需要做的就是尋求一個合适的遠裁剪平面；Occlusion Culling，遮擋剔除，Unity內嵌了Umbra，一個非常好OC庫。但Occlusion Culling也並不是放之四海而皆准的，有時候進行OC反而比不進行還要慢，建議在OC之前先確定自己的場景是否适合利用OC來優化；Texture Packing，或者叫Texture Atlasing，是將同種shader的紋理進行拼合，根據Unity的static batching的特性來減少draw call。建議使用，但也有弊端，那就是一定要將場景中距離相近的實體紋理進行拼合，否則，拼合後很可能會增加每幀渲染所需的紋理大小，加大內存帶寬的負擔。這也就是为什麼會出現“DrawCall降了，渲染速度也變慢了”的原因。

非運動物體盡量打上Static標簽

Unity在運行時會對static物體進行自動優化處理，所以應該盡可能將非運行實體勾上static標簽。

場景中盡可能地使用prefab

盡可能地使用prefab的實例化物體，以降低內存帶寬的負擔。檢查實體的PrefabType，盡量將其變成PrefabInstance，而不是ModelPrefabInstance。

備注：優化是個無止境的過程，可優化的項目其實還有很多很多，比如腳本優化，shader優化等等，這些留待以後再慢慢添加。

原文链接：http://rritw.com/a/caozuoxitong/OS/20120426/160528.html

Unity3D在IOS上的优化小结