渲染大面積草地時，如何下降消耗？

1）在渲染大面積草地時，如何下降消耗
2）使用LoadFromMemory致使內存翻倍問題
3）對Android x86平臺的支持問題
4）OnGUI的堆內存分配問題

---

Rendering

Q：請問下你們，渲染大面積草地時，如何下降消耗呢？

A1：回答以下：
1.使用DrawMeshInstance；
2.上面這個API是不會進行視距剔除、視錐體剔除和遮擋剔除的。

下面有兩種方案：
a.將草地按區域分組，用每組的中心點計算視距，依據距離切換網格LOD或剔除；還能用向量點乘簡單剔除在相機後方的草地（注意臨界問題）。
b.藉助CullingGroup。
CullingGroup.onStateChanged事件綁定，經過事件觸發調整傳入；DrawMeshInstanced的Matrix順序和渲染數量（可是DrawMeshInstanced只能指定渲染前幾個Matrix）；
經過cullingGroup.SetBoundingSpheres實現視錐體剔除和遮擋剔除；
經過cullingGroup.SetBoundingDistances實現視距剔除和LOD。
這個方案最好也進行區域分組，否則CullingGroup的事件監聽佔用會比較高，在中端機上4000個監聽會佔約2ms的大小。

之後若是有對比兩種方案的性能，我再進行補充。

附：

1. 《CullingGroup API的使用說明》
2. 《Unity 3D研究院之Lightmap支持GPU Instancing》
3. 《如何高效使用GPU Instancing技術來進行草叢渲染》
4. 升級Unity 2018，DrawMeshInstanced不生效的問題

感謝題主李先生@UWA問答社區提供了回答

A2：使用Indirect模式的Instancing，配合Compute Shader實現視錐剔除和遮擋剔除。

感謝鄒春毅@UWA問答社區提供了回答

---

AssetBundle

Q：UWA的幾篇文章中都有說到儘可能不要用AssetBundle.LoadFromMemroy接口，由於這個接口會使得內存的佔用翻倍，可是我用Unity 2017.4.5f1進行測試後，發現AssetBundle.LoadFromMemroy和AssetBundle.LoadFromFile幾乎是沒有差異的，由於文章中也沒有關於體積具體的版本信息。因此我想問是以前的Unity 4.x或者Unity 5.x版本纔有這個問題？仍是說測試用例是有要求的呢？

另外，我是在PC上進行測試的，打包出exe，直接用任務管理器查看內存佔用狀況，發現並無區別。

A1：應該是在C++裏面直接申請一塊內存用來解壓，Mono佔用不會變可是PSS會增大，內存峯值也會變高，使用adb shell dumpsys meminfo packageName來查看PSS。

若是目標平臺是PC，那就說明內存策略多是分配後當即歸還給操做系統了。若是PC不是目標平臺，那麼看內存就沒有很大的意義。
感謝張迪@UWA問答社區提供了回答

A2：LoadFromMemroy輸入的byte數組用的是Mono堆內存，哪怕這個內存有釋放，但Mono堆內存總量是隻升不降的，在加載資源的過程當中，一旦Mono觸發GC後仍內存不夠，極可能須要申請新的Mono內存，這會致使Mono內存持續升高。

並且用LoadFromMemroy沒有必要性，用這個接口哪怕內存不是問題，也會在加載資源時明顯比LoadFromFile慢很多，並且真的想要逆向AssetBundle資源仍是很容易的。退一步說，非要加密建議使用LoadFromStream，而後本身去實現Stream解密。
感謝loy_liu@UWA問答社區提供了回答

A3: 我以前的測試有問題，如今更正一下：LoadFromMemroy即便在PC平臺也不如LoadFromFile接口。

經測試，PC上LoadFromMemroy接口內存的佔用大概會高1/5左右，加載時間比LoadFromFile接口慢1/5左右，並且如loy_liu所說，LoadFromMemroy接口須要先讀取byte數組，會產生Mono內存的分配問題，而LoadFromFile不會。在Android平臺上，內存的對比很是誇張，我這邊測試的數據翻了接近3倍。

因此儘可能不要使用LoadFromMemroy接口，我沒有去測試LoadFromStream接口的性能和內存，但聽說和LoadFromFile差很少。
感謝題主fdy@UWA問答社區提供了回答

A4: Lzma的資源包LoadFromMemory會致使資源自己翻倍。L4z資源包相似於管理器，自己佔用內存很小，翻倍也不要緊，而內存流自己也是用完就能扔。

感謝歐月鬆@UWA問答社區提供了回答

---

Build

Q：目前項目發佈後大於100MB，檢查發現是libil2cpp.so較大，大概大於60MB，並且同時支持了ARMv七、ARM6四、x86，至關於x3的大小。因此想問一問你們，目前x86架構的機型大概佔比多少？須要繼續支持嗎？

A1: 不必，我建議去掉。
感謝loy_liu@UWA問答社區提供了回答

A2: 大多數模擬器都是X86，能夠考慮下。
感謝歐月鬆@UWA問答社區提供了回答

A3: 須要支持，不然模擬器會很卡。

感謝Fly@UWA問答社區提供了回答

---

Memory

Q：在PC上運行遊戲，用Profile工具檢測的時候，發現GUIUtility.BeginGUI內存泄漏，每次調用產生0.8KB的內存消耗，每幀調用4次，就是3.2KB。請問這是什麼緣由引發的呢？

A：OnGUI必然有GC Alloc，即便是空函數。你能夠拿宏括起來，用來作Profiling的包不要編譯進去。

感謝littlesome@UWA問答社區提供了回答

---

今天的分享就到這裏。固然，生有涯而知無涯。在漫漫的開發週期中，您看到的這些問題也許都只是冰山一角，咱們早已在UWA問答網站上準備了更多的技術話題等你一塊兒來探索和分享。歡迎熱愛進步的你加入，也許你的方法恰能解別人的燃眉之急；而他山之「石」，也能攻你之「玉」。

官網：www.uwa4d.com
官方技術博客：blog.uwa4d.com
官方問答社區：answer.uwa4d.com
UWA學堂：edu.uwa4d.com 官方技術QQ羣：793972859（原羣已滿員）