# 参数说明
软件数据采集说明
Perfeye支持移动平台和Windows平台的所有应用程序(游戏、APP应用、浏览器等),桌面应用程序Perfeye支持在Windows机器使用运行。
# Windows平台
Screenshot
(主屏幕截图)
FPS
(1秒内游戏画面或者应用界面真实平均刷新次数,俗称帧率/FPS)
- Avg(FPS):平均帧率(一段时间内平均FPS)
- Var(FPS):帧率方差(一段时间内FPS方差)
- Drop(FPS):降帧次数(平均每小时相邻两个FPS点下降大于8帧的次数)
Jank
(1s内卡顿次数。iOS9.1以下系统暂时不支持。类似Android的Jank卡顿和iOS的FramePacing平滑度统计原理。帧率FPS高并不能反映流畅或不卡顿。比如:FPS为50帧,前200ms渲染一帧,后800ms渲染49帧,虽然帧率50,但依然觉得非常卡顿。同时帧率FPS低,并不代表卡顿,比如无卡顿时均匀FPS为15帧。所以,平均帧率FPS与卡顿无任何直接关系)
计算方法:同时满足两条件,则认为是一次卡顿Jank.
- 当前帧耗时>前三帧平均耗时2倍。
- 当前帧耗时>两帧电影帧耗时(1000ms/24*2=84ms)。
同时满足两条件,则认为是一次严重卡顿BigJank.
- 当前帧耗时>前三帧平均耗时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.67ms2,三帧电影帧耗时是41.67ms3。
- BigJank:1s内严重卡顿次数
- Jank(/10min):平均每10分钟卡顿次数。
- BigJank(/10min):平均每10分钟严重卡顿次数
FTime
(上下帧画面显示时间间隔,即认为帧耗时,iOS9.1以下系统暂时不支持)
- Avg(FTime):平均帧耗时
- Delta(FTime):增量耗时(平均每小时两帧之间时间差>100ms的次数)
DrawCall 每一帧画面绘制所调用函数
ID3D11DeviceContext:: (opens new window),
ID3D11DeviceContext::Draw (opens new window),
ID3D11DeviceContext::DrawInstanced (opens new window),
ID3D11DeviceContext::DrawIndexedInstanced (opens new window),
ID3D11DeviceContext::DrawInstancedIndirect (opens new window),
ID3D11DeviceContext::DrawIndexedInstancedIndirect (opens new window)
方法的次数。Vertice
每一帧所有经过处理的顶点数量总和
Primitive
每一帧所有经过处理的图片( 三角形,点,线) 的数量总和
Dispatch
调用 ID3D11DeviceContext::Dispatch, ID3D11DeviceContext::DispatchIndirect的次数 (dispatch) 次数
CPU Usage
(Total整机/App目标进程,统计结果和任务管理器一致)
CPU Core Usage
(系统每个CPU核心的使用率)
Memory
(进程的Private Bytes,统计结果和VMMap Private Bytes结果一致,与任务管理器-详细信息-提交内存也一致。)
Working Set(进程的工作集内存,统计结果和VMMap Working Set结果一致,与任务管理器-详细信息-工作集(内存)也一致)
Swap Memory
(系统的Swap Memory)
GPU Usage
(GPU使用率,统计结果和GPU-Z结果一致)
GPU Memory Used
(GPU显存,统计结果和GPU-Z结果一致)
Network
(Recv/Send,测试目标进程流量)
IO
- appRead/appWrite(测试目标进程的IO读写量)
- sysRead/sysWrite(整个系统的磁盘的IO读写量)
DRAM Bandwidth
- DRAMBandwidthRead (从主内存控制器中读取的内存带宽字节数(GB/s))
- DRAMBandwidthWrite (向主内存控制器中写入的内存带宽字节数(GB/s))
- DRAMBandwidthIO (由于对内存控制器的IO请求而读/写的字节数(单位GB))
- DRAMBandwidthIA (由于对内存控制器的IA请求而读/写的字节数(单位GB))
- DRAMBandwidthGT (由于对内存控制器的GT请求而读/写的字节数(单位GB))
CPU Core IPC
- CPUCoreExecUsage (平均每个额定CPU周期内执行的指令个数
[分核心]
) - CPUCoreIPC (平均每个CPU周期内执行的指令个数
[分核心]
)
- CPUCoreExecUsage (平均每个额定CPU周期内执行的指令个数
CPU Core Freq
- CPUCoreFreq (相对频率(单位%)(分核心)大于1表示Intel Turbo Boost)
- CPUCoreActiveFreq (主动相对频率(单位%)(分核心)大于1表示Intel Turbo Boost)
CPU Core L3 Cache Miss
- L3CacheMisses (L3缓存(读) cache misses的字节数
[分核心]
) - L3CacheHitRatio (L3缓存(读) cache命中率(单位:%)
[分核心]
) - L3CacheMissesPerInstruction (平均每条指令发生L3缓存(读) cache misses的次数
[分核心]
)
- L3CacheMisses (L3缓存(读) cache misses的字节数
CPU Core L2 Cache Miss
- L2CacheMisses (L2缓存(读) cache misses的字节数
[分核心]
) - L2CacheHitRatio (L2缓存(读) cache命中率(单位:%)
[分核心]
) - L2CacheMissesPerInstruction (平均每条指令发生L2缓存(读) cache misses的次数
[分核心]
)
- L2CacheMisses (L2缓存(读) cache misses的字节数
CPU Core Temp
- CPUCoreTemp (距离CPU TjMax(核心最高温度)的相对温度(单位:摄氏度),0表示已经达到CPU TjMax(核心最高温度)
[分核心]
)
- CPUCoreTemp (距离CPU TjMax(核心最高温度)的相对温度(单位:摄氏度),0表示已经达到CPU TjMax(核心最高温度)
CPU Energy
- CPUEnergy (CPU能耗(单位:焦耳))
# iOS 平台 (与苹果官方 Xcode 工具参数对齐一致)
Screenshot
FPS
(1秒内游戏画面或者应用界面真实平均刷新次数,俗称帧率/FPS)
- Avg(FPS):平均帧率(一段时间内平均FPS)
- Var(FPS):帧率方差(一段时间内FPS方差)
- Drop(FPS):降帧次数(平均每小时相邻两个FPS点下降大于8帧的次数)
Jank
(1s内卡顿次数。iOS9.1以下系统暂时不支持。类似Android的Jank卡顿和iOS的FramePacing平滑度统计原理。帧率FPS高并不能反映流畅或不卡顿。比如:FPS为50帧,前200ms渲染一帧,后800ms渲染49帧,虽然帧率50,但依然觉得非常卡顿。同时帧率FPS低,并不代表卡顿,比如无卡顿时均匀FPS为15帧。所以,平均帧率FPS与卡顿无任何直接关系)
计算方法:同时满足两条件,则认为是一次卡顿Jank.
- 当前帧耗时>前三帧平均耗时2倍。
- 当前帧耗时>两帧电影帧耗时(1000ms/24*2=84ms)。
同时满足两条件,则认为是一次严重卡顿BigJank.
- 当前帧耗时>前三帧平均耗时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.67ms2,三帧电影帧耗时是41.67ms3。
- BigJank:1s内严重卡顿次数
- Jank(/10min):平均每10分钟卡顿次数。
- BigJank(/10min):平均每10分钟严重卡顿次数
FTime
(上下帧画面显示时间间隔,即认为帧耗时,iOS9.1以下系统暂时不支持。)
- Avg(FTime):平均帧耗时
- Delta(FTime):增量耗时(平均每小时两帧之间时间差>100ms的次数)
smoothness的定义:
24 fps 是人眼「似动现象」最低帧率, 也就是约 41.7 ms 每帧. 低于此帧率, 人 眼会感觉到画面的不连续. 把每帧超出 41.7 ms 的时间算作造成卡顿的时间, 剩下的时间算作流畅时间. 流畅时间和总时间的比值, 定义为流畅度.
JX3Jank的定义:
当前帧耗时(ftime),超过前五次帧耗时(ftime)的均值的1.5倍,记为一次JX3Jank。
CPU Usage
(Total整机/App进程,统计结果合Xcode一致)
Memory
(是统计FootPrint,注:OOM与FootPrint有关,与系统、机型无关。只与RAM有关,如1G内存机器。FootPrint超过650MB,引发OOM)。受iOS平台限制,暂时无法获取ios10及以下系统的memory。如做性能测试,建议升级iOS系统版本
Xcode Memory
(XCode Debug Gauges统计方式即XCode Memory)受iOS平台限制,暂时无法获取ios10及以下系统的Xcode Memory。如做性能测试,建议升级iOS系统版本
Real Memory
(Xcode Instrument统计方式即Real Memory,实际占用物理内存。注:物理内存与系统策略有关,关注意义不大)
Virtual Memory
(虚拟内存)
Wakeups
(线程唤醒次数)。注:超过150进程很大可能会被系统kill
CSwitch
(上下文切换测试)。注:单核超过14000进程会被系统Kill
GPU Utilization
(Render/Tilter/Device)
- Render:渲染器利用率(像素着色处理阶段,若占比高,说明是PS阶段出现瓶颈,shader过于复杂或纹理大小、采样复杂等)
- Tilter:Tilter利用率(顶点着色处理阶段,若占比高,说明是VS阶段出现瓶颈,顶点数太多等原因)
- Device:设备利用率(整体GPU利用率)
Network
(Recv/Send,测试目标进程流量,和Xcode结果一致)
Battery Power
(整机实时Current电流、Voltage电压、Power功耗)(注: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)。
- 参考
无法访问时可能需要使用VPN
:https://help.apple.com/xcode/mac/11.0/index.html?localePath=en.lproj#/devf7f7c5fcd (opens new window)
BatteryTemp
(电池温度)
IO
- ReadBytes/WrittenBytes(测试目标进程的IO读写量)
Gpu
- GpuGeneralCounter
- TotalOccupancy:GPU通用计算使用率
- VertexOccupancy:顶点使用率
- FragmentOccupancy:片段使用率
- ComputeOccupancy:计算使用率
- GpuMemoryCounter
- BufferReadLimiter:缓冲读取限制率
- BufferLoadUtilization:缓冲负载利用率
- TextureSampleLimiter:GPU写入纹理限制率
- TextureSampleUtilization:纹理样本利用率
- GpuReadBandwidth:GPU读取带宽
- GpuWriteBandwidth:GPU写入带宽
- GpuShaderCounter
- AluLimiter:ALU限制率
- AluUtilization:ALU利用率
- F32Utilization:F32利用率
- F16Utilization:F16利用率
- GpuGeneralCounter
# Android 平台
- Screenshot
- FPS(1 秒内游戏画面或者应用界面真实平均刷新次数,俗称帧率/FPS)
- Avg(FPS):平均帧率(一段时间内平均 FPS)
- Var(FPS):帧率方差(一段时间内 FPS 方差)
- Drop(FPS):降帧次数(平均每小时相邻两个 FPS 点下降大于 8 帧的次数)
- 注解特殊情况:
// 采样频率为1s一次, 刷新频率是dumpsys获取的数据, FTime是真实的一次刷新的时长
FTime: ... |<-------------1700------------>|...
refresh freq: | |
sample freq: | | |
0 1000 2000
在上图这种FTime>1000
的情况下时, 因为这个FTime处于两个采样周期中, 并且该FTime在第二个采样周期结束之前完成,也就是1000-2000
这个采样段中采到了1700的FTime, 因此对于上图这种情况而言, FPS是不会等于0。
// 采样频率为1s一次, 刷新频率是dumpsys获取的数据, FTime是真实的一次刷新的时长
FTime: ... |<-------------1700------------>|...
refresh freq: | |
sample freq: | | |
0 1000 2000
在上图这种FTime>1000
的情况下时, 虽然这个FTime仍然为1700, 但其跨越了三个采样周期,在1000-2000
这个区间内sample其实是没有拿到FTime数据的, 因此在这种情况下FPS会等于0。
Jank
(1s 内卡顿次数。iOS9.1 以下系统暂时不支持。类似 Android 的 Jank 卡顿和 iOS 的 FramePacing 平滑度统计原理。帧率 FPS 高并不能反映流畅或不卡顿。比如:FPS 为 50 帧,前 200ms 渲染一帧,后 800ms 渲染 49 帧,虽然帧率 50,但依然觉得非常卡顿。同时帧率 FPS 低,并不代表卡顿,比如无卡顿时均匀 FPS 为 15 帧。所以,平均帧率 FPS 与卡顿无任何直接关系)
计算方法:同时满足两条件,则认为是一次卡顿 Jank.
- 当前帧耗时>前三帧平均耗时 2 倍。
- 当前帧耗时>两帧电影帧耗时(1000ms/24*2=84ms)。
同时满足两条件,则认为是一次严重卡顿 BigJank.
- 当前帧耗时>前三帧平均耗时 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。
- BigJank:1s 内严重卡顿次数
- Jank(/10min):平均每 10 分钟卡顿次数。
- BigJank(/10min):平均每 10 分钟严重卡顿次数
FTime
(上下帧画面显示时间间隔,即认为帧耗时,iOS9.1 以下系统暂时不支持。)
- Avg(FTime):平均帧耗时
- Delta(FTime):增量耗时(平均每小时两帧之间时间差>100ms 的次数)
smoothness 的定义:
24 fps 是人眼「似动现象」最低帧率, 也就是约 41.7 ms 每帧. 低于此帧率, 人 眼会感觉到画面的不连续. 把每帧超出 41.7 ms 的时间算作造成卡顿的时间, 剩下的时间算作流畅时间. 流畅时间和总时间的比值, 定义为流畅度.
JX3Jank 的定义:
当前帧耗时(ftime),超过前五次帧耗时(ftime)的均值的 1.5 倍,记为一次 JX3Jank。
CPU Usage
(Total 整机/App 目标进程,统计结果和 Android Studio Profiler 一致)
CPU Clock
(各个 CPU 核心的频率和使用率)
Memory
(PSS Memory,统计结果和 Android Java API 标准结果一致,与 Meminfo 也一致。
Swap Memory
(Swap Memory)
Virtual Memory
Memory Detail
(NativePSS、GFX、GL、Unknown)
GPU Usage
(目前仅支持高通芯片手机)
GPU Frequency
(目前仅支持高通芯片手机)
Network
(Recv/Send)
CTemp
(CPU 温度)
Battery Power
(Current 电流、Voltage 电压、Power 功率)(注:与仪器测试误差<3%左右)
MaliGpu
- MaliGpuGeneralCounter
- Non Fragment:非片段着色器
- Fragment:片段着色器耗费的GPU时间占渲染耗费的GPU时间的比例
- MaliGpuShaderCounter
- Over Draw:表示每个像素由多少个片段分层组成,通常用于表示像素被重复绘制的次数
- Pixels Throughput:表示每个被渲染的像素耗费的GPU的时钟的数量
- MaliGpuMemoryCounter
- L2LoadStore:Load/Store单元读取L2内存的实际带宽
- L2Texture:Texture单元读取L2内存的实际带宽 (纹理采样)
- Bus Read:定义GPU到DRAM或者GPU外部的系统内存的实际读带宽
- Bus Write:定义GPU到DRAM或者GPU外部的系统内存的实际写带宽
- MaliGpuGeneralCounter
QComGpu
- QComGpuGeneralCounter
- GpuUtilization:Percentage utilization of the GPU
- GpuBusBusy:Approximate Percentage of time the GPU's bus to system memoryis busy
- ShadersBusy:Percentage of time that all Shader cores are busy
- PreClippedPolygons:Number of polygons submitted to the GPU, per second, before any hardware clipping
- QComGpuMemoryCounter
- ReadTotal:Total number of bytes read by the GPU from memory, per second
- WriteTotal:Total number of bytes written by the GPU to memory, per second
- TextureL2Miss:Number of L2 texture cache misses divided by L2 texture cache requests.This metric does not consider how many texture requests are made per time period, but is simple miss to request ratio
- StalledOnSystemMemory:Percentage of cycles the L2 cache is stalled waiting for data from system memory
- QComGpuShaderCounter
- VerticesShaded:Number of vertices submitted to the shader engine, per second
- FragmentsShaded:Number of fragments submitted to the shader engine, per second
- QComGpuGeneralCounter
PVRGpu
- PVRGpuGeneralCounter
- Renderer Active:This counter shows the percentage of time that Renderer tasks were active. Renderer time refers to any time that is spent processing pixels and shading them. This includes the ISP (Image Synthesis Processor), Texturing and Shader Processor units
- Tiler Active:his counter shows the percentage of time that Tiler tasks were active. Tiler time includes vertex processing and all the projection, clipping, culling and tiling/binning operations
- HSREfficiency:Percentage of time that all Shader cores are busy
- SPMActive:Number of polygons submitted to the GPU, per second, before any hardware clipping
- PVRGpuMemoryCounter
- Gpu Memory Read Bytes:This counter shows the rate within the current period that the GPU is reading data from the system memory bus
- Gpu Memory Write Bytes:This counter shows the rate within the current period that the GPU is writing data to the system memory bus
- Gpu Memory Total Bytes:This counter shows the rate within the current period that the GPU is reading or writing data over the system memory bus
- Gpu Memory Interface Load:This counter shows the total utilisation of the GPU memory bus, for both read and write memory operations over the GPU memory interface within the current period
- PVRGpuShaderCounter
- Shaded Vertices:This counter represents the total number of vertices that the Shader unit has processed per second
- Shaded Pixels:This counter represents the total number of pixels that the Shader unit has processed per second
- OverDraw:It indicates how many segments each pixel is composed of. It is usually used to indicate the number of times the pixel is drawn repeatedly
- PVRGpuGeneralCounter