Q1:在UWA的測評結果中,我們的Mesh檔案記憶體過高(使用UWA GOT測試最大的場景會達到200MB),大部分是由于場景的物件導緻的。我們的場景物件是這樣加載的:場景有一個基礎的架構(地面、天空盒和個别大的物件等),在進入場景後,會根據位置來加載其他的物件,加載的物件在離開視野後,為了防止下次再加載,隻将其隐藏了,并沒有銷毀,這樣的話,人物如果在場景裡跑了一圈,就相當于整個場景的物件,都會進入記憶體。請問,是不是将離開視野的場景物件銷毀比較好呢,銷毀後是不是要調用UnloadUnusedAssets才能徹底從記憶體中去除呢?
如果題主做的是移動遊戲,那麼200MB确實太大了。 建議題主建立一個Memory Pool來緩存場景中的物體,至少有以下兩個規則: (1)Pool必須有一個上限,一般為容器的數量,超過最大門檻值後即開始進行清理; (2)為Pool中每個Object記錄一個存儲時間,當時間超過一定門檻值後進行清理,或者當Pool滿了後,将時間最長的進行Deactive Object進行清理。 通過緩存池來進行銷毀較長時間不再顯示的的物體,同時,可以通過UnloadAsset API來解除安裝相關的資源,Resources.UnloadUnusedAssets API一般隻建議在場景切換處進行使用。
該問題來自UWA問答社群,如您對該問題仍有疑問,可以轉至社群進行進一步交流。
https://answer.uwa4d.com/question/59f2da210558dee424da9d69
Q2:Unity版本:5.6.1f1,如果使用Static Splash Image , 一張1000×500的圖大約會占用30MB~40MB的記憶體(PSS值變化),并且這個記憶體沒有釋放的迹象,感覺像是個Bug。
我們對這個問題進行了測試,看上去這個問題是Unity 5.6.1的Bug,在5.6.2版本中應該已經被修複了。下面是我們的測試方式: Unity測試版本:Unity 5.6.2 測試裝置:紅米4X 測試步驟: 1、當沒有加入Splash Image 時,空場景項目加載後,其PSS記憶體占用情況如下圖所示:2、項目中放入如下的24MB Splash Image。![]()
技術分享連載(八十四) 3、當紋理不壓縮時,其項目啟動後,PSS記憶體确實明顯上漲了,由之前的51796KB上升到85747KB。![]()
技術分享連載(八十四) 但僅過一小段時間(<30s),PSS記憶體就降下去了,回落到52083KB,可見原來較大的Splash Image已經被釋放。![]()
技術分享連載(八十四) 我們在該裝置上進行了多次測試,均得到類似的結果。對此,我們的建議如下: (1)嘗試更新Unity引擎,在Unity5.6.2以上版本中進行測試,看是否還會出現PSS記憶體不回落現象; (2)嘗試在其他裝置上進行測試,檢視是否是特定裝置帶來的記憶體問題。![]()
技術分享連載(八十四)
https://answer.uwa4d.com/question/59f1d1414bcaad4150f9e5bb
Q3:異步紋理加載Asynchronous Texture Upload這個功能最後到底有沒有實用?
就是這個東西,按理應該是解決異步加載時,紋理卻隻能同步加載的問題,現在界面上也一直有這設定,但我翻到網上介紹的時候看到如下資訊:
這個是預設就開啟的,隻是得開啟多線程渲染才有效,因為要在 Render Thread 裡上傳紋理,還有文檔裡提到的各種限制,比如隻針對關閉了 Read/Write 的紋理… 非多線程渲染時,異步加載紋理的時候,可以在 Loading.UpdatePreLoading 這個函數裡看到較高的 Texture.AwakeFromLoad。但多線程渲染時,這部分的開銷就會變得很小,因為這部分開銷被放到 Render Thread 去了,如下圖中的 Gfx.UploadTexture。但需要注意的是,這個地方的異步并不是流式的加載,也就是說,當加載一個大紋理的時候,還是一次性完成的,并不會分幀去做,如下圖加載了一張2048的紋理,圖中綠色峰值是Gfx.WaitForPresent,也就是主線程在等待 Render Thread。![]()
技術分享連載(八十四) 綜上,這個功能實際上就是把某些滿足要求的紋理的加載時間從主線程移到了渲染線程。在某些情況下,确實是可以提高總體的加載速度的。但這個功能并不能真正地“解決異步加載時紋理卻隻能同步加載”的問題,隻是把卡頓放到渲染線程去了(如果耗時高了,主線程還是要等的)。![]()
技術分享連載(八十四)
https://answer.uwa4d.com/question/59f07256d4035ac353374454
Q4:在目前的Unity版本中,使用多元材質是否會對效率産生影響,用多元材質和把模型分塊哪個更好?
制作美術資源時,應該盡量避免使用多元材質。先舉例說明多元材質的一個優點是拆分模型做不到的: 一塊大石頭有石頭和草地兩個材質,做成一個整體的模型,使用多元材質,作為一個物件進行烘焙,在Lightmap上的UV分布是一個整體,不會出現拆分為兩個模型烘焙産生的接縫問題。除了上面這種情況,其他情況下推薦将模型拆分成多個模型賦予不同的材質。 優點是: 1、多個模型會作為多個MeshObject參與到裁剪、靜态批次等優化中 ; 2、拆分的模型和貼圖可以進行材質合并,程式才能進行下一步的優化,如果本身是多元材質,就無法進行合并DrawCall的優化; 第一個優點就能帶來很大的收益。制作上應該按照一個模型對應一個貼圖的做法進行,如果模型是一個整體,比如房子由底座、牆體、屋頂組成,建議将他們多選導出成一個FBX。![]()
技術分享連載(八十四) 另外,不同材質的模型建議做成多個模型,再多選導出成一個FBX,仍然是一個模型對應一個貼圖的規範進行制作。![]()
技術分享連載(八十四) ![]()
技術分享連載(八十四)
該問題來自UWA問答社群,感謝文雅提供了回答,如您對該問題仍有疑問,可以轉至社群進行進一步交流。
原文出處:侑虎科技
本文作者:admin
轉載請與作者聯系,同時請務必标明文章原始出處和原文連結及本聲明。