本文件主要是對Unity官方教程的個人理解與總結（其實以翻譯記錄為主：>）
僅作為個人學習使用，不得作為商業用途，歡迎轉載，並請註明出處。
文章中涉及到的操作都是基於 Unity2017.3版本
參考連結： https://docs.unity3d.com/Manual/MobileProfiling.html

Profiling

First steps
（未完待續）

Memory

記憶體

There are two types of memory, Mono memory and Unity memory.
有兩種型別的記憶體：Mono 記憶體和Unity記憶體。

Mono memory

Mono 記憶體

Mono memory handles script objects, wrappers for Unity objects (game objects, assets, components, etc). Garbage Collector cleans up when the allocation does not fit in the available memory or on a System.GC.Collect() call.
Mono記憶體處理指令碼物件，作為Unity物件的封裝（遊戲的物件、資產、元件等）。當可用記憶體分配不適合或 System.GC.Collect() 呼叫時，垃圾收集器就會清理。

Memory is allocated in heap blocks. More can allocated if it cannot fit the data into the allocated block. Heap blocks will be kept in Mono until the app is closed. In other words, Mono does not release any memory used to the OS (Unity 3.x). Once you allocate a certain amount of memory, it is reserved for mono and not available for the OS. Even when you release it, it will become available internally for Mono only and not for the OS. The heap memory value in the Profiler will only increase, never decrease.
記憶體是在堆塊中分配的。如果無法將資料放入已分配的塊中，則可以申請分配更多塊。堆塊將保持在Mono中，直到應用程式關閉。換句話說，Mono並沒有釋放任何記憶體到作業系統中（Unity 3.x）。一旦你分配了一定數量的記憶體，它就會被保留為mono，而不可用於作業系統再分配。即使你釋放了它，它也只會在內部為Mono所用而不為作業系統所提供。Profiler中的堆記憶體值只會增加，不會減少。

If the system cannot fit new data into the allocated heap block, the Mono calls a “GC” and can allocate a new heap block (for example, due to fragmentation).
“Too many heap sections” means you’ve run out of Mono memory (because of fragmentation or heavy usage).
Use System.GC.GetTotalMemory to get the total used Mono memory.
The general advice is, use as small an allocation as possible.
如果系統不能將新資料放入已分配的堆塊中，Mono呼叫一個“GC”，並且可以分配一個新的堆塊（例如，由於儲存碎片）。
“太多的堆”意味著您已經耗盡了Mono記憶體（因為儲存碎片或大量使用）。
使用 System.GC.GetTotalMemory 獲得總已使用的Mono記憶體。
一般的建議是，儘可能少地使用分配。

Unity memory

Unity記憶體

Unity memory handles Asset data (Textures, Meshes, Audio, Animation, etc), Game objects, Engine internals (Rendering, Particles, Physics, etc). Use Profiler.usedHeapSize to get the total used Unity memory.
Unity記憶體處理資產資料（紋理、網格、音訊、動畫等）、遊戲物件、引擎內部（渲染、粒子、物理等）。使用 Profiler.usedHeapSize 來獲得總已使用的Unity記憶體。

Memory map

記憶體對映

No tools yet but you can use the following.

• Unity Profiler - not perfect, skips stuff, but you can get an overview. It works on the device!
• Internal profiler. Shows Used heap and allocated heap - see mono memory. Shows the number of mono allocations per frame.
• Xcode tools - iOS
• Xcode Instruments Activity Monitor - Real Memory column.
• Xcode Instruments Allocations - net allocations for created and living objects.
• VM Tracker (textures usually get allocated with IOKit label and meshes usually go into VM Allocate).

目前還沒有工具，但是您可以使用以下內容。

• Unity Profiler ——不是完美的，跳過了一些東西，但是你可以得到一個概述。它在裝置上可執行！
• 內部 profiler。顯示已使用堆和分配的堆——請參閱mono記憶體。顯示每幀的mono分配的數量。
• iOS Xcode工具
• Xcode Instruments Activity Monitor-真實記憶體列。
• Xcode Instruments Allocations-為建立的和存在的物件的淨分配。
• VM Tracker （紋理通常是用IOKit 標籤分配的，而網格通常會由VM分配）。

You can also make your own tool using Unity API calls:
你也可以使用Unity API建立自己的工具：

• FindObjectsOfTypeAll (type : Type) : Object[]
• FindObjectsOfType (type : Type): Object[]
• GetRuntimeMemorySize (o : Object) : int
• GetMonoHeapSize
• GetMonoUsedSize
• Profiler.BeginSample/EndSample - profile your own code
• UnloadUnusedAssets () : AsyncOperation
• System.GC.GetTotalMemory/Profiler.usedHeapSize

