移动性能测试 [个人总结分享] 安卓端性能测试 (数据篇)

浮云 · 2018年05月28日 · 最后由 浮云 回复于 2018年06月27日 · 235 次阅读

开篇前述:

续《安卓端性能测试 (思路及方案设计篇)》列下主要数据来源,毕竟性能还是要和数据打交道,了解数据来源和探索利用数据的形式很重要,总结下一些常用数据来源。
数据源的文本截取就是编程语言基础能力了。我常用 shell+busybox 设计安卓端监控脚本,通过 busybox 的 sed,grep,awk 解决,两个主要思想:
1、文本流处理,同时截取处理,复杂逻辑设计 awk 解决
2、能文本流一次性保存就不要分多步,影响处理性能
还有一点主导我设计的思想是在监控结果呈现上:通过数据统计引导数据关注点,通过排序引导关键数据呈现。(比如在内存数据呈现上,除了峰值排序,还会关注极值差排序)

正篇开叙

时间数据来源

1、秒级精度
(1)date 命令获取的时间

2、分秒精度
(2)/proc/uptime

3、毫秒精度
(1)Log 时间戳
(2)uiautomator events 信息的 EventTime

4、微秒精度
(1)系统环境变量:$EPOCHREALTIME
(2)getevent -t -l 的时间戳

5、纳秒精度
(1)/proc/timer_list(linx 内核定时器节点)第三行 now at
(2)使用 timer 接口输出的时间,如 vsync 时间

流畅度量化(原创计算需求)

1、帧数据
(1)dumpsys SurfaceFlinger --latency
(2)dumpsys gfxinfo 包名 framestats(安卓 5.0 及以上版本)

2、FPS
(1)帧数据采样间隔 1.6S 左右(60 帧屏 127 帧=2.116S,为了连续抓数据和平衡抓取开销)
(2)统计样本帧数/样本时间;只有一帧按硬件绘制耗时的结束时间计算
(3)Vsync 间隔大于 500ms 算静置,不计算帧率且不输出
(4)空数据、vsync=最大正整数数据不处理
(5)Vsync 帧数据复用,结束时间加首行绘制间隔(注:最早发现这个现象是微信红包弹出效果的数据,有复用帧)

3、硬件掉帧比例( jank% )
(1)帧数据中第三列和第一列的差值,如果大于首行绘制间隔 jank 帧数 +1
(2)Jank 总帧数/样本数据总帧数
(3)引导优化方向为 framework 优化 SurfaceFlinger 绘制性能,如已优化过则主推精简 ui 布局及图片资源大小

4、帧间隔超过 kpi 的帧数比例
(1)按人眼识别卡顿 100ms,可定制
(2)引导优化肉眼可识别的严重卡顿,降低此比例

5、按人眼视觉的当前认知标准判定:
(1)严重卡顿:帧间隔≥100ms(按人眼视觉存在 100ms 的反应时间)
(2)轻微卡顿:50ms≤帧间隔<100ms(游戏帧率可玩底线 20 帧)
(3)延迟:42ms<帧间隔<50ms(视频级体验按网络流 24 帧)

6、流畅度打分评价
(1)比例分配:平均帧率/60*60%+kpi/最大两帧间隔 *20%+ 帧间隔小于 kpi 帧数比例 *20%(除法比例最大为 1,kpi 可定制,按人眼识别卡顿是 100ms)

资源负载

1、CPU:
(1)top –n 1 命令:按单核 100% 计算 cpu 占用。
缺陷:相对 busybox top –b –n 1 执行耗时长、计算精度低,无执行参数、无分配所在核的编号、不同设备预置的版本不同不利于脚本通用性。
(2)dumpsys cpuinfo:获取 cpuinfo 服务计算的系统和进程 cpu 占用快照。
缺陷:累计时段比 top 长、受 dumpsys meminfo 影响会拉高 cpu 占用数值
(3)按节拍数( jiffies )设计代码逻辑计算:/proc/进程 pid/stat
缺陷:逐个进程计算的效率并不比 top 命令高,更适用已知单进程监控

2、内存:
(1)总内存 kernel 节点:/proc/meminfo
(2)dumpsys meminfo:获取内存占用快照,包括总内存和进程内存 pss 排序,加包名/PID 获取进程内存占用细节,会主动触发 GC 后获取。
(3)procrank:eng/userdebug 版本可用,计算进程内存到 uss 占用
(4)ps/busybox ps :包含 VSS 和 RSS

3、IO:
(1)kernel 节点:/proc/进程 pid/io (需 kernel 支持,root 下获取)

4、流量:
(1)/proc/uid_stat// (第一个是 UID,第二个是 tcp_rcv 和 tcp_snd)
(2)/proc/net/xt_qtaguid/stats

频率评估(原创统计形式并开发了监控脚本)

1、Log 打印控制的数据需求:
(1)样本:5 秒的 log(logcat –v thread time)
(2)样本的统计项:总行数/总时间、每个 tag 的打印总行数/总时间
(3)额外信息:tag 的 pid 对应的进程

资源分配上限

1、内存泄露:
(1)受控情况下的最大堆内存大小:getprop dalvik.vm.heapgrowthlimit
(2)不受控情况下的最大堆内存大小: getprop dalvik.vm.heapsize
(3)LowMemoryKiller 值: /sys/module/lowmemorykiller/parameters/adj 与/sys/module/lowmemorykiller/parameters/minfree
(4)进程 VSS 虚拟地址耗尽:32 位=4G、64 位=128G(BSP 会占用 1G,其他是 VSS 可用)

2、Linx 系统限制::
(1)ulimit -a 查看所有限制
(2)文件描述符(/proc/进程 pid/fd):ls –l 查看,统计行数,上限=1024(kernel 可调整)

状态信息

1、UI 状态:
(1)Window: dumpsys window visible
(2)Activity: dumpsys activity top
(3)uiautomator: uiautomator dump xml 文件保存完整

能源状态:

1、显示: dumpsys display
2、电量:dumpsys power
3、能源状态系统节点:主频、温度传感器数据、屏幕亮度等,在不同芯片厂商定义不同

外部硬件采集

1、响应时间/帧率:
(1)摄像头采集 + 机械臂操作
(2)视频采集卡 + 遥控设备

2、能源:
(1)功耗:功耗计(TV)、Power Monitor 及同类产品(手机)
(2)温度:热电偶、红外热成像摄像头

3、硬件模块按需 DIY
(1)淘宝来源如:支持蓝牙模块的 usb 电压电流表、医用温度测试模块、亮度采集模块等等

如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
共收到 2 条回复 时间 点赞

请教大神在监控时如何评估 FPS 的,目前用自动化驱动场景去做监控,但是 FPS 数据毛刺严重,每次 FPS 的测试结果相差较大

leon 回复

我自己写的 fps 计算方法和打分规则,用户体验角度讲,实践后明显 10 分一档,每 10 分跨度都会有体验差异。还有两个维度数据的定向性能问题 highlight:1、硬件掉帧;2、一组采样数据中 100ms≤帧间隔≤500ms 的比例
分别对应推进对应的体验优化,如果是游戏体验,会调整统计 50ms≤帧间隔≤500ms 的比例

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册