背景交代
最近QC同學在跑遊戲的過程中發現玩的時間久了遊戲會發生閃退，經過蒐集信息後排除了功能性bug的
一.判斷是否是內存泄露
拿到真機，USB連接，殺掉多餘後臺進程，打開Perfdog，接下來一頓操作猛如虎，Perfdog具體操作不在贅述，有關perfdog怎麼使用的教程可以參考
Perfdog使用教程
拿到內存趨勢圖
使用手機
此圖一出，基本就可以斷定內存泄露了，這是正常玩遊戲，遊戲運行了30分鐘的內存趨勢圖；
結論：，內存持續上升，存在內存泄露。
一個優秀的遊戲通常情況內存是有上升有回落，多次運行同一個功能也不會導致內存功能持續上升；
呈現出起伏狀態，比如：
知道了存在內存泄露，下面就要開始分析有可能是哪裏導致的內存泄露；
二.分析泄露原因
一般針對unity遊戲來說，內存瓶頸是資源和Mono堆內存，兩部分；
以下是unity遊戲程序在運行時的內存分配概況
先簡單介紹下Mono，unity使用Mono機制來完成跨平臺的操作，就好像JAVA使用虛擬機來完成跨平臺操作一樣，Mono也是一種跨平臺的實現。跨平臺其實現原理在於使用了叫CIL（Common Intermediate Language通用中間語言，也叫做MSIL微軟中間語言）的一種代碼指令集，CIL可以在任何支持CLI（通用語言基礎結構）的環境中運行，就像.NET是微軟對這一標準的實現，Mono則是對CLI的又一實現。由於CIL能運行在所有支持CLI的環境中，例如剛剛提到的.NET運行時以及Mono運行時，也就是說和具體的平臺或者CPU無關。
一般對於unity開發的遊戲來說，內存的開銷都是圍繞下面的三個方面：
1.資源內存的佔用；
2.引擎模塊自身內存佔用；
3.託管堆內存佔用。
Mono通過垃圾回收機制（GarbageCollect，簡稱GC）對內存進行管理，可以自動地改變堆的大小來適應你所需要的內存，並且是可以適時地調用垃圾回收（GarbageCollection）操作來釋放已經不需要的內存。也就是說Mono會自動釋放一些內存，但要注意的是GC釋放的內存只會留給mono使用，並不會交還給操作系統，因此mono堆內存是隻增不減的。
這裏簡單介紹下Mono回收原理：
Mono會跟蹤每次內存分配的動作，並維護一個分配對象表，當GC的時候，以全局數據區和當前寄存器中的對象爲根節點，按照引用關係進行遍歷，對於遍歷到的每一個對象，將其標記爲活的（alive）。所有對象的被標記意味着該對象可以通過全局對象或者當前上下文訪問到，而沒有被標記的對象則意味着該對象無法通過任何途徑訪問到，即該對象“失聯”了，GC最終會將所有“失聯”的對象內存進行回收。
內存泄露定義
我們把對象已經不再需要使用卻沒有被GC回收的情況稱爲mono內存泄漏。Mono內存泄漏會使空閒內存減少，GC頻繁，mono堆不斷擴充，最終導致遊戲內存佔用的升高。最終導致內存過高，進程被操作系統Kill或者崩潰。簡單來說，也就是一些對象被實例化出來後沒有被釋放掉，一種保存在內存中，新的對象又需要申請新的內存空間，導致內存不斷上升。
重點關注點
配置文件的使用、紋理、網格、RenderTexture和粒子系統；
比如頻繁的創建銷燬對象是否使用對象池，或者粒子，紋理等資源顯示過後是否被及時從內存中釋放，等等；
三.測試手段
1.首先通跑測試，確定問題確定原因，比如我上面通過通跑遊戲確定存在內存泄露；
2.縮小範圍，由於一個遊戲在運行的過程中場景比較複雜，上面的同跑並不能準確定位問題，所以我們要劃分場景測試，例如我在上面的通跑遊戲過程中包括以下場景，打開關閉UI界面，戰鬥場景，切換地圖，升級武器等，如果沒有比較明顯的數據，那就要分別針對以下場景進行測試。比如UI場景可以反覆打開關閉UI界面，戰鬥場景可以持續戰鬥掛機，反覆切換地圖等等，總之是把遊戲內進行的行爲減少，細化要檢測的場景；
3.定位問題
如果某個場景發生內存泄露，邊定位到那個場景運行遊戲，而在遊戲運行時，相應的引擎也有一些工具可以查看具體的代碼使用情況，比如unity的Profiler。
如果多個場景都出現內存泄露，那就要查找這些場景所交叉的部分，比如通信框架等；而本次經過多個場景的測試發現都存在泄露，最後經過排查發現是使用的通信框架存在泄露問題。
四，Perfdog內存相關簡介
通常情況下安卓可以輕鬆獲取到的內存有4種數據，我們也可以通過ADB來獲取，
VSS - Virtual Set Size 虛擬耗用內存（包含共享庫佔用的內存）
RSS - Resident Set Size 實際使用物理內存（包含共享庫佔用的內存）
PSS - Proportional Set Size 實際使用的物理內存（比例分配共享庫佔用的內存）
USS - Unique Set Size 進程獨自佔用的物理內存（不包含共享庫佔用的內存）
一般來說內存佔用大小有如下規律：VSS >= RSS >= PSS >= USS
而Perfog的Memory也就是 Android PSS Memory，也是我們通常來用作代表內存的數據，是實際使用的物理內存大小。
Swap Memory (Swap Memory，部分設備支持Swap功能，在啓用Swap功能後，系統會對PSS內存進行壓縮，Swap增加，PSS會相應減少，由於壓縮會佔用CPU資源，同時相應會導致FPS降低)
Virtual Memory(VSS) 虛擬內存是計算機系統內存管理的一種技術。它使得應用程序認爲它擁有連續的可用的內存（一個連續完整的地址空間），而實際上它通常是被分隔成多個物理內存碎片，還有部分暫時存儲在外部磁盤存儲器上，在需要時進行數據交換。
五、Perfdog新功能初探
PerfDog 3.5版本剛剛推出，新增一個最新的數值，CPU Usage(Normalized)：規範化CPU利用率
官方給出的解釋爲：
傳統計算方法：當前時刻CPU頻率下，CPU Usage = CPU執行時間/CPU總時間。
由於移動設備CPU頻率時刻變化，用傳統CPU利用率計算方法，假定在低頻率時刻計算出CPU利用率=30%，和在CPU高頻時刻計算出CPU利用率=30%。同樣都是30%但性能消耗是完全不樣的，明顯高頻消耗更高。傳統CPU利用率已無法真實反映性能消耗。
所以我們需要一種規範化(可量化)的統計方式。將頻率因素考慮進去。
CPU Usage(Normalized)= (CPU執行時間/CPU總時間) * (當前時刻所有CPU頻率之和/所有CPU頻率最大值之和)。
PerfDog兩種統計方式都有。CPU Usage默認爲規範化CPU利用率。建議使用規範化CPU利用率作爲衡量性能指標。
具體的描述可以看這裏：規範化CPU利用率
嚐鮮體驗以下。測試使用過程和之前的一樣。來看看新增的數據對比
title：
CPU Usage趨勢圖對比：
CPU Core Usage趨勢圖對比：
從趨勢圖來看的話，實際上兩種算法並無太大差異，但是精確到具體幀的使用率，差異會比較明顯，單純從性能的角度來說，傳統CPU利用率僅能從數值的角度體現手機的CPU使用程度，但是無法從性能使用程度的角度表達手機的CPU使用效率，就像前文所說，低頻率時刻計算出CPU利用率=30%，和在CPU高頻時刻計算出CPU利用率=30%。同樣都是30%但性能消耗是完全不樣的。規範化CPU利用率數值可以彌補這一缺點。目前的測試行業良莠不齊，規範指標較少，如果真的可以做到統一行業標準不失爲一件好事。