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
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使用率
扩展阅读：你真了解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