分享者Kelvin Lo 去年的?Unity優化分享蠻多反饋，今年整理了很多的優化技巧再次分享出來。

1. Unity Tech Talk
Kelvin Lo
Unity Evangelist
kelvinlo@unity3d.com
優化講座 II

2. 今天分享內容
•Unity優化分享
資源設定
CPU 相關優化
記憶體 相關優化
GPU 相關優化
UI 相關優化
特別感謝Unity工程師
Ian Dundore
Valentin Simonov
以及
Unity support team全體

3. 資源設定

4. 萬惡的預設值

5. 貼圖沒有壓縮
在某些情況下，美術會覺得紋理壓縮後效果不理想。我們建議的是：可以把原圖的分辨
率長寬都擴大一倍，保持原有壓縮格式。這樣壓縮過後的文件還是比不壓縮的文件要小
，並且視覺效果可以得到較大的改善。
Crunch壓縮是基於DXT或ETC的有損壓縮格式。貼圖會在CPU上解壓縮為DXT或ETC，
然後在Runtime時送到GPU上。 Crunch壓縮有助於想要讓下載包在硬碟時更小的專案。
要要注意的是Crunch壓縮會需要較長時間壓縮，但執行時解壓縮速度非常快。
貼圖取樣如果非必要32bit，可以改16-bit

6. 貼圖import settings裡的 Read/Write Enabled 處於勾選狀態
如果這裡有打勾 Read/Write Enabled，貼圖
在傳到GPU之後，同時也會保留一份在CPU
端的的記憶體。
由於手機設備會顯存和記憶體共用，會導致
記憶體佔用加倍。因此需要注意是否有需要
在CPU端存取的貼圖才需要打勾。
例如：需要通過腳本獲取貼圖像素的情況下
，該貼圖的 Read/Write Enabled就要打勾。

7. 除非腳本有用到以下功能才需要打勾
• 作為Mesh Collider裡用來碰撞的網格
• 腳本中用StaticBatchingUtility.Combine來
做靜態批次的網格
• 粒子系統發射的網格
• 其他自訂計算
除此之外的其它模型建議不要勾選此項 ，否
則會在記憶體內也保留一份網格實例佔用記
憶體。
模型import settings裡的 Read/Write Enabled 處於勾選狀態

8. 模型import settings裡的 沒用到的設定不要勾
如果BlendShapes沒有用到，所有模型的此
選項應該都關閉
如果這個模型沒有Normal貼圖，這裡應該設
為None, 省下一些Vertex資訊儲存的浪費
Tangents同理

9. 模型匯入時Rig頁籤裡的Optimize GameObject沒有設定
建議開啓Optimize GameObject，這個選項
可以把模型層級都壓在一起，節省了物件在
場景裡更新以及查詢的CPU運算消耗。
需要存取的物件記得把它拉出來白名單。
201.7.1之後OGO理論上打不打勾效能都應該差不多。
建議測試如果差不多就不要打勾

10. 10
採用FBX Exporter來導入模型
Unity FBX從以前和Prefab的關聯一直都是壞的，用Fbx Export可以確保關聯是正常的。

11. 使用第三方音源套件時沒有關閉Unity內建音源器
兩個情況可以關閉Unity的內建音源系統：
1.採用了第三方的音源系統
2.沒有音效的專案
可以從Edit->Project Settings->Audio-
>Disable Unity Audio來關閉FMOD模組，避
免不必要的CPU消耗。

12. 一些音源設定建議
1.當專案類型不需要立體聲時，設定為Mono
可以省一半記憶體。
2.太小的音效檔（<200KB）Load type應設
定為”Decompress On Load”。
3.200-1Mb大小的音源可以壓縮在記憶體。
4.大於1MB的音源建議要設定為Streaming。
*請注意：同一時間只能有一個streaming
Audio clip播放

13. 一些音源設定建議
Android平台建議所有的音源檔選Vorbis壓縮
格式。
iOS平台由於Unity沒用硬解，所以對於較短
的音源檔，建議設定為ADPCM，較長的音
源檔，建議Vorbis或直接用MP3壓縮。
ADPCM的壓縮比是3.5：1壓縮比，解壓縮成
本非常低，非常適合短音效。
MP3或Vorbis的音效會消耗較多資源進行解
壓縮，但壓縮比比較大。
對於很長像是背景音樂音效檔，建議使用
Vorbis，因為它可以更好地處理循環。

