在使用Unity開(kāi)發(fā)游戲的過(guò)程中，借助Profiler來(lái)分析內(nèi)存使用狀況是至關(guān)重要的。但許多開(kāi)發(fā)者可能還對(duì)Profiler中各項(xiàng)數(shù)據(jù)表示的含義不甚明確，Unity官方的技術(shù)工程師柳振東，將針對(duì)Profiler內(nèi)存分析相關(guān)的問(wèn)題及解答，與大家進(jìn)行分享。

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

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

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

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

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

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

“System.ExecutableAndDlls”該項(xiàng)顯示的是執(zhí)行文件和所調(diào)用的庫(kù)（物理、渲染、IO等系統(tǒng)庫(kù)）的總和。請(qǐng)不用擔(dān)心該選項(xiàng)的數(shù)值，因?yàn)楹芏郃pplication均在共用這些庫(kù)，并且它對(duì)于真實(shí)游戲的內(nèi)存壓力非常小，而且也不會(huì)導(dǎo)致OS因?yàn)樵搩?nèi)存來(lái)Kill掉游戲。

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

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

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

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

5. 我們?cè)贓ditor中調(diào)試項(xiàng)目的時(shí)候發(fā)現(xiàn)紋理的內(nèi)存大小是其本身大小的兩倍，是因?yàn)閁nity把內(nèi)存和顯存的大小都計(jì)算進(jìn)去了嗎？

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