# 参数说明
软件数据采集说明
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)
方法的次数。Logic FPS
游戏逻辑FPSVertice
每一帧所有经过处理的顶点数量总和Primitive
每一帧所有经过处理的图片( 三角形,点,线) 的数量总和Dispatch
调用 ID3D11DeviceContext::Dispatch, ID3D11DeviceContext::DispatchIndirect的次数 (dispatch) 次数Total
(系统总CPU使用率)App
(进程CPU使用率)CPU Clock
(各个CPU核心的未规范化频率和未规范化使用率)CPU Usage
(Total整机/App目标进程,统计结果和任务管理器一致)CPU Core Usage
(系统每个CPU核心的使用率)Utility
(总cpu 使用率 对应Windows性能计数器中的Processor Utility)Memory
(进程的Private Bytes,统计结果和VMMap Private Bytes结果一致,与任务管理器-详细信息-提交内存也一致。)Working Set
(进程的工作集内存,统计结果和VMMap Working Set结果一致,与任务管理器-详细信息-工作集(内存)也一致)Swap Memory
(系统的Swap Memory)GPU Usage
(GPU使用率,统计结果和GPU-Z结果一致)GPU Load
(GPU使用率)GPU Clock
(各Gpu核心的未规范化频率和为规范化使用率)GPU Memory Used
(GPU显存,统计结果和GPU-Z结果一致)Board Power Draw
(主板芯片功耗)Shared Usage
(共享GPU内存,统计结果和任务管理器结果一致)Dedicated Usage
(专用GPU内存,统计结果和任务管理器结果一致)Network
(Recv/Send,测试目标进程流量)Renderer (渲染器利用率(像素着色处理阶段,若占比高,说明是PS阶段出现瓶颈,shader过于复杂或纹理大小、采样复杂等))
- GPA Renderer
- Intel Cpu Counter
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。Total:
(系统总CPU使用率)App:
(进程CPU使用率)CPU Clock:
(各个CPU核心的未规范化频率和未规范化使用率)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进程很大可能会被系统killCSwitch
(上下文切换测试)。注:单核超过14000进程会被系统KillGPU 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(GPU基础信息计数器)
- TotalOccupancy:GPU使用率
- VertexOccupancy:测量用于执行顶点线程的 GPU 总线程容量的百分比
- FragmentOccupancy:测量用于执行片段线程的 GPU 总线程容量的百分比
- ComputeOccupancy:测量用于执行计算命令的 GPU 总线程容量的百分比
- GpuMemoryCounter(显存计数器)
- BufferReadLimiter:GPU从 buffers 中读取数据所花费时间的占比(包含stall时间)
- BufferLoadUtilization:GPU从 buffers 中读取数据所花费时间的占比(排除stall时间)
- TextureSampleLimiter:GPU花费在 sampling texture 上的时间占比(包含stall时间)
- TextureSampleUtilization:GPU花费在 sampling texture 上的时间占比(排除stall时间)
- GpuReadBandwidth:GPU每秒从内存中读取的数据量
- GpuWriteBandwidth:GPU每秒向内存中写入的数据量
- GpuShaderCounter(GPU 着色器周期计数器)
- AluLimiter:GPU花费在算数,逻辑,位运算上的时间占比(包含stall时间)
- AluUtilization:GPU花费在算数,逻辑,位运算上的时间占比(排除stall时间)
- F32Utilization:GPU花费在32位浮点运算上的时间占比
- F16Utilization:GPU花费在16位浮点运算上的时间占比
- GpuGeneralCounter(GPU基础信息计数器)
# 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 Clock:
(各个GPU核心的未规范化频率和未规范化使用率)Dedicated Usage
(系统所使用的专用GPU内存)GPU Frequency
(目前仅支持高通芯片手机)Network
(Recv/Send)CTemp
(CPU 温度)GTemp
(GPU 温度)BatteryTemp
(电池温度)Battery Power
(Current 电流、Voltage 电压、Power 功率)(注:与仪器测试误差<3%左右)MaliGpu
- MaliGpuGeneralCounter(GPU基础信息计数器)
- Non-fragment queue utilization:非片段着色器耗费的GPU时间占渲染耗费的GPU时间的比例
- Fragment queue utilization:片段着色器耗费的GPU时间占渲染耗费的GPU时间的比例
- MaliGpuShaderCounter(maliGPU 着色器周期计数器)
- Fragments/pixel:表示每个像素由多少个片段分层组成,通常用于表示像素被重复绘制的次数
- GPU cycles/pixel:指平均每个已着色Pixel所耗费的GPU Cycle
- MaliGpuMemoryCounter(mali 显存计数器)
- Load/store bytes:Load/Store单元读取L2内存的实际带宽
- Texture bytes:Texture单元读取L2内存的实际带宽 (纹理采样)
- Read bytes:定义GPU到DRAM或者GPU外部的系统内存的实际读带宽
- Write bytes:定义GPU到DRAM或者GPU外部的系统内存的实际写带宽
- Mali Pixels Info(Mali Geometry Usage:maliGPU 像素信息计数器)
- OverDrawthreads:表示每个像素由多少个片段分层组成,通常用于表示像素被重复绘制的次数,单位:threads
- PixelsThroughputcycles:表示每个被渲染的像素耗费的GPU的时钟的数量,单位:cycles
- CulledPrimitives:在渲染过程中被剔除的图元个数,单位:个
- VisiblePrimitives:在所有culling stages之后仍然可见的图元个数,单位:个
- InputPrimitives:进入渲染过程的输入图元的总数,单位:个
- Mali Shader Cycles(maliGPU着色器计数器)
- Shader Cycles:shader活跃的cycles,单位:cycles
- Shader Fragment Cycles:可变单元活跃的cycles,单位:cycles
- Shader Arithmetic Cycles:算数单元活跃的cycles,单位:cycles
- Shader LoadStore Cycles:加载单元活跃的cycles,单位:cycles
- Shader Texture Cycles:纹理单元活跃的cycles,单位:cycles
- Mali Memory & Bus Bandwidth
- L2LoadStore:Load/Store单元读取L2内存的实际带宽(包括项点缓存,原子,图像数据),单位:MB
- L2Texture:Texture单元读取L2内存的实际带宽(纹理采样),单位:MB
- BusRead:定义GPU到DRAM或者GPU外部的系统内存的实际读带宽,单位:MB
- BusWrite:定义GPU到DRAM或者GPU外部的系统内存的实际写带宽,单位:MB
- MaliGpuGeneralCounter(GPU基础信息计数器)
QComGpu
- QComGpuGeneralCounter(QComGPU基础信息计数器)
- GPU % Utilization:GPU 使用率
- GPU % Bus Busy:GPU到内存总线的繁忙时间的百分比
- % Shaders Busy:shader繁忙时间的百分
- Pre-clipped Polygons/Second:在硬件裁剪之前每秒提交给 GPU 的多边形数
- QComGpuMemoryCounter(QCom显存计数器)
- Read Total (Bytes/sec):GPU每秒从内存中读取的数据量
- Write Total (Bytes/sec):GPU每秒向内存中写入的数据量
- % Texture L2 Miss:L2纹理缓存的未命中百分比
- % Stalled on System Memory:L2缓存等待内存数据而被迫stall的百分比
- QComGpuShaderCounter(QComGPU 着色器周期计数器)
- Vertices Shaded / Second:每秒钟提交到shader的顶点的数
- Fragments Shaded/ Second:每秒钟提交到shader的片段的数量
- QComGpuGeneralCounter(QComGPU基础信息计数器)
PVRGpu
- PVRGpuGeneralCounter(PVRGPU基础信息计数器)
- RendererActive:渲染器任务处于活动状态时间的百分比
- TilerActive:任务处于活跃状态时间的百分比
- HSREfficiency:HSR Engine丢弃的模糊像素占输入像素的百分比
- SPMActive:表示由 SPM 引起的渲染器任务百分比
- PVRGpuMemoryCounter(PVR显存计数器)
- GpuMemoryReadBytes:GPU每秒从内存中读取的数据量
- GpuMemoryWriteBytes:GPU每秒向内存中写入的数据量
- GpuMemoryTotalBytes :GPU每秒从内存中读取/写入的数据量
- GpuMemoryInterfaceLoad:GPU内存总线的使用率
- PVRGpuShaderCounter(PVRGPU 着色器周期计数器)
- Shadedvertices:每秒钟shader产生顶点数的总数
- ShadedPixels:每秒钟shader产生像素点的总数
- Fragments/pixel:表示每个像素由多少个片段分层组成,通常用于表示像素被重复绘制的次数
- PVRGpuGeneralCounter(PVRGPU基础信息计数器)
# SteamDeck 平台
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.67ms*2,三帧电影帧耗时是41.67ms*3。
- BigJank:1s内严重卡顿次数
- Jank(/10min):平均每10分钟卡顿次数。
- BigJank(/10min):平均每10分钟严重卡顿次数
FTime (上下帧画面显示时间间隔,即认为帧耗时。)
- Avg(FTime):平均帧耗时
- Delta(FTime):增量耗时(平均每小时两帧之间时间差>100ms的次数)
Logic FPS:
1秒内游戏逻辑更新的次数CPU
- Total:总CPU使用率,单位:%
- App:app CPU使用率,单位:%
- CPUUsage:单核CPU 使用率,单位:%
- CPU Clock:CPU 频率,单位:MHz
- CPU Temp:CPU 温度, 单位:℃
- CPU Core Usage :各个CPU Core使用率,单位%
GPU
- GPU Usage:GPU使用率, 单位:%
- GPU Freq:GPU频率,单位:MHz
- GPU Memory Clock:显存频率,单位:MHz
- GPU Memory Used:显存大小,单位:MB
- GPU Power:显卡功耗,单位:W
- GPU Temp:显卡温度, 单位: ℃
Memory
- Memory:RSS,单位:MB
- SwapMemory:系统虚拟内存占用率,单位:%
- Virtual Memory:进程所需用的虚拟内存,VSS,单位MB
- RAM:整机内存使用情况,单位:MB
# HarmonyOS 平台
Screenshot
(主屏幕截图)FPS
(1秒内游戏画面或者应用界面真实平均刷新次数,俗称帧率/FPS)- Avg(FPS):平均帧率(一段时间内平均FPS)
- Var(FPS):帧率方差(一段时间内FPS方差)
- Drop(FPS):降帧次数(平均每小时相邻两个FPS点下降大于8帧的次数)
Jank
(1s内卡顿次数。类似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
(上下帧画面显示时间间隔,即认为帧耗时。)- Avg(FTime):平均帧耗时
- Delta(FTime):增量耗时(平均每小时两帧之间时间差>100ms的次数)
Total
(系统总CPU使用率,单位%)App
(进程CPU使用率,单位%)GPU Usage
(GPU使用率,单位%)Memory
(PSS Memory)Swap Memory
(系统已使用的交换内存大小, SwapTotal - SwapFree, 单位GB)Virtual Memory
(进程已使用的虚拟内存(VSS))GPU Memory
(GPU 显存使用率)CPU Energy
(CPU 使用能耗占系统总能耗的百分比)GPU Energy
(GPU 使用能耗占系统总能耗的百分比)Location Energy
(Location 使用能耗占系统总能耗的百分比)Display Energy
(显示屏 使用能耗占系统总能耗的百分比)Other Energy
(Other 使用能耗占系统总能耗的百分比)Network
(Recv/Send,测试目标进程流量)
# Xbox 平台
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.67ms*2,三帧电影帧耗时是41.67ms*3。
- BigJank:1s内严重卡顿次数
- Jank(/10min):平均每10分钟卡顿次数。
- BigJank(/10min):平均每10分钟严重卡顿次数
FTime
(上下帧画面显示时间间隔,即认为帧耗时。)- Avg(FTime):平均帧耗时
- Delta(FTime):增量耗时(平均每小时两帧之间时间差>100ms的次数)
Logic FPS:
1秒内游戏逻辑更新的次数CPU
- CPU Core Usage:CPU各核心使用率
- CPUUsage:多核CPU 使用率,单位:%
GPU
- GPULoad:GPU使用率,单位:%
- GPUMemory Used:显存大小,单位:GB
Memory
- Total Used Memory (The total amount of memory currently allocated by the title 总内存使用量)
- Total Used Optimal Memory (The total amount of optimal memory currently allocated by the title 进程实际使用的最优内存总量)
- Total Accessible Memory ( The total amount of memory accessible by the title 可访问的内存总量)
- Total Accessible Optimal Memory ( The total amount of optimal memory accessible by the title, 系统已使用的物理内存)
- Tooling Accessible Memory (The amount of accessible tooling memory 可访问的工具内存量)
- Tooling Used Memory (The amount of currently allocated tooling memory 当前分配的工具内存量)
Network
- Send:应用发送流量,单位:b/s
- Recv:应用接收流量,单位:b/s
# PS5 平台
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:
上下帧画面显示时间间隔,即认为帧耗时- Avg(FTime):平均帧耗时
- Delta(FTime):增量耗时(平均每小时两帧之间时间差>100ms的次数)
Logic FPS:
1秒内游戏逻辑更新的次数Memory
- Memory Usage:目标进程内存的使用量
CPU
- CPUUsage:多核CPU 使用率,单位:%
PlayStation
- GPUFlipDone:GPU Flip Done事件频率
- GPUFlipRequest:GPU Flip Request事件频率
- CustomSync:调用sceRazorCpuSync()函数的频率
GPU
- AllActivity:所有GPU活动合计的使用率,单位:%
- PipelineActivity:管道的GPU使用率
- CommandProcessorBlock:Command Processor Block的GPU使用率
- CommandProcessorFetchers:Command Processor Fetchers的GPU使用率
- CommandProcessorGraphics:Command Processor Graphics的GPU使用率
- CommandProcessorCompute:Command Processor Compute的GPU使用率
- InputAssembler:Input Assembler的GPU使用率
- InputAssemblerExcDMA :Input Assembler (除了DMA)的GPU使用率
- ShaderPipeInstructions:Shader Pipe Instructions的GPU使用率
- ShaderExportBlocks:Shader Export Blocks的GPU使用率
- TexturePipes:Texture Pipes的GPU使用率
- TextureCacheBlocks:Texture Cache Blocks的GPU使用率
- VertexGeometryTessellatorBlocks:Vertex Geometry Tessellator Blocks的GPU使用率
- PrimitiveAssemblyBlocks:Primitive Assembly Blocks的GPU使用率
- ScanConverterBlocks:Scan Converter Blocks的GPU使用率
- DepthBlocks:Depth Blocks的GPU使用率
- ColorBlocks:Color Blocks的GPU使用率
- GlobalDataShare:Global Data Share的GPU使用率
Energy Usage
- CoreTargetClockOS :Core Target Clock系统的使用功耗
- CoreTargetClockGame:Core Target Clock游戏的使用功耗
- GfxEffectiveClock:Gfx Effective Clock的使用功耗
- GfxTargetClock:Gfx Target Clock的使用功耗
- CoreTotalCACOS:Core Total CAC系统的使用功耗
- CoreTotalCACGame:Core Total CAC游戏使用的功耗
- GfxTotalCAC:Gfx Total CAC的使用功耗
- G6BWRead:G6 BW Read的使用功耗
- G6BWWrite:G6 BW Write的使用功耗
- G6BWIOPower:G6 BW IO Power的使用功耗
- SocketLevelTotalCA:Socket Level Total CAC的使用功耗
IO
- WriteThrottlingLevel:机器SSD的写入限制级别
- WriteThrottlingBudget:机器SSD的写入预算
# Switch平台
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:
上下帧画面显示时间间隔,即认为帧耗时- Avg(FTime):平均帧耗时
- Delta(FTime):增量耗时(平均每小时两帧之间时间差>100ms的次数)
CPU
- CpuTime: CPU耗时,单位:ms
GPU
- GpuTime: GPU耗时,单位:ms
- GpuAllocated:Unity为GPU资源(如纹理、着色器、网格缓冲区等)分配的内存(Memory explicitlyallocated by the Unity player for Gpu resources e.g. Textures, shaders, Mesh buffers,etc.),单位:MB
- GpuReserved:Unity为Gpu资源所申请占用的内存(Memory claimed by the Unity player for Gpuresource allocations. All Gpu,Allocated bytes come from within this reservation.) ,单位:MB
Memory
- TotalMemory:进程在Switch上使用的总内存(Total memory in use on the Nintendo Switchexcluding executable size),单位:MB
- AllocatedMemory:Unity实际分配的内存(Memory explicitly allocated by the Unity player.),位:MB
- ReservedMemory:Unity为程序运行申请占用的内存(Memory claimed by the Unity plaver forruntime allocations. All Mem,Allocated bvtes come from within this reservation.),单位:MB
- GCHeap:GCHeap的大小(The size of the Gc heap and how much is currently used.),单位:MB
- GCUsed:GCHeap的使用量(The size of the Gc heap and how much is currently used.),单位:MB
- LowLevelAllocations:Low Level allocations made by the Unity player outside of MemReserved reservation,单位:MB
- ExternalAllocations:emory allocations made by systems not tracked by Unity. This can befrom 3rd party native plug-ins or similar,单位:MB
- SysFreeSpace:剩余的内存空间总量(Total free space remaining for allocations.),单位:MB
- SysAllocatable:剩余的可分配内存总量(The largest possible allocation that can currentlybe successfully reguested.),单位:MB
- TotalAvailableMemorySize:整机可用内存,单位:MB
- TotalUsedMemorySize:整机已使用内存,单位:MB
- TotalMemoryHeapSize:整机可用堆内存,单位:MB
- AllocatedMemoryHeapSize:整机分配堆内存,单位:MB
- ProgramSize:程序代码和数据大小,单位:MB
Thread
- TotalThreadStackSize:当前创建的线程栈大小,不包括已被销毁的线程和主线程
- ThreadCount:当前线程个数,包括主线程