14. RESOURCES 目錄
Resources目錄對於一個”商品”專案，一般來說不建議使用:
1. 全部 “Resources” 目錄都會被包在一個很大塊的二進制結構
2. 4 Gb 上限, 沒辦法壓縮
3. 發佈時不管有沒有改變都會重新打包
4. 目錄裡面越多 Assets 會讓載入時間拖長
5. Runtime啟動時，Unity會幫這些資源產生index永遠放在記憶體裡
Resources是老舊系統，Unity不會繼續維護它
建議正式專案不要再使用，如果真的要用請在有把握的範圍使用

15. Asset Bundles群組建議
標頭資料 8KB
載入暫存區 16KB
序列化資料 72KB - SerializedFile dependency list
不同的樹狀結構資料 50KB+
每包Asset Bundles會消耗掉上述空間，如果打包規劃是以小包為
主的專案要特別注意太多包累積的空間消耗也是很可觀的
<2018.2將優化到4.5k

16. Asset Bundles打包建議
我們常常發現客戶不同的Asset Bundels包裡有相同的資源，比如貼圖。
可以用Asset Bundle browser或Asset Bundle Graph Tool來檢查是否有重複的資源
常見的情況是，無索引的資源被載入，然後又因為UnloadUnusedAssets被卸載。這種無用的
流程一直不斷的循環在背景執行。所以這裡要有良好管理
• 不要使用IgnoreTypeTree選項，容易造成問題。
• 對於版本控制，不要依賴Unity幫Asset Bundle產生的hash， 用CRC比較穩。
• 卸載Asset Bundles時，用AssetBundle.Unload（false）效能比較不好，用
AssetBundle.Unload（true）會自動處理得很好。

17. Asset Bundles下載建議
棄用WWW來載入AB，改用UnityWebRequest
改用UnityWebRequest有二個主要好處：
第一是UnityWebRequest可以將下載中的物件先存到磁碟，而非記憶體內。
第二是在傳送LZMA壓縮的包裝時（預設）時，UnityWebRequest會重新壓縮成LZ4格式，可
以提高暫存的載入時間。
由於載入資源時每幀從Assetbundle加載的Asset數量並沒有限制
導致有可能Loading時間過久是因為分配問題，在場景內每幀從Assetbundle加載的Asset數建
議限制在2到5個，數量太高時容易造成Lag。

18. 資源管理建議
一般來說，建議手動從專案裡移除任何沒用的腳本或套件。雖然編譯器會在打包時做這件事，但這樣
做有助於提高整體編譯時間。
善用AssetPostprocessorAPI來改善專案的資源匯入管理
他可以幫你在匯入Asset時執行你的判斷腳本，Unity的工程師Mark有寫一
個放在github上(MarkUnity/AssetAuditor)
如果懶得拿來改寫也可以研究Asset Bundle Graph Tool，裡面有相同功
能
除非必要，打包應該只包64bit的專案，包體會小很多。
Apple已經把100Mb上限提高到150Mb,這個問題沒有之前那麼大了。
[Android]Unity的工程師Dave Hampson寫了一個工具可以幫你把當機log從google轉回來，他能幫你
看到具體當機時呼叫的函式名稱，有助於除錯。

19. Json XML相關
靜態資料不要用 JSON 或 XML 傳
• 解析和傳輸都很慢
• 不會改變的資料確常常要被更新
不會改的靜態資料建議存在ScriptableObjects裡，寫個工具介面來管理。

20. CPU效能

21. CPU效能常見問題
太頻繁從腳本呼叫Camera.main
Camera.main實際是GameObject.FindGameObjectsWithTag(「
MainCamera」)呼叫，主要是因為Unity無法得知通過腳本設定的
MainCamera，CPU會消耗較高。建議腳本做Main Camera的
Cache。
腳本中大量對UnityEngine.Object的判斷操作
建議改為用InstanceID來判斷即Object. GetInstanceID，執行期間
保證唯一。因為Object的判斷是字串判斷且還有額外的耗時操作，
而Int類型的判斷就非常快速了。同理，使用Object作為key的數據
結構也建議改用InstanceID做key。

22. CPU效能常見問題
以下的物件都有相同的問題，建議有大量的操作也要有快取機制
• Reflection
• Find()
• Camera.main
• GetComponent()

23. CPU效能優化建議
當場景載入時，在第一幀更新之前，Unity會先做以下事情：
• 呼叫所有GameObjects上MonoBehaviours（關閉也一樣）的Awake()函式。
• 呼叫所有啟用MonoBehaviours的OnEnable()。
• 在執行完所有MonoBehaviours的Awake()和OnEnable()方法之後，在第一次
Update()呼叫之前呼叫所有的Start()方法。

24. CPU效能常見問題
一次Update Unity做了哪些事情？

25. CPU效能優化建議
在單一Frame裡的Update有太多東西執行
自訂Update管理器
如何實現：請參考Unity官方文章1000次的Update呼叫
針對你的專案定義不同的Update時機
例如：
判斷移動物件
檢查AI和循逕
Log和角色存檔
其他

