基於Unity3d 引擎的Android遊戲優化（轉）

轉載源：http://www.manew.com/thread-47240-1-1.html

最近項目進入收尾階段，以前對項目作了不少優化，mesh合併 ，減小DrawCall和模型骨骼以及物理計算，合併材質球，優化代碼等等，在IOS上還好，可是上，試過幾款手機，從低端到高端，發現性能仍是不好，因此又花了幾天來研究摸索，終於把遊戲性能搞定。記錄下來，留做之後參考。

　　1. 更新不透明貼圖的壓縮格式爲ETC 4bit，由於android市場的手機中的GPU有多種，每家的GPU支持不一樣的壓縮格式，但他們都兼容ETC格式，

　　2. 對於透明貼圖，咱們只能選擇RGBA 16bit 或者RGBA 32bit。

　　3. 減小FPS，在ProjectSetting-> Quality中的VSync Count 參數會影響你的FPS，EveryVBlank至關於FPS=60，EverySecondVBlank = 30；

　　這兩種狀況都不符合遊戲的FPS的話，咱們須要手動調整FPS，首先關閉垂直同步這個功能，而後在代碼的Awake方法裏手動設置FPS（Application.targetFrameRate = 45;）

　　下降FPS的好處：

　　1）省電，減小手機發熱的狀況；

　　2）能都穩定遊戲FPS，減小出現卡頓的狀況。

　　4. 當咱們設置了FPS後，再調整下Fixed timestep這個參數，這個參數在ProjectSetting->Time中，目的是減小物理計算的次數，來提升遊戲性能。

　　5. 儘可能少使用Update LateUpdate FixedUpdate，這樣也能夠提高性能和節省電量。多使用事件（不是SendMessage，使用本身寫的，或者C#中的事件委託）。

　　6. 待機時，調整遊戲的FPS爲1，節省電量。

　　VSync Count 垂直同步

　　中新建一個場景空的時候，幀速率（FPS老是很低），大概在60~70之間。一直不太明白是怎麼回事，如今基本上明白了。我在這裏解釋一下緣由，若有錯誤，歡迎指正。在Unity3D中當運行場景打開Profiler的時候，咱們會看到VSync 這一項佔了很大的比重。這個是什麼呢，這個就是垂直同步，稍後再作解釋。咱們能夠關閉VSync來提升幀速率，選擇edit->project settings->Quality 在右側面板中能夠找到VSync Count ,把它選成Don't Sync。這就關閉了VSync(垂直同步)，如今在運行場景看看，幀速率是否是提升不少。

　　如今來講說什麼是垂直同步，要知道什麼是垂直同步，必需要先明白顯示器的工做原理，顯示器上的全部圖像都是一線一線的掃描上去的，不管是隔行掃描仍是逐行掃描，顯示器都有兩種同步參數——水平同步和垂直同步。

　　什麼叫水平同步？什麼叫垂直同步？

　　垂直和水平是CRT中兩個基本的同步信號，水平同步信號決定了CRT畫出一條橫越屏幕線的時間，垂直同步信號決定了CRT從屏幕頂部畫到底部，再返回原始位置的時間，而偏偏是垂直同步表明着CRT顯示器的刷新率水平。

　　爲何關閉垂直同步信號會影響遊戲中的FPS數值？

　　道理一點都不復雜，首先咱們平時運行操做系統通常屏幕刷新率是多少？大概通常都是在85上下吧，那麼顯卡就會每按照85的頻率時間來發送一個垂直同步信號，信號和信號的時間間隔是上兩次屏幕更新的時間間隔。

　　若是咱們選擇等待垂直同步信號（也就是咱們平時所說的垂直同步打開），那麼在遊戲中或許強勁的顯卡迅速的繪製完一屏的圖像，可是沒有垂直同步信號的到達，顯卡沒法繪製下一屏，只有等85單位的信號到達，才能夠繪製。這樣FPS天然要受到操做系統刷新率運行值的制約。

　　而若是咱們選擇不等待垂直同步信號（也就是咱們平時所說的關閉垂直同步），那麼遊戲中做完一屏畫面，顯卡和顯示器無需等待垂直同步信號就能夠開始下一屏圖像的繪製，天然能夠徹底發揮顯卡的實力。可是不要忘記，正是由於垂直同步的存在，才能使得遊戲進程和顯示器刷新率同步，使得畫面更加平滑和穩定。取消了垂直同步信號，當然能夠換來更快的速度，可是在圖像的連續性上勢必打折扣。這也正是不少朋友抱怨關閉垂直後發現畫面不連續的理論緣由。

　　一、頂點性能

　　通常來講，若是您想在iPhone 3GS或更新的設備上每幀渲染不超過40,000可見點，那麼對於一些配備 MBX GPU的舊設備（好比，原始的iPhone，如 iPhone 3g和 iPod Touch第1和第2代）來講，你應該保證每幀的渲染頂點在10000如下。

　　二、光照性能

　　像素的動態光照將對每一個受影響的像素增長顯着的計算開銷，並可能致使物體會被渲染屢次。爲了不這種狀況的發生，您應該避免對於任何單個物體都使用多個像素光照，並儘量地使用方向光。須要注意的是像素光源是一個渲染模式（Render Mode）設置爲重要（Important）的光源。像素的動態光照將對頂點變換增長顯着的開銷。因此，應該儘可能避免任何給定的物體被多個光源同時照亮的狀況。對於靜態物體，採用烘焙光照方法則是更爲有效的方法。

　　三、角色

　　每一個角色儘可能使用一個Skinned Mesh Renderer,這是由於當角色僅有一個 Skinned Mesh Renderer 時， Unity 會 使用可見性裁剪和包圍體更新的方法來優化角色的運動，而這種優化只有在角色僅含有一個 Skinned Mesh Renderer 時纔會啓動。角色的面數通常不要超過1500，骨骼數量少於30就好，角色Material數量通常1~2個爲最佳。

　　四、靜態物體

　　對於靜態物體定點數要求少於500，UV的取值範圍不要超過（0,1）區間，這對於紋理的拼合優化頗有幫助。不要在靜態物體上附加組件，雖然加了對結果沒什麼影響，可是會增長CPU開銷。

　　五、攝像機

　　將遠平面設置成合適的距離，遠平面過大會將一些沒必要要的物體加入渲染，下降效率。另外咱們能夠根據不一樣的物體來設置攝像機的遠裁剪平面。Unity 提供了能夠根據不一樣的 layer 來設置不一樣的 view distance ，因此咱們能夠實現將物體進行分層，大物體層設置的可視距離大些，而小物體層能夠設置地小些，另外，一些開銷比較大的實體（如粒子系統）能夠設置得更小些等等。

　　六、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 降了，渲染速度也變慢了」的緣由。