如何理解Unity Profiler內(nèi)存分析問題

本篇文章為大家展示了如何理解Unity Profiler內(nèi)存分析問題，內(nèi)容簡明扼要并且容易理解，絕對能使你眼前一亮，通過這篇文章的詳細介紹希望你能有所收獲。

在使用Unity開發(fā)游戲的過程中，借助Profiler來分析內(nèi)存使用狀況是至關(guān)重要的。但許多開發(fā)者可能還對Profiler中各項數(shù)據(jù)表示的含義不甚明確，小編將針對Profiler內(nèi)存分析相關(guān)的問題及解答，與大家進行分享。

要想完全發(fā)揮Profiler內(nèi)存分析的威力，首先要做的就是了解Profiler展示的數(shù)據(jù)所表達的含義，以及到底哪些模塊所使用的內(nèi)存才會被統(tǒng)計到Unity的Profiler中。Profiler涉及到的知識點還有很多，我們今天先從中挑選一些大家常有的疑問來作解答。

1.    在Unity的Profiler中看到的總內(nèi)存使用和我使用其它工具看到的系統(tǒng)內(nèi)存占用不太一樣，這是為什么呢？

Profiler中看到的內(nèi)存是通過Unity自身引擎看到的內(nèi)存分配，凡是引擎Allocation和Deallocation的內(nèi)存，引擎均有記錄，所以我們可以給出確切的引擎內(nèi)存占用信息。但是，仍有其他內(nèi)存我們是無法獲知的。

比如，如果引擎使用了第三方庫，那么庫分配的內(nèi)存我們是無法進行統(tǒng)計的。另外，在移動設(shè)備上大家看到的內(nèi)存，其實都要比Profiler大很多，這是因為不管是通過Xcode的Instrument還是通過Android的USS，其記錄的真實物理內(nèi)存都包括兩部分，一個是真實Used的物理內(nèi)存，另一個則是緩存的（Cached）的物理內(nèi)存。這是OS所決定的，Android和iOS系統(tǒng)在資源不使用時均不會立即將其進行回收，而是將其放在緩存的物理內(nèi)存中，以便下次再用時，可以快速地加載。當系統(tǒng)發(fā)現(xiàn)App的內(nèi)存不夠用時，才會在底層調(diào)用一個memory killer線程來輪詢緩存物理內(nèi)存，進而為app來清理內(nèi)存。而Unity Profiler記錄的則是目前真實使用的物理內(nèi)存，即上述所說的第一部分。因此，當游戲運行時間越長，Profiler分配內(nèi)存和通過其他軟件獲得的系統(tǒng)內(nèi)存差距會越大。

因此，只要所使用的第三方庫不存在內(nèi)存泄露問題，我們一般都建議只需要查看Profiler即可，只要Profile中的內(nèi)存可以保證正常升高和回落，那么引擎這邊分配的內(nèi)存就是沒有問題的。

2.    我們做項目的時候發(fā)現(xiàn)有時profiler中System.ExecutableAndDlls這項占用很多，有什么解決辦法嗎？

“System.ExecutableAndDlls”該項顯示的是執(zhí)行文件和所調(diào)用的庫（物理、渲染、IO等系統(tǒng)庫）的總和。請不用擔心該選項的數(shù)值，因為很多Application均在共用這些庫，并且它對于真實游戲的內(nèi)存壓力非常小，而且也不會導致OS因為該內(nèi)存來Kill掉游戲。

3.    為什么在Profiler中的Simple模式下，Used Total的數(shù)值不等于其右邊各項Unity,Mono,GfxDriver,FMOD與Profiler總和呢？

其實在Unity中，Used Total的計算公式為Used Total = Unity + Mono + GfxDriver + Profiler + additionalUsedMemory。公式中的additionalUsedMemory項在profiler中并沒有顯示，因為這一項一般情況下都為0，只在某些特殊發(fā)布平臺下才會有數(shù)值（一般Android，PC和IOS都為0）。因此一般情況下Used Total的值就是除FMOD之外各項的總和了。當然，這個規(guī)則對于Reserved Total是同樣適用的。

4.    我們項目的資源主要使用AssetBundle動態(tài)加載資源，發(fā)現(xiàn)Profiler中Detailed模式下PersistentManager.Remapper一項占用時多時少，這一項主要是做什么的呢？

Remapper主要提供文件的持久化存儲，包括各種序列化的asset，項目的setting文件等，維護文件系統(tǒng)的中的文件與內(nèi)存中數(shù)據(jù)的對應(yīng)關(guān)系。那么如果項目大量使用AssetBundle的話，在對AssetBundle進行Unload之前都會需要占用Remapper的內(nèi)存的。而Remapper本身的實現(xiàn)使用內(nèi)存池，其數(shù)值只會增大，那么為了使Remapper占用的內(nèi)存保持在一個穩(wěn)定的數(shù)值上，我們需要每次在加載一定數(shù)量的AssetBundle之后進行Unload操作，而不要一次性把所有AssetBundle都加載后才調(diào)用Unload。（這樣的操作對維持整個mono heap的大小也是至關(guān)重要的，因為mono heap本身也是只增大不減小的）

5.     我們在Editor中調(diào)試項目的時候發(fā)現(xiàn)紋理的內(nèi)存大小是其本身大小的兩倍，是因為Unity把內(nèi)存和顯存的大小都計算進去了嗎？

其實并不是這個原因，因為Editor本身會保有紋理的一份內(nèi)存，在Editor下進行profiler會把Editor本身所使用的紋理大小也計算進去，因此會有內(nèi)存變?yōu)閮杀兜那闆r。我們官方并不建議在Editor下對項目進行性能調(diào)試，而是務(wù)必要在真機上跑編譯好的項目，然后連接profiler進行調(diào)試，只有這樣才能得到真正精確的測試數(shù)據(jù)。

上述內(nèi)容就是如何理解Unity Profiler內(nèi)存分析問題，你們學到知識或技能了嗎？如果還想學到更多技能或者豐富自己的知識儲備，歡迎關(guān)注億速云行業(yè)資訊頻道。