5-1 Optimization In Mobile Platform

由於從第5章之後的遊戲要往行動平台進行轉化，所以本章要來簡單整理Unity在行動平台優化的相關重點，也提供一些有用的教學資源給大家。

首先要讓大家先了解DrawCall的概念，以下引用網路上一段有用的解釋：

在Unity中，每次引擎準備數據並通知GPU的過程稱為一次Draw Call。
這一過程是逐個物體進行的，對於每個物體，不止GPU的渲染，引擎重新設置材質/Shader也是一項非常耗時的操作。因此每幀的Draw Call次數是一項非常重要的性能指標，對於iOS來說應盡量控制在20次以內，這個值可以在編輯器的Statistic窗口看到。
http://www.cnblogs.com/zhaoqingqing/p/4623839.html

DrawCall是如何影響性能的？
每一次繪製CPU都要調用DrawCall，而在調動DrawCall前，CPU還要進行很多準備工作：檢測渲染狀態、提交渲染所需要的數據、提交渲染所需要的狀態。而GPU本身俱有很強大的計算能力，可以很快就處理完渲染任務。

當DrawCall過多，CPU就會很多額外開銷用於準備工作，CPU本身負載，而這時GPU可能閒置了。做個試驗：拷貝1000個總大小1M的文件和單個大小為1M的文件，明顯拷貝1000個文件要慢很多，DrawCall調用和這個很類似。

DrawCall優化：減少DrawCall
既然，我們已經知道DrawCall導致的性能問題在於DrawCall數量過多，那麼我們優化的思路就是減少DrawCall。這裡我們只討論批處理（Batching）。

過多的DrawCall會造成CPU的性能瓶頸：大量時間消耗在DrawCall準備工作上。很顯然的一個優化方向就是：盡量把小的DrawCall合併到一個大的DrawCall中，這就是批處理的思想。
https://zhuanlan.zhihu.com/p/26386905

從Window/Profiler中即可打開性能用的監視視窗。

打開後點擊Rendering，然後下面的列表即可看到遊戲運行時的Draw Calls、Batched Draw Calls等資訊，大家可以依據這些資訊來觀察優化的成果。

於遊戲運行中時，按下左上角的Stats可以打開Unity Statistics統計面板，這邊同樣會即時顯示FPS、Batches等資訊。針對該統計面板，提供大家下列一教學文章，對於詳細了解這些資訊內容很有幫助。

【U3d】渲染统计窗口详细介绍(Rendering Statistics Window)

http://blog.csdn.net/wdmzjzlym/article/details/51335915

接著，我們要如何指定場景中的物體，讓Unity知道該物體需要列入Static Batch？先點擊場景中的靜態物體，如下圖中的一個橫躺在地面的樹幹。

然後於Inspector視窗中，選擇Static/Batching Static，便能將該靜態物體指定為Static Batch，能有效減少DrawCall次數。

https://hk.saowen.com/a/843fcf331d05ad5b73e140a7762ccc5cd86de9c2fdac60d9a1f3822e961f381f
從3D模型優化的角度來看，我們也希望行動平台能依下列數據優化3D模型：
　　Mesh方面：
　　　　動態模型：
　　　　　　面片數<3000,  材質數<3,  骨骼數<50
　　　　靜態模型：
　　　　　　頂點數<500
　　Audio方面：
　　　　長時間音樂（背景音樂）壓縮格式：mp3
　　　　短時間音樂（攻擊等等）一般不壓縮存儲格式為：wav
　　　　Decompress On Load：適用於小文檔
　　　　Compressed in Memory：使用於大文檔
　　　　Streaming：以流的形式便加載邊播放（對CPU消耗較大一般不採用）

　　Texture方面：
　　　　貼圖長度<1024（對手機而言）

　　Shader方面：
　　　　儘量減少複雜的數學運算
　　　　儘量減少Discard操作

如何減少冗余資源與重複資源：

1. Resource目錄下的資源不管是否被引用，都會被打包進安裝包，不使用的資源盡量不要放在Resource目錄。
2. 不同目錄下的相同資源文件，如果被引用，都會被打包進安裝包造成冗余。

Asset Bundle資源檢測與分析：
https://www.uwa4d.com/#assetbundle


下一章再替大家介紹更多性能優化的方法。