【技術小札】是UWA推出的技術交流欄目，我們會將開發團隊中反饋的常見問題加以總結並梳理在此，以供大家參考。同時如果你也是個熱愛分享、願與大家抱團進步的程序員，歡迎加入UWA的QQ群（465082844），與我們奇文分享，疑義相析。

精選5個性能優化問題，建議閱讀時間10分鐘，認真讀完必有收穫。如果您有任何獨到的見解或者發現也歡迎聯繫我們，一起探討。

內存管理

Q1：如圖，在Editor中查看Profiler里的內存詳細信息，發現Used Total中有個「Unity」，請問是什麼意思？為什麼會特別大？

在Editor中運行時，「Unity」大是正常的，因為在Editor中運行項目時，引擎包含了所有的資源佔用的內存（除了部分紋理和Mesh是在GFX中），同時自身會進行很多的輔助操作來記錄各種遊戲運行信息。一般來說，在查看遊戲運行時的真實消耗內存，我們均是推薦直接在發布遊戲上通過Profiler進行查看，在Editor中運行遊戲所看到的內存是要大很多的。

內存管理

Q2： 在進行內存優化時，Unity Profiler給出的數據和Android系統(adb dumpsys meminfo,已經考慮memtrack的影響 )的數據差距較大（已經分析了Profiler自身的內存佔用），如何分析這部分差異，比如包括對顯存消耗進行準確統計，OS消耗的統計等等？

內存差異較大是正常的，一般來說，Profiler統計的內存較為一致，而Android系統通過ADB反饋的PSS、Private Dirty等值則是差別很大。這主要是因為晶元和OS的不同而導致。具體的Android內存，建議直接查看Google Android OS的相關文檔。

Unity Profiler反饋的則是引擎的真實物理使用內存，一般我們都建議通過Profiler來查看內存是否存在冗餘、泄露等問題。

資源管理

Q3：iOS上PVRTC不支持NPOT的貼圖壓縮，在Android上可以用ETC2，但在iOS上不能壓縮，內存消耗大。請問在iOS上有沒有好的處理方案？

ETC2僅能在支持OpenGL ES3.0的手機上進行使用，請研發團隊在使用前謹慎考察支持ES3.0的手機在國內的覆蓋範圍。

PVRTC不支持NPOT的貼圖壓縮，這是Apple規定的，上層應用無權對此更改。我們僅能建議將紋理儘可能做成POT形式，否則只能接受內存較大的開銷，沒有其他更好的辦法。

資源載入

Q4：怎樣動態載入Navmesh？

目前Navmesh不支持動態載入，只能隨場景一起載入， 因此可以考慮將帶有Navmesh的場景打包成AssetBundle，然後使用LoadLevel載入AssetBundle中的場景。

Navmesh的動態載入已經在Unity的Roadmap中。而當前，Navmesh是和場景綁定的，也就是說目前只能通過LoadLevel（不支持LoadLevelAdditive的載入方式）來載入場景的同時，自動載入對應的Navmesh數據。替代方案是：將多個「場景Prefab」的Navmesh 合併到同一個場景中烘焙好（互不重疊），然後再將這些「場景Prefab」分離到各個單獨的場景中去；在運行階段，Navmesh隨著第一個場景一次性載入，而對於其他的場景物件，再通過LoadLevelAdditive來載入對應的場景即可。缺點是為了使場景物件對齊Navmesh，在場景製作時就不能出現坐標上的重疊，因此僅供參考。

在Unity 5.x下，Lightmap的動態載入，需要通過腳本將烘焙時每個物件的Lightmapindex和Lightmapscaleoffset記錄下，並在運行時動態載入後設置回去的方式來實現。因為目前Lightmapindex和Lightmapscaleoffset信息是和場景綁定在一起，儲存在Lightmapsnap.assets 中，發布時也是放在場景信息中，因此不會記錄在Prefab 上。

圖形渲染

Q5：當關閉預渲染GI時會出現IndirectResolution,這個參數有什麼用，為什麼調大了以後會大大增加渲染時間，但是烘培出來卻沒有什麼效果。

該值主要控制的是GI的烘焙密度，數值越大，表示每個單位距離內的Texel越多，即烘焙得越精緻，自然烘焙的時間也越長。

該值並非越大越好，場景越小建議該值越低。該值為1時，對於多數場景，其烘焙效果已經足夠了，升高該值，其效果也不會有明顯提升。

推薦閱讀：