References to the loaded objects - There is no way to figure this out. A workaround is to “Find references in scene” for public variables.
對載入的物件的引用——沒有辦法解決這個問題。一個解決方案是為公共變數“查詢場景中的引用”。

Garbage collector

垃圾回收

• This fires when the system cannot fit new data into the allocated heap block.
• Don’t use OnGUI() on mobiles: it shoots several times per frame, completely redraws the view and creates tons of memory allocation calls that require Garbage Collection to be invoked.
• 當系統不能將新資料放入已分配的堆塊時，就會觸發這種情況。
• 不要在手機上使用OnGUI()：它每幀觸發幾次，完全重新繪製檢視，並建立大量的記憶體分配呼叫，需要呼叫垃圾收集。

Creating/removing too many objects too quickly?

過快地建立/移除太多物件

• This may lead to fragmentation.

• Use the Editor profiler to track the memory activity.

• The internal profiler can be used to track the mono memory activity.

• System.GC.Collect() You can use this .Net function when it’s ok to have a hiccup.

• 這可能導致儲存碎片。

• 使用Editor profiler來跟蹤記憶體活動。

• 內部profiler 可以用來跟蹤mono記憶體活動。

• System.GC.Collect() 當它可以卡頓的時候，你可以使用這個.Net函式。

Allocation hiccups

分配問題

• Use lists of preallocated, reusable class instances to implement your own memory management scheme.
• Don’t make huge allocations per frame, cache, preallocate instead
• Problems with fragmentation?
• 使用預先分配的、可重用的類例項的列表來實現您自己的記憶體管理方案。
• 不要在單幀進行大量的分配，快取和預分配可替代
• 儲存碎片的問題？

Preallocating a memory pool.

預分配記憶體池

Keep a List of inactive GameObjects and reuse them instead of Instantiating and Destroying them.
保留一個未啟用的遊戲物件的列表，並重新使用它們，而不是例項化和銷燬它們。

Out of mono memory

mono 記憶體溢位

• Profile memory activity - when does the first memory page fill up?
• Do you really need so many gameobjects that a single memory page is not enough?
• Use structs instead of classes for local data. Classes are stored on the heap; structs on the stack.
• Read the Understanding Automatic Memory Management page.
• Profile 記憶體活動——第一個記憶體頁何時填滿？
• 你真的需要這麼多的遊戲物件，一個記憶體頁是不夠的嗎？
• 本地資料使用structs 而不是classes。類儲存在堆中;結構體在棧上。

Out of memory crashes

記憶體溢位崩潰

At some points a game may crash with “out of memory” though it in theory it should fit in fine. When this happens compare your normal game memory footprint and the allocated memory size when the crash happens. If the numbers are not similar, then there is a memory spike. This might be due to:
在某些時候，遊戲可能會隨著“記憶體不足”而崩潰，儘管理論上它應該可以很好地適應。當發生這種情況時，對比發生崩潰時和正常遊戲記憶體佔用和分配的記憶體大小會發生比較。如果資料不相似，那麼就會有一個記憶體峰值。這可能是由於：

• Two big scenes being loaded at the same time - use an empty scene
  between two bigger ones to fix this.
• Additive scene loading - remove unused parts to maintain the memory
  size.
• Huge asset bundles loaded to the memory
• Textures without proper compression (a no go for mobiles).
• Textures having Get/Set pixels enabled. This requires an uncompressed copy of the texture in memory.
• Textures loaded from JPEG/PNGs at runtime are essentially uncompressed.
• Big mp3 files marked as decompress on loading.
• Keeping unused assets in weird caches like static monobehavior fields, which are not cleared when changing scenes.
  -兩個大場景同時被載入 - 使用一個空的場景放在兩個大場景中間過渡來解決這個問題。
  -疊加場景載入-刪除未使用的部件以維護記憶體大小。
• 巨大的asset bundles載入到記憶體中
• 紋理沒有適當的壓縮（不適合移動端）。
• 具有Get/Set畫素的紋理。這需要在記憶體中有一個未壓縮的紋理副本。
• 在執行時從jpeg/pngs載入的紋理本質上是未壓縮的。
• 大的mp3檔案被標記為在載入時解壓縮。
• 將未使用的資產儲存在諸如靜態monobehavior 欄位之類的奇怪快取中，這些欄位在更改場景時不會被清除。