當一個APP或遊戲各種功能越來越多時，效能優化的重要性就不言而喻了，況且現在APP或遊戲的功能逐漸趨同，提升使用者體驗已從產品設計本身轉到了APP或遊戲的流暢性上，這也讓越來越多的開發者更加關注效能優化與測試。前段時間PerfDog研發團隊曾帶來《騰訊遊戲效能實戰案例分享之幀率陡變1.0》和《APP&遊戲需要關注Jank卡頓嗎？》兩篇關於幀率與Jank的專業分析文章，本次我們就來看看在效能優化測試中會遇到的哪些名詞。
FPS
FPS是影象領域中的定義，是指畫面每秒渲染幀數，通俗來講就是指動畫或視訊的畫面數。FPS是測量用於儲存、顯示動態視訊的資訊數量，每秒鐘幀數越多，所顯示的動作就會越流暢。FPS也可以理解為我們常說的重新整理率，1秒內遊戲畫面或者應用介面真實平均重新整理次數，俗稱幀率/FPS。
1.Avg(FPS):平均幀率(一段時間內平均FPS)
2.Var(FPS):幀率方差(一段時間內FPS方差)
3.Drop(FPS):降幀次數(平均每小時相鄰兩個FPS點下降大於8幀的次數)
可以參考下面的表格，使用者打遊戲的時候延遲不應該大於100毫秒，否則使用者的體驗就會非常差。100—300毫秒使用者就可以感受到延遲，再多到了1秒的話使用者的注意力會轉移，10秒以上使用者就會拋棄這款應用。
Jank
1s內卡頓次數，類似Android的Jank卡頓和iOS的FramePacing平滑度統計原理。幀率FPS高並不能反映流暢或不卡頓。比如：FPS為50幀，前200ms渲染一幀，後800ms渲染49幀，雖然幀率50，但依然覺得非常卡頓。同時幀率FPS低，並不代表卡頓，比如無卡頓時均勻FPS為15幀。所以，平均幀率FPS與卡頓無任何直接關係。
關於Jank的詳細內容可以檢視《APP&遊戲需要關注Jank卡頓嗎？》這篇文章。
PerfDog計算方法：同時滿足兩條件，則認為是一次卡頓Jank.
1.當前幀耗時>前三幀平均耗時2倍。
2.當前幀耗時>兩幀電影幀耗時(1000ms/24*2=84ms)。
同時滿足兩條件，則認為是一次嚴重卡頓BigJank.
1.當前幀耗時>前三幀平均耗時2倍。
2.當前幀耗時>三幀電影幀耗時(1000ms/24*3=125ms)。
計算思路：考慮視覺慣性，假設以前三幀的平均幀耗時為參考，作為vsync時間間隔，連續兩次vsync沒有新渲染畫面重新整理，則認為是一次潛在卡頓，也就是說下一幀耗時大於前三幀平均幀耗時2倍，則認為一次潛在卡頓。同時單幀耗時滿足大於兩倍電影幀耗時1000ms/24*2 (由於人眼低於24幀才能辨別畫面不連續性)，則認為是一次真正卡頓。同時若單幀耗時大於3倍電影幀耗時，則認為是一次嚴重卡頓。
註解：為什麼是兩次vsync？GPU一般是3重緩衝buffer，當前幀已佔用一個buffer，即剩餘2緩衝buffer，人眼一般可容忍2幀延遲。為什麼是兩幀電影幀耗時？低於24幀畫面，人眼就能感知到畫面不連續性，電影一般都是24幀。即電影幀耗時1000ms/24=41.67ms，兩幀電影幀耗時也就是41.67ms*2，三幀電影幀耗時是41.67ms*3。
1.BigJank:1s內嚴重卡頓次數
2.Jank(/10min):平均每10分鐘卡頓次數。
3.BigJank(/10min):平均每10分鐘嚴重卡頓次數
FTime
上下幀畫面顯示時間間隔，即認為幀耗時。
1.Avg(FTime):平均幀耗時
2.Delta(FTime):增量耗時(平均每小時兩幀之間時間差>100ms的次數)
CPU Usage
Total整機/App程序，CPU使用率其實就是你執行的程式佔用的CPU資源，表示你的機器在某個時間點的執行程式的情況。使用率越高，說明你的機器在這個時間上運行了很多程式，反之較少。使用率的高低與你的CPU強弱和程式優化的好壞有直接關係。
CPU Clock
各個CPU核心的頻率和使用率
Memory
記憶體用於暫時存放CPU中的運算資料，以及與硬碟等外部儲存器交換的資料。只要移動端在執行中，CPU就會把需要運算的資料調到記憶體中進行運算，當運算完成後CPU再將結果傳送出來，記憶體佔用多少決定了移動端是否能穩定執行。Android PSS Memory實際使用的實體記憶體，統計結果和Android Java API標準結果一致，與Meminfo也一致。iOS是統計FootPrint，注：OOM與FootPrint有關，與系統、機型無關。只與RAM有關，如1G記憶體機器。FootPrint超過650MB，引發OOM。
Xcode Memory
XCode Debug Gauges統計方式即XCode Memory。
Real Memory
Xcode Instrument統計方式即Real Memory，實際佔用實體記憶體。注：實體記憶體與系統策略有關，關注意義不大
Swap Memory
Swap Memory，部分裝置支援Swap功能，在啟用Swap功能後，系統會對PSS記憶體進行壓縮，Swap增加，PSS會相應減少，由於壓縮會佔用CPU資源，同時相應會導致FPS降低
Virtual Memory
虛擬記憶體是計算機系統記憶體管理的一種技術。它使得應用程式認為它擁有連續的可用的記憶體（一個連續完整的地址空間），而實際上它通常是被分隔成多個實體記憶體碎片，還有部分暫時儲存在外部磁碟儲存器上，在需要時進行資料交換。
記憶體耗用VSS - Virtual Set Size 虛擬耗用記憶體（包含共享庫佔用的記憶體）RSS - Resident Set Size 實際使用實體記憶體（包含共享庫佔用的記憶體）PSS - Proportional Set Size 實際使用的實體記憶體（比例分配共享庫佔用的記憶體）USS - Unique Set Size 程序獨自佔用的實體記憶體（不包含共享庫佔用的記憶體）一般來說記憶體佔用大小有如下規律：VSS >= RSS >= PSS >= USS
OOMOOM，全稱“Out Of Memory”，就是記憶體溢位，一般是由於程式編寫者對記憶體使用不當，如對該釋放的記憶體資源沒有釋放，導致其一直不能被再次使用而使計算機記憶體被耗盡的現象。重啟計算機即可，但根本解決辦法還是對程式碼進行優化。
記憶體溢位可以引發很多的問題： 1.程式卡頓，響應速度慢（記憶體佔用高時JVM虛擬機器會頻繁觸發GC） 2.莫名消失（當你的程式所佔記憶體越大，它在後臺的時候就越可能被幹掉。反之記憶體佔用越小，在後臺存在的時間就越長） 3.直接崩潰（OutOfMemoryError）
ANR
在Android上，如果你的應用程式有一段時間響應不夠靈敏，系統會向用戶顯示一個對話方塊，這個對話方塊稱作應用程式無響應（Application Not Responding）對話方塊。使用者可以選擇“等待”而讓程式繼續執行，也可以選擇“強制關閉”。所以一個流暢的合理的應用程式中不能出現ANR，而讓使用者每次都要處理這個對話方塊。因此，在程式裡對響應效能的設計很重要，這樣系統不會顯示ANR給使用者。預設情況下，在android中Activity的最長執行時間是5秒，BroadcastReceiver的最長執行時間則是10秒。
Wakeups
執行緒喚醒次數。注：超過150程序很大可能會被系統kill
CSwitch
上下文切換測試。注：單核超過14000程序會被系統Kill
GPU Usage
GPU使用率，PerfDog目前支援高通晶片手機
GPU Frequency
GPU頻率，PerfDog目前支援高通晶片手機
GPU Utilization
Render/Tilter/Device
1.Render：渲染器利用率(畫素著色處理階段，若佔比高，說明是PS階段出現瓶頸，shader過於複雜或紋理大小、取樣複雜等)
2.Tilter:Tilter利用率(頂點著色處理階段，若佔比高，說明是VS階段出現瓶頸，頂點數太多等原因)
3.Device:裝置利用率(整體GPU利用率)
Network
Recv目標程序接收流量速率，Send目標程序接收、傳送流量速率。
CTemp
CPU溫度
BTemp
電池溫度
Battery Power
整機實時Current電流、Voltage電壓、Power功耗（注：PerfDog目前在Android平臺每秒獲取多次；在iOS平臺20s獲取一次，目前最精準的統計方式，結果和Battery life結果一致，支援所有iOS機型）
Energy Usage
即為Xcode Energy Impact。監控應用使用的能耗情況(包括CPU、GPU、NetWork、Location、Display (iPhone X only)、Overhead)。
注：和Xcode Energy Impact結果一致。有線模式下測試。Total Energy<270為Low，270 < Total Energy < 1000為High，Total Energy>1000為Very High。
上面對效能優化測試中會遇到的一些名詞做了簡單的總結，難免會有一些遺漏，歡迎小夥伴們前往PerfDog社群（https://bbs.perfdog.qq.com/）交流補充。
PerfDog作為最新的移動全平臺效能測試分析工具已經支援上述提到的絕大多數效能引數的測試，例如手機測評者最關心的遊戲PFS、GPU使用率、CPU溫度、電池功耗等和開發工程師與測試工程師最關心的CPU使用率、記憶體佔用，網路流量速度等。如果您也對效能優化測試感興趣，不妨前往PerfDog官網下載試用。後續PerfDog研發團隊還會針對不同的效能引數繼續為大家帶來高品質的深度技術解析內容，敬請期待。