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与卡顿无任何直接关系。
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
OOM
OOM，全称“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官网下载试用。