26. CPU效能優化建議
在Player Settings裡有一個Prebake Collision Meshes可以打勾
可以節省載入時間，代價是包體變大
預設的情況下，Unity會在載入週期計算給PhyX用的網格資料
(會在Loading thread裡計算)，同個模型不同大小位置算一個
建議專案採用很多Mesh Colliders，又想加速載入時間的情況時啟用

27. CPU效能優化建議
Animator元件預設情況下只在Enable時保留暫存區的資料，代表當你disable它後這些資
料會被清除，在下次開啟時才會重建，當大量這種操作很容易造成Cpu負擔。
這個問題在2018.1之後會有一個
Animator.keepAnimatorControllerStateOnDisable 參數，設為 true
就會保留這些資料。

28. CPU效能優化建議
Debug.Log()其實是很耗效能的，Unity Profiler裡大部分CPU區塊有很大一部分用在產生Log的堆
疊。 這是Unity預設的，你可以用Application.SetStackTraceLogType()手動設定堆疊追蹤類型。
有三個選項：
Full - 這會產生一個完整的Log呼叫樹狀結構。
ScriptOnly - 這只會產生一個託管碼(Managed code)的樹狀結構。
None - 這只會輸出用戶餵給記錄器的Log。
在大多數情況下，我們建議使用None選項。在需要記錄完整的呼叫堆疊資料的時候runtime去改變
Log type。
您只要追蹤 Application.logMessageReceivedThreaded事件就能看到何時Log被觸發，這個事件
也支援log type，所以可以切換不同的紀錄類別。

29. CPU效能優化建議
當透過腳本同時修改物件座標和旋轉時，儘量用SetPositionAndRotation()，不要單獨修改
Transform的值，效能比較好。
如果可以，儘量用本地座標(Local)而非世界座標(World)，因為Unity實際存的是本地座標，所以會
有一個遍歷的效能損失。
Don’t Destroy on Load要小心使用，要記得場景卸載後要手動卸載這些物件，以免造成記憶體溢位
在系統最繁忙時呼叫SendMessage()，如果可以，能不用SendMessage就不用
由於實例化(Instantiating)物件很慢，儘量用物件池來管理物件

30. CPU效能優化建議
粒子系統依照不同的大小會佔用記憶體從最簡單的粒子系統3.5Kb到使用許多模組時會增加到25 +
Kb。 即使關閉也是會佔用記憶體，因此在場景中有大量不用的粒子系統對記憶體很不好。
第一個優化方向應該是減少場景中的粒子系統數量。
然後就可以朝以下幾個方向優化：
• 減少噴發粒子數量（預設為1000）
• 噴Billboard而不是Mesh。
• 減少每個粒子系統上的模組數量
• 粒子特效在呼叫Start, Stop, Pause, Clear等等的函式時，可以把withChildren設為False

31. GC分配量的建議
專案GC分配越頻繁，量越大，由於Mono記憶
體池可用記憶體不足導致的GC.Collect（常見
造成Lag的原因之一）呼叫就會越頻繁，並且
可能引起mono記憶體池不必要的擴展，因此
腳本函數的GC分配量是既影響CPU也影響記
憶體的重要參數。
建議設定：
對於每幀都會分配GC的函數，GC分配量大於
2KB都建議優化。對於偶爾分配GC的函數，
GC分配量大於10KB的建議都確認下分配的數
據結構是否有優化空間。

32. GPU效能

33. Shader的建議事項
• 手遊專案儘量不要用Standard Shader。 因為Standard Shader對手機平台並沒有優化處理。
• Pass能合併就合併，RenderTexture能共用就共用
• 當一個Shader variant第一次被使用時，你會發現Unity在Shader.CreateGPUProgram()中耗
了花費的時間異常的多，很容易造成CPU尖峰。為了緩解這種情況，您可以把這些場景中使
用的Shader紀錄起來，保存到Graphics Settings裡：

34. Shader的注意事項
• ShaderVariantCollection可以放入包含專案所需的所有Shaders。 使用此功能時Unity會在第
一個場景載入之前編譯裡面所有的Shaders。確保它們可以提前使用。
• 或者，您也可以呼叫Shaders.WarmUpShaders（），但此函數提供的控制參數較少。
Shaders.WarmUpShaders()在Metal有問題
確保修復了才用

