內存管理
Q：如圖，在Editor中查看Profiler裏的內存詳細信息，發現Used Total中有個“Unity”，請問是什麼意思？爲什麼會特別大？
A: 在Editor中運行時，“Unity”大是正常的，因爲在Editor中運行項目時，引擎包含了所有的資源佔用的內存（除了部分紋理和Mesh是在GFX中），同時自身會進行很多的輔助操作來記錄各種遊戲運行信息。
一般來說，在查看遊戲運行時的真實消耗內存，我們均是推薦直接在發佈遊戲上通過Profiler進行查看，在Editor中運行遊戲所看到的內存是要大很多的。
Q： 在進行內存優化時，Unity Profiler給出的數據和Android系統(adb dumpsys meminfo,已經考慮memtrack的影響 )的數據差距較大（已經分析了Profiler自身的內存佔用），如何分析這部分差異，比如包括對顯存消耗進行準確統計，OS消耗的統計等等？
A： 內存差異較大是正常的，一般來說，Profiler統計的內存較爲一致，而Android系統通過ADB反饋的PSS、Private Dirty等值則是差別很大。這主要是因爲芯片和OS的不同而導致。具體的Android內存，建議直接查看Google Android OS的相關文檔。
Unity Profiler反饋的則是引擎的真實物理使用內存，一般我們都建議通過Profiler來查看內存是否存在冗餘、泄露等問題。
Q：iOS上PVRTC不支持NPOT的貼圖壓縮，在Android上可以用ETC2，但在iOS上不能壓縮，內存消耗大。請問在iOS上有沒有好的處理方案？
A：ETC2僅能在支持OpenGL ES3.0的手機上進行使用，請研發團隊在使用前謹慎考察支持ES3.0的手機在國內的覆蓋範圍。
PVRTC不支持NPOT的貼圖壓縮，這是Apple規定的，上層應用無權對此更改。我們僅能建議將紋理儘可能做成POT形式，否則只能接受內存較大的開銷，沒有其他更好的辦法。
Q：怎樣動態加載Navmesh？
A：目前Navmesh不支持動態加載，只能隨場景一起加載， 因此可以考慮將帶有Navmesh的場景打包成AssetBundle，然後使用LoadLevel加載AssetBundle中的場景。
Navmesh的動態加載已經在Unity的Roadmap 中: http://unity3d.com/cn/unity/roadmap。
而當前，Navmesh是和場景綁定的，也就是說目前只能通過LoadLevel（不支持LoadLevelAdditive的加載方式）來加載場景的同時，自動加載對應的Navmesh數據。替代方案是：將多個“場景Prefab”的Navmesh 合併到同一個場景中烘焙好（互不重疊），然後再將這些“場景Prefab”分離到各個單獨的場景中去；在運行階段，Navmesh隨着第一個場景一次性加載，而對於其他的場景物件，再通過LoadLevelAdditive來加載對應的場景即可。缺點是爲了使場景物件對齊Navmesh，在場景製作時就不能出現座標上的重疊，因此僅供參考。
在Unity 5.x下，Lightmap的動態加載，需要通過腳本將烘焙時每個物件的Lightmapindex和Lightmapscaleoffset記錄下，並在運行時動態加載後設置回去的方式來實現。因爲目前Lightmapindex和Lightmapscaleoffset信息是和場景綁定在一起，儲存在Lightmapsnap.assets 中，發佈時也是放在場景信息中，因此不會記錄在Prefab 上。
Q：當關閉預渲染GI時會出現IndirectResolution,這個參數有什麼用，爲什麼調大了以後會大大增加渲染時間，但是烘培出來卻沒有什麼效果。
A：該值主要控制的是GI的烘焙密度，數值越大，表示每個單位距離內的Texel越多，即烘焙得越精緻，自然烘焙的時間也越長。該值並非越大越好，場景越小建議該值越低。該值爲1時，對於多數場景，其烘焙效果已經足夠了，升高該值，其效果也不會有明顯提升。