PerfDog（性能狗）是移動全平台Android/iOS性能測試和分析工具平台（web可視化數據管理，需登錄）。快速定位分析性能問題，提升App應用及游戲的性能和品質。
手機無需root或越獄，App應用及游戲也無需做任何修改，極簡化即插即用。本文的內容主要來自於：PerfDog使用說明書
在win10上profile android應用
在macOS Big Sur（11.2.3）上profile ios應用
Win7上安裝iTools4來profile ios應用
FTime（幀耗時）：上下幀畫面顯示時間間隔
1) Avg(FTime)：平均幀耗時
2) Delta(FTime)：增量耗時(平均每小時兩幀之間時間差>100ms的次數)
FPS（幀率）：1秒內游戲畫面或者應用界面真實平均刷新次數
1) Avg(FPS)：平均幀率(一段時間內平均FPS)
2) Var(FPS)：幀率方差(一段時間內FPS方差)
注：一段時間內，30幀占比80%，31幀占比11%，29幀占比6%，32幀占比3%
Avg(FPS)為這段時間的平均FPS，即這段時間FPS的數學期望E(X) = 30*0.8 + 31*0.11 + 29*0.06 + 32*0.03 = 30.11
Var(FPS)為這段時間的FPS方差。方差D(X)反映X與E(X)的偏離程度的大小。方差越小，X越集中在E(X)附近
D(X) = E(X平方) - E(X)*E(X) = 30*30*0.8 + 31*31*0.11 + 29*29*0.06 + 32*32*0.03 - 30.11*30.11 = 0.2779
3) Drop(FPS)：降幀次數(平均每小時相鄰兩個FPS點下降大於8幀的次數)
Jank：1s內卡頓次數。
BigJank：1s內嚴重卡頓次數
幀率FPS高並不能反映流暢或不卡頓。比如：FPS為50幀，前200ms渲染一幀，后800ms渲染49幀，雖然幀率50，但依然覺得非常卡頓。
同時幀率FPS低，並不代表卡頓，比如無卡頓時均勻FPS為15幀。
因此，平均幀率FPS與卡頓無任何直接關系，需要用Jank來衡量游戲的卡頓情況。
PerfDog Jank計算方法：
同時滿足以下兩條件，則認為是一次卡頓Jank.
(a) 當前幀耗時>前三幀平均耗時2倍。
(b) 當前幀耗時>兩幀電影幀耗時(1000ms/24*2=84ms)。
同時滿足兩條件，則認為是一次嚴重卡頓BigJank.
(a) 當前幀耗時>前三幀平均耗時2倍。
(b) 當前幀耗時>三幀電影幀耗時(1000ms/24*3=125ms)。
Stutter：測試過程中，卡頓時長的占比
tapm的一些性能指標
FPS卡頓：當相鄰兩秒的幀時間差大於100ms
FPS抖動：當相鄰兩秒的FPS差值大於8
FPS低幀：FPS低於5幀
CPU Usage：傳統CPU利用率，也叫未規范化CPU利用率。為CPU執行時間/CPU總時間。
一般Android Studuio、adb、Xcode等獲取的CPU利用率都是未規范化CPU利用率。
注：iOS下，該值與Xcode使用率/核心數一致
CPU Usage(Normalized)：規范化CPU利用率。考慮CPU頻率變化。為 (CPU執行時間/CPU總時間) * (當前時刻所有CPU頻率之和/所有CPU頻率最大值之和)
注1：由於移動設備CPU頻率時刻變化，用傳統CPU利用率計算方法，假定在低頻率時刻計算出CPU利用率=30%，和在CPU高頻時刻計算出CPU利用率=30%。
同樣都是30%但性能消耗是完全不樣的，明顯高頻消耗更高。傳統CPU利用率已無法真實反映性能消耗。
注2：Android下要用規范化CPU利用率作為衡量性能指標；iOS平台，頻率變化一般是在電池電量極低，鎖屏等極端情況下才出現，所以規范化CPU利用率沒有很大意義。
1) TotalCPU：表示整機CPU使用率
2) AppCPU：進程CPU使用率 注：建議低於60%，高於90%說明有嚴重的CPU性能問題
擴展閱讀：你真了解CPU利用率？
Memory(物理內存)
(a) Andorid下為PSS。注：與dumpsys meminfo的Pss TOTAL數值一樣。
(b) iOS下為FootPrint（或叫resident_size）。OOM與FootPrint有關，與系統、機型無關。只與RAM有關，如1G內存機器。FootPrint超過650MB，引發OOM；2G內存機器，FootPrint超過1300MB，引發OOM。
Xcode Memory (XCode Debug gauges統計方式）即FootPrint
Virtual Memory(VSS)：虛擬內存。64位app該值都超大。
Available Memory：整機可用剩余物理內存。
Network(Recv/Send)：測試目標進程流量
注1：Android下，USB/WiFi測試模式下均為APP數據
注2：iOS下，USB測試模式下是app的，WiFi測試模式下可能是整機可能是app。結果與Xcode統計一致。
溫度
注1：Android下，CTemp(CPU溫度)
注2：iOS下，BTemp(電池溫度)
Battery Power(僅WIFI模式，Current電流、Voltage電壓、Power功耗)
注1：Sum(Battery)是耗電量。
注2：Android下，對於已經兼容的雙電機型，可參考：https://bbs.perfdog.qq.com/detail-340.html，未兼容設備可以電流x2進行容錯。
注3：iOS下，20s獲取一次，目前最精准的統計方式，結果和Battery life結果一致，支持所有iOS機型）
ScreenShot(截圖)：只支持USB模式，注：部分機型截圖影響性能
Android特有
InterFrame：部分機型具有動態補幀/插幀技術，此參數可真實反映1秒內插入的幀數
CPU Clock：各個CPU核心的未規范化頻率和未規范化使用率
Swap Memory：在啟用Swap功能后，系統會對PSS內存進行壓縮，Swap增加，PSS會相應減少，由於壓縮會占用CPU資源，同時相應會導致FPS降低
對應adb shell cat /proc/<pid>/status中的VmSwap
NativePss：對應dumpsys meminfo的Native Heap
Gfx：對應dumpsys meminfo的Gfx dev
GL：對應dumpsys meminfo的GL mtrack
JavaHeap：對應dumpsys meminfo的Java Heap
Unknown：對應dumpsys meminfo的Unknown
GPU Usage(目前僅支持部分手機)。注：Top Android GPU測試機型，請參考：https://bbs.perfdog.qq.com/detail-195.html
GPU Frequency(目前僅支持部分手機)。
Mali GPU Utilization(僅支持Mali芯片GPU）注：支持的GPU列表，請參考：https://bbs.perfdog.qq.com/detail-332.html
1) Non-fragment：非片段着色器(頂點着色器，細分着色器，計算着色器)耗費的GPU時間占渲染耗費的GPU時間的比例。
2) Fragment：片段着色器耗費的GPU時間占渲染耗費的GPU時間的比例。
Mali Memory & Bus Bandwidth(僅支持Mali芯片GPU）
1) L2Load/Store：Load/Store單元讀取L2內存的實際帶寬 (包括頂點緩存，原子，圖像數據)。
2) L2Texture：Texture單元讀取L2內存的實際帶寬 (紋理采樣)。
3) Bus Read：定義GPU到DRAM或者GPU外部的系統內存的實際讀帶寬。
4) Bus Write：定義GPU到DRAM或者GPU外部的系統內存的實際寫帶寬。
Mali Pixels Info(僅支持Mali芯片GPU）
1) OverDraw：表示每個像素由多少個片段分層組成，通常用於表示像素被重復繪制的次數。
2) PixelsThroughput：表示每個被渲染的像素耗費的GPU的時鍾的數量。
注：更多GPU信息說明，請參考：https://bbs.perfdog.qq.com/article-detail.html?id=72
iOS特有
Real Memory：Xcode Instrument統計方式，實際占用物理內存。
與物理內存系統策略有關，衡量內存指標時不會關注，但是它有助於分析定位整體性能問題。
比如：物理內存充足時，Real Memory會大於FootPrint。原因是因為系統會多分配一些物理內存做緩沖，提升內存分配效率。
比如：FootPrint沒有降低，說明應用沒有釋放內存，但是Real Memory卻降低了，說明系統對內存做了壓縮。由於壓縮會占用CPU資源，同時相應會導致FPS降低
Wakeups(線程喚醒次數)：超過150進程很大可能會被系統kill。a sleep/wake cycle on each thread per second，Exceeding limit of 150 wakeups per second over 300 seconds，特別是iOS13.2悶殺后台進程事件，建議重點關注
CSwitch(上下文切換測試)：單核超過14000進程會被系統Kill。Context Switch Limit 14000(Core/Second)
GPU Utilization
1) Render(渲染器利用率)：像素着色處理階段，若占比高，說明是PS階段出現瓶頸，shader過於復雜或紋理大小、采樣復雜等
2) Tiler(Tiler利用率)：頂點着色處理階段，若占比高，說明是VS階段出現瓶頸，頂點數太多等原因
3) Device(設備利用率)：整體GPU利用率
Energy Usage(即為Xcode Energy Impact。監控應用使用的能耗情況(包括CPU、GPU、NetWork、Location、Display (iPhone X only)、Overhead)。
注：和Xcode Energy Impact結果一致。有線模式下測試，支持iOS9及以上系統。Total Energy<=270為Low，270<Total Energy<=1000為High，Total Energy>1000為Very High。
參考：https://help.apple.com/xcode/mac/11.0/index.html?localePath=en.lproj#/devf7f7c5fcd