0x00 前言

工作的過程中，常常會發現有小夥伴對Unity的Profiler提供的記憶體資料與某些原生平臺Profiler工具，例如iOS系統和Xcode，所提供的記憶體資料有差異而感到好奇。而且大家對如何解讀原生平臺工具的資料更加感興趣，同樣例如iOS系統和Xcode。最近正好看了一個來自Unite Copenhagen題為 Developing and optimizing a procedural game | The Elder Scrolls Blades - Unite Copenhagen 的演講，其中就涉及到了一些關於iOS記憶體的話題(雖然並不是很詳細)。正好也結合工作中的一些經驗，寫一篇文章來討論一下一個Unity開發者如何處理和iOS記憶體有關的問題。主要內容包括解析iOS系統的記憶體管理，使用Instrument檢視Unity遊戲的記憶體狀況，使用命令列工具深入挖掘Unity遊戲的記憶體問題以及文末小彩蛋。  

0x01 iOS的記憶體管理 - Unity Profiler統計錯了嗎？

首先，我想強調的一點是，Profiler工具所提供的記憶體資料只是一個（組）數字，而且不同的工具存在有不同統計記憶體的策略。因此，一個重要的問題是我們看到的資料究竟是如何獲取的？   而根據所使用的工具不同，該工具用於查詢資料的策略以及開發人員實際要查詢的內容，最後的結果也有可能是不一樣的。因此，如果要尋找一個數字來彙總某個應用或者遊戲的所有記憶體資訊，那麼可能是把問題想簡單了，或者說忽略了系統的複雜性。例如，不同版本的iOS其對記憶體開銷的統計都是有區別的——在iOS12上執行的metal app的記憶體在 Xcode memory gauge的統計是高於iOS11的，這同樣是由於蘋果改變了對記憶體的統計策略，很多之前沒有被統計的記憶體如今也被計算到了記憶體開銷中。而同樣都是iOS，Xcode memory gauge的統計和Instrument中的統計也有可能不完全一致，而早期Instrument的Allocation則主要用來統計heap記憶體，只能說根據各自工具的統計規則，大家都是正確的。因此，把時間浪費在對比不同工具的資料上還不如以一個工具作為標尺來衡量記憶體開銷或者是判斷記憶體的優化是否有效。  

The accounting for purgeable, nonvolatile memory changed beginning in iOS 12 and tvOS 12. In iOS 11 and tvOS 11, allocations with this memory storage mode—commonly used by Metal apps to store buffers, textures, and state objects—weren’t counted toward an app’s memory limit and weren’t presented in tools like Xcode memory gauge.

  所以，瞭解作業系統是如何管理記憶體就變得十分重要，對於如何解讀Profiler工具提供的資料也很有幫助。接下來我們先來討論一下iOS系統對記憶體的管理機制，之後再來分別看看Xcode抓取的記憶體資料和Unity抓取的記憶體資料。   首先，每一個程序都會有一個地址空間。其範圍由指標size支援，比如32bit或64bit。並且地址空間首先會分為多個區域（regions），然後將這些區域細分為4KB（早期版本）或16KB（A7之後）為單位的page，這些page繼承了該region的各種屬性，例如是否是隻讀、可讀寫等等。當然，有些page可能存放的資料比這個page的尺寸要小，有的資料可能需要好幾page才能存放，但是系統的記憶體單位是16kb的page，所以系統統計的記憶體開銷約等於page的數量 x page的大小。   當然，系統還有真實的實體記憶體。  

Virtual memory vs Resident memory

  ref: WWDC 2013   通過虛擬記憶體使我們能夠建立從該地址空間到真實實體記憶體的對映，這點我想這些大家應該都知道。而對映其實是一個很有趣的事情。因為從每一個app程序的角度來看，它擁有所有的記憶體，即虛擬記憶體，但事實上只有一部分虛擬記憶體被對映到了真實的實體記憶體上，這部分被對映到實體記憶體的部分就是所謂的Resident memory。   就像上面這個圖中描述的一樣，一個app分配了記憶體，可以看到在虛擬記憶體上分配了4個region，其中第3個region包括了13個page。 但此時，真正對映到實體記憶體上的只有6個page。而虛擬記憶體到真實實體記憶體的對映發生在對記憶體的第一次使用時，比如從記憶體中讀取資料或是向記憶體中寫資料。Resident memory同樣也是Virtual memory，只不過這部分Virtual memory已經對映到了真實的實體記憶體。 我想大家可能都通過XCode或者Instrument的統計看到過類似的資料，例如Instrument的VM Tracker中就分別列出了Resident和Virtual Size。  

