#每天一個小目標#Unity技術分享(一)
【技術分享】是UWA推出的技術交流欄目,我們會定期將開發團隊中反饋的常見問題加以總結並梳理在此,以供大家參考。UWAQQ群:465082844
精選5個性能優化問題,建議閱讀時間10分鐘,認真讀完必有收穫。如果您有任何獨到的見解或者發現也歡迎聯繫我們,一起探討。
Q1:Texture佔用內存總是雙倍,這個是我們自己的問題,還是Unity引擎的機制?
出現這種情況的原因有兩種:一種是你在真機運行時開啟了Read&Write。另一種可能是Unity的Bug,目前的Unity 5.2.3 release note如下 :
(735644) - OpenGL: Fixed texture memory usage reporting in profiler, was twice the actual size for most textures.開發者需要關注下自己的開發版本,5.2.3以前類似情況的項目可以參考一下。
Q2:我現在發現兩個因素直接影響Overhead,一個是Shader的複雜度,一個是空Update方法及其同類空方法,不知道是否還有其他因素?
Overhead的計算方法是:Profiler當前幀統計的總耗時時間減去所有已知選項的累加時間,即引擎當前還無法識別模塊的耗時時間。Overhead數值理論上是趨向於0的,但是由於目前市面上的硬體設備、系統框架過於豐富,所以引擎可能無法識別所有模塊的CPU開銷。
就我們目前遇到的大部分案例而言,Overhead數值較高一般是由硬體設備的垂直同步演算法無法識別而引起的。所以,一般情況下,Overhead的數值其實並不需要開發者特別關注。在UWA的性能分析中,我們並沒有將Overhead計算在內,一方面是其本身數據的統計意義對目前大多數項目的性能優化幫助不大,另一方面是即便知道了它的CPU數值,也無法知道到底是哪些地方引起的,上層很難有針對性地進行優化。當然,我們會持續對Overhead進行實驗和研究,分析其CPU耗時規律、與已知選項的關聯性等。後續有任何相關發現,我們都會總結成文,及時分享給大家。
Q3:在Unity的內存管理機制中, Reserved Total 和 Used Total之間的關係是怎樣的?
Reserved Total 和 Used Total為Unity引擎在內存方面的總體分配量和總體使用量。 一般來說,引擎在分配內存時並不是向操作系統 「即拿即用」,而是首先獲取一定量的連續內存,然後供自己內部使用,待空餘內存不夠時,引擎才會向系統再次申請一定量的連續內存進行使用。所以,從圖表中可以看到,Reserved Total 的內存佔用量略大於 Used Total, 且兩者走勢基本一致。
注意:對於絕大多數平台而言,Reseved Total內存 = Reserved Unity內存 + GFX內存 + FMOD內存 + Mono內存。(關於Unity的內存管理機制,我們在這裡寫過一篇比較詳細的分析)
Q4:紋理Atlas是建議合成一張2048(尺寸)的紋理還是四張1024的紋理?
在其他設置一致的情況下,這兩種方式無論在載入還是渲染方面其實並沒有實質上的差別。在我們接觸到的大多數案例中,紋理資源方面的問題除了尺寸外,紋理格式、Mipmap設置和Read&Write功能同樣是需要研發團隊時刻關注的。
Q5:在把Unity升級到5.3之後,項目中緩存的粒子特效無法正常播放了(只能播放一次),是否還需要修改粒子的設置呢?
這個問題是Unity的Bug,5.4.0B3 release note 為:
Particles: Fixed particle system only playing once.(會在新版本5.4修復)n
目前我們推薦通過另一種方法可以暫時繞過該 Bug:
particleSystem.Stop(); nparticleSystem.Clear(); nparticleSystem.Simulate(0.02f); nparticleSystem.Play();n
推薦閱讀:
※Linux下做性能分析6:理解一些基礎的CPU執行模型
※如何做Go的性能優化?
※我們用50次遊戲性能的深度優化,總結出了五條「毒雞湯」
※【求知探新】《為誰而煉金》UI界面載入性能分析
※多個提高Node.js應用吞吐量的小優化技巧介紹