35. Shader的注意事項
從Profiler可以看到Shader的用量(ShaderLab Allocations)，當你發現某些Shader佔用太多記
憶體時，可以從打包的log來算出這些Shader大概會在runtime時佔用多少記憶體。
例如拿Unity的Standard Shader來當範例：
Compiled shader 'TEST Standard (Specular setup)' in 31.23s
d3d9 (total internal programs: 482, unique: 474)
d3d11 (total internal programs: 482, unique: 466)
metal (total internal programs: 482, unique: 480)
glcore (total internal programs: 482, unique: 454)
從這個範例來看Shader展開了482個variants。
這個Shader會壓成大約是:
0.14 + 0.12 + 0.20 + 0.15MB = 0.61MB
在Runtime期間這包0.61Mb會整包放在記憶體裡
然後針對當下的執行平台會解開 (比如 Metal 為2.55Mb)。

36. GPU優化建議
• 採用Forward rendering path但又在場景打太多動態光源是很耗效能的。
因為每盞燈都會幫每個照明物件產生一個render pass
善用Unity Frame debugger
Draw Call的批次處理能降低GPU
的消耗，但是要達到一些條件才
能批次處理，這時可以用這個工
具來看哪些地方沒有被批次處理。

37. GPU優化建議
沒有要發佈的平台就不要預設啟用，在製作後
製時，處理Image Effect會宣告一個螢幕解析
大小的記憶體暫存區。
例如：iPad Air的解析度已經達到2048x1536
，一個全螢幕的Render buffer可能會用掉
24mb~36mb的記憶體，減少一半的render
buffer可以少75%的記憶體用量
用Unity官方的Post processing Stack工具會比
較好

38. GPU優化建議
[Mobile] Unity的Post processing stack是很好的後製特效工具，但在手機上有很多限制：
不能用：
Ambient Occlusion(耗效能)
SSR(耗效能且必須用Deferred渲染通道)
TAA(需要支援motion vectors)
大量的Motion Blur(同上)
Eye adaptation(手機不支援)
Color Grading運用浮點材質格式，太低端的手機不支援

39. UI效能

40. 2017新加的UI Profiler
Unity 2017.1在 Profiler加了一個新的UI分類，可以用來檢查為何UI沒有被批次處理的原因：

41. 2017新加的UI Profiler
批次處理會分開的原因如下：
• UI有不同的Z軸。
• 每當專案有nested canvas，然後UI需要在其他UI元素之間顯示Canvas時，就會切斷批次處
理。例如，如果nested canvas有個下拉式選單要顯示，那他必須中斷之前的批次處理確保下
拉式窗口會顯示在最上層。
• 當UI具有不同的材質時，我們需要使用該材質建立一個新的批次處理來分開渲染。
• 當我們遇到不同裁切範圍就會中斷批次。
• 每當UI具有不同的貼圖時，我們需要建立一個具有該貼圖的新批次處理來分別渲染它們。

42. UI的一些建議
UI在需要隱藏的時候不要用調整Alpha為0的方式
實際上GPU依然需要對UI mesh進行渲染，建議用移出畫面的方式。
UI儘量不要疊太多層來達到美術效果，這樣很容易造成Overdraw，建議盡量越少層越好。
會動的UI和不會動的UI要分開Canvas，不要放在同一個Canvas
很多會動的UI依照區塊切開Canvas，不要放在同一個Canvas

43. UI的一些建議
所有的Canvas Renderers在建立時預設都會啟用
Raycast Target屬性。這會導致touch事件的成本增
加。建議把不需要觸碰的Canvas Renderer上關閉
Raycast Target選項，降低Touch事件造成的CPU成
本。
每個Canvas預設都有一個GraphicRaycaster元件。
每一幀GraphicRaycasters都會針對每個上層
Canvas的所有可互動UI元素進行檢查動作，然後分
派對應的UI事件處理程序。當可互動的元件一多就
會造成CPU效能下降。因此，應檢查不需要Graphic
Raycasters的物件就應該移除掉。
World Space Canvas的Event Camera永遠不要空
白

44. 總結

45. FBX Exporter工具介紹
https://youtu.be/UALFg-xfJu0
1000次Update呼叫
http://unitytaiwan.blogspot.tw/2016/01/1000update.html
Android Crash 檢查工具
https://bitbucket.org/davehampson/symbolicate
Mark寫的AssetAuditor工具
https://github.com/MarkUnity/AssetAuditor
Aras’s Blog Shader Compression
https://aras-p.info/blog/2016/09/13/Shader-Compression-Some-Data/
Ian的Unite優化講座
https://www.youtube.com/watch?v=_wxitgdx-UI
PPT
https://www.slideshare.net/secret/xLig7llwdlRQIp
最佳實踐系列
https://unity3d.com/learn/tutorials/s/best-practices

46. Thank you!!
更多Unity資料請關注：
https://www.facebook.com/UnityTechTaiwan/