Dirty memory vs Clean memory

  page有可能是dirty的也有可能是clean的。要如何區分dirty和clean呢？簡單的說，dirty的頁就是我們的app或者遊戲對這個page的內容進行了修改即分配了記憶體同時也修改了記憶體的內容，常見的就是malloc在heap上分配的記憶體。這部分記憶體是不能被回收的，因為這些資料顯然需要被儲存在記憶體中以保證程式正常的執行。   而clean的頁則是沒有對其內容進行修改，可以被系統收回和重新建立的。例如記憶體對映檔案（Memory-mapped file），如果作業系統需要更多的記憶體，那麼就可以將其丟棄。因為系統總是可以從磁碟中重新載入它，建立記憶體空間和磁碟上檔案的對映關係。clean的記憶體是可以被釋放和重新建立的。但是可以看到，雖然Memory-mapped file並沒有消耗真實的實體記憶體，但是它消耗了程序的虛擬記憶體。   除此之外還有可執行檔案的__TEXT段以及一些framework的DATA CONST段，也會歸為clean memory。   在WWDC2018上，iOS的開發人員舉了一個很形象的例子。即分配20,000個integers組成的array，此時會有page被建立，如果只對第一個元素和最後一個元素賦值，則第一個page和最後一個page——即首尾元素所在的page——會變成dirty，但是首尾之間的page仍然是clean，即只分配了記憶體而沒有修改或寫資料。     ref: WWDC 2018  

Compressed memory

  當記憶體吃緊時，會回收clean page。而dirty page是不能被回收的，那麼如果dirty memory過多會如何呢？在iOS7之前，如果程序的dirty memory過高則系統會直接終止程序。iOS7之後，引入了Compressed Memory的機制。由於iOS沒有傳統意義上的disk swap 機制（mac OS有），因此我們在蘋果的Profiler工具中看到的Swapped Size指的其實就是Compressed Memory。   iOS7之後，作業系統可以通過記憶體壓縮器來對dirty記憶體進行壓縮。首先，針對那些有一段時間沒有被訪問的dirty pages（多個page），記憶體壓縮器會對其進行壓縮。但是，在這塊記憶體再次被訪問時，記憶體壓縮器會對它解壓以正確的訪問。舉個例子，某個Dictionary使用了3個page的記憶體，如果一段時間沒有被訪問同時記憶體吃緊，則系統會嘗試對它進行壓縮從3個page壓縮為1個page從而釋放出2個page的記憶體。但是如果之後需要對它進行訪問，則它佔用的page又會變為3個。  

Unity Profiler錯了嗎？

  可以看到，從作業系統記憶體管理的角度來看，一個程序的記憶體其實是十分複雜的。而Unity記錄的記憶體資料，以“Reserved Total - Unity”為例，則主要來自引擎內MemoryManager的記錄。MemoryManager會根據不同的情況呼叫對應的Allocator來進行引擎的記憶體分配。       例如我們可以以Unity 3D Game Kit這個免費專案為例，使用Instrument來檢視一下它的記憶體分配。       可以看到MemoryManager呼叫了UnityDefaultAllocator。 而下圖的這個分配則使用了IphoneNewLabelAllocator來分配記憶體。       也就是說Unity的程式碼分配的記憶體，Unity是會進行記錄的。但是我們可以看到除了Unity的程式碼本身分配的記憶體，還有很多framework或者第三方library也會分配記憶體。但是這部分記憶體，Unity的Profiler是不會記錄的。  

0x02 使用Instrument除錯Unity 遊戲的記憶體

  這部分我推薦Valentin Simonov的這篇文章Understanding iOS Memory (WiP)，對使用Instrument除錯記憶體介紹的十分清晰。  

0x03 使用命令列工具深入挖掘記憶體問題

  除了使用Instrument來調查記憶體問題之外，我們還可以通過很棒的Xcode memory debugger工具來查詢記憶體問題。尤其是將Memgraph匯出後，還可以藉助各種命令列工具來輔助調查以獲取更多資訊。       而且有時大家也會抱怨說在Xcode的Memory Report頁面看到的記憶體資料有時候不僅和Unity Profiler不一樣，有時甚至和Instrument等蘋果自己的效能工具數值也不一樣。上文已經說過了，不同的工具有不同的資料是正常的。但是我們同樣可以通過Memgraph和命令列工具來檢視一下，Memory Report的資料側重什麼內容。   還是以Unity 3D Kit這個工程作為演示，測試裝置為iPhone X，不過在開始之前我們首先需要開啟Scheme -> Run -> Diagnostics -> Malloc Stack選項。       運行遊戲後從主選單點選開始遊戲載入第一個場景，我們可以在Memory Report中看到此時的記憶體已經達到了1.48G。但是Memory Report中它的記憶體刻度仍然在綠色部分，所以實事求是的講Memory Report的刻度並不是一個好的優化建議，因為這個記憶體開銷在iphone7上就直接會導致遊戲被系統中止。      

Animation Leak?

  我們直接進入到Xcode memory debugger，如果想要在這裡檢查是否有記憶體leak的問題，可以點選Filter中的選項。這裡有一個常見的假“leak”情況。