更新时间:2023.01.31 10:13:35
进行性能测评时推荐细分业务场景,比如核心页面、Feed流的滑动、App的启动1分钟内的操作场景等。因为资源消耗和使用场景密切关联,通常无法约定统一标准。
判断是否发生内存泄漏
判断是否存在明显卡顿
判断相比上一版本,内存、CPU、FPS指标是否发生劣化
Android提供了CPU、卡顿和内存的指标,后续将增加功耗、流量以及IO等。
App监控提供了4个CPU使用率来衡量CPU的消耗,推荐使用规范化的App CPU使用率来作为应用的测评标准。
整机CPU使用率
整机CPU使用率用于衡量设备的负载情况。数值越大,表明当前手机任务越繁忙。
计算原理:
CPU执行时间片 = A时刻的CPU(总时间片 - Idle状态时间片) - B时刻的CPU(总时间片 - Idle状态时间片)
总时间片 = A 时刻的CPU总时间片 - B时刻的CPU总时间片
CPU使用率 = CPU执行时间片/总时间片
CPU的时间片可以通过cat /proc/stat
获取。
App CPU使用率
App CPU使用率用于衡量App对CPU的使用情况。
计算原理和计算方式和系统CPU使用率计算相似,使用指定进程的时间片,通过cat /proc/pid/stat
获取。
规范化使用率:参考腾讯的指标设计,增加了这一指标。即考虑到手机cpu频率是变化的,用传统cpu使用率计算方法,在低频率时刻计算出cpu使用率=30%,和在cpu高频时刻计算出cpu使用率=30%。同样都是30%但性能消耗显然后者更高。
计算原理:
规范化使用率 = 上述计算的CPU使用率 * (当前所有CPU频率之和/所有CPU频率最大值之和)
类似于CPU使用率,这里增加了分别对每一个核的计算。可以综合考量当前CPU的调度和使用情况。
提供每个核的频率变化曲线,可以用来考量CPU的调度情况。
针对流畅性,一共提供了8个参考指标。
指标 | 解释 |
---|---|
FPS | 数据获取时间周期内,实际渲染帧数/ 数据获取间隔时间。 |
Jank | 单帧绘制耗时> MOVIE_FRAME_TIME 时,计一次jank。 |
BigJank | 单帧绘制耗时> 3 * MOVIE_FRAME_TIME 时,计一次big jank。 |
Stutter | 卡顿比。当发生jank的帧的累计时长与区间时长的比值。 |
其中,MOVIE_FRAME_TIME即一帧电影的耗时,一般电影是24帧每秒,所以
MOVIE_FRAME_TIME = 1000 / 24
简单情况下,推荐使用FPS来衡量页面综合流畅度,重点关注BigJank的发生场景。
指标 | 说明 |
---|---|
TotalPSS | Proportional Set Size 实际使用的物理内存(按比例分配共享库占用的内存) |
VMSize | 虚拟内存大小。
|
VMSwap | VM交换区 |
Available | 可用内存 |
当App发生非Java OOM的时候,大部分是因为虚拟内存不足,所以推荐重点关注VmSize的增长情况。
指标名 | 说明 |
---|---|
JavaHeap | 从 Java 或 Kotlin 代码分配的对象的内存。由于Java堆之外的内存分配与Java分配绑定。应用程序将调用Android框架,Android框架调用Native库,并且内存分配。它们的生命周期将与Java对象相关联。优化 Java Heap 上的对象,也有助于其它类型内存的回收。 |
NativeHeap | Natie Heap(从 C 或 C++ 代码分配的对象内存。即使应用中不使用 C++,也可能会看到此处使用的一些原生内存,因为 Android 框架使用原生内存代表处理各种任务,如处理图像资源和其他图形时。 |
Code | dex jar so ttf 等文件占用的内存 |
Stack | 栈内存 |
Graphics | 指图形缓冲区队列向屏幕显示像素(包括 GL 表面、GL 纹理等等)所使用的内存 |
Other | 不确定如何分类的私有内存 |
System | 系统代码占用的内存 |
Unknown | 其它未知内存 |
详细具体的说明Heap、Stack、ASH、Device、Mmap、MemTrack、Other等模块分配情况
指标名 | 说明 |
---|---|
Native Heap | 同上:Native/C malloc内存 |
Dalvik Heap | 同上:Java/Kotlin对象占用内存 |
Dalvik Other | 分法准确分类的Java/Kotlin对象占用的其它内存 |
Stack | 栈内存 |
Ashmem | Android Shared Memory共享内存 |
Gfx dev | 驱动反馈的GPU内存,主要是GL纹理大小总和 |
Other dev | 分法准确分类的device内存 |
.so mmap | 映射的.so代码占用内存 |
.jar mmap | 映射的.jar代码占用内存 |
.apk mmap | 映射的.apk代码占用内存 |
.ttf mmap | 映射的.ttf代码占用内存 |
.dex mmap | 映射的.dex(Dalvik 或 ART)代码占用内存 |
.oat mmap | 代码映像(预加载类)占用内存,所有应用之间共享 |
.art mmap | 堆映像(预加载类)占用内存,所有应用之间共享 |
Other mmap | 分法准确分类的mmap映射内存 |
GL mtrack | 驱动上报的GL内存使用情况。 主要是GL texture大小,GL command buffer,固定的全局驱动程序RAM开销等的总和 |
EGL mtrack | 主要是SurfaceView和TextureView的总和 |
Other mtrack | 分法准确分类的mtrack内存 |
也可参考官方对dumpsys memInfo更详细的说明
设备电流(功率=电流*电压,设备电压恒定)可以用来衡量整机的功耗情况。只保留待测应用处于前台运行,且尽可能关闭其他应用时,可以用整机的功耗来衡量待测应用的功耗。这就是功耗测评的基本背景。
Android系统提供了官方API来查询当前的电流电压,经过实测,在不同厂商设备上存在电流单位不一致正负值不一致的问题(注意:在没有连接充电线时,电流预期为正值,进行功耗测评时必须关闭USB连接,不能在充电的同时进行功耗的测量),经过反复校验以及和设备厂商的沟通,最终基于官方API进行了兼容处理,实现了对市面上绝大多数机型的适配,能够准确获取设备电流,和电流仪的监控值误差极小。因此确定了通过SDK采集电流来作为衡量功耗的指标。线上ApmPlus功耗监控使用同一实现。
上述原理决定了无法实现类似CPU测评一样仅通过ADB即完成工作,这里APM提供了一个额外的功耗测评App(名为手机端的AnyTrace),App里包含了开发的电流采集SDK。采集到电流数据后,再通过socket传输到桌面端的App性能分析工作台(此处开发基于Facebook开源的Flipper)。
性能分析工作台的版本为0.3.0以上的版本。
手机已下载并安装AnyTrace。
采集过程中,需要保持AnyTrace不被系统优化杀死,所以如果您的手机有耗电优化策略,注意把AnyTrace放到白名单中。一般情况下,App会开启前台服务,大部分手机不会关闭。
手机和电脑需要连接在同一WiFi下。在进行功耗测评时,按照软件提示进行WiFi的连接。另外,部分设备的WiFi连接稳定性较差,尽量选择连接稳定的WiFi进行使用。
USB连接手机,选择待测App。
在左侧导航栏,单击性能测评。
在性能测评页面,选择功耗数据。
单击启动。软件开始尝试进行WiFi连接、手机端App连接。
断开USB链接后,单击确定。然后再在设备列表里选择WiFi标识的待测设备。选择设备后,可能需要重新选择待测App和进程。
在WiFi设备、待测App、待测进程都完备后,再次单击启动。即可采集到电流数据。
如果出现离线提示,则意味着WiFi失联,可能是因为手机WiFi不稳。如果不能自动恢复,请重启手机。
如果WiFi设备、待测App、待测进程都完备,单击启动后仍弹出对话框,提示无法采集或始终无法出现测评图表等如下图的BadCase,请依次尝试以下解决方法:
其他情况请在交流群中反馈。反馈前,可连续单击左下角版本号5下,会弹出已上传提示,把异常日志上传到后台,便于分析。
使用率=总CPU使用率(Xcode中展示的使用率)/核心数
1秒内应用界面真实平均刷新次数,俗称帧率/FPS
FPS Avg: 平均帧率(一段时间内平均FPS)
Jank
BigJank
Stutter
指定时间内卡顿的时长占比,Stutter(卡顿率) = ∑Jank time / Time,Jank为卡顿次数,Stutter为卡顿率,Jank和Stutter趋势有一致性,但并非完全线性,因为每次Jank卡顿严重性是不一样的。同时也说明了,没有Jank卡顿出现,自然也就卡顿率是0了。
不同业务类型、不同场景下,资源使用差别较大,并非要追求资源消耗的绝对的低值,需要和业务需求、用户体验间综合衡量,建立业务指标和性能指标的关联关系,然后选择合适的指标和标准进行控制和优化。同时,一般情况下,还需要针对高中低三档机型进行分别设置。
例如,低端机上同样的代码性能较差,在无损降级取得一定收益后,已经无法取得相对大盘更大的收益,通过AB实验发现一定的有损降级,比如去掉某些动画,能带来更好的单击率的数据,通过反复调整降级点,在线下取得更好的性能指标,最终在线上也带来了显著的播放时长收益。最终确立了低端机下后续的性能标准。
一般的指标确立思路如下所示:
当前版本指标定为标准,新版本保证不劣化(或者在一定范围内,比如启动耗时增加少于5毫秒)。
针对显著影响直观感受的先确定明确的卡口标准。比如Feed流的滑动卡顿对用户体验有明显的损失,方便确定中档机型FPS均值不低于58,持续滑动1分钟卡顿次数少于2次。
尝试一定的劣化实验验证预期收益。比如AB实验发现启动增加10%,用户留存明显降低,基本可以确定,如果能优化启动10%,那么能给留存率带来接近的提升。那么指标标准就应该进行提高。
性能测评的数据可以导出,然后用软件导入可以恢复展示。
其中,windows版本需要通过快捷键触发。导入:ctrl + i,导出: ctrl + e
性能测评的原始数据和报告数据也可以导出为Excel格式。
在图表上双击添加标记。单击标记位置可以删除标记。
数据的准确性如何保证?
在内部抖音、头条上多个App经过了大约一年多的验证,尽可能保证了数据采集和计算的准确度。
指标是否有标准,即超过多少作为性能发生异常?
参考上文指标标准。
iPhone的IP地址的获取。
设置 > 无线局域网 > WiFi详情 > IP地址。
iPhone的Mac地址的获取 。
设置> 通用> 关于本机> 无线局域网地址,不应为WiFi详情中无线局域网地址,WiFi设置中一旦开启私有地址,该MAC地址就会改变,关于本机中的无线局域网地址固定不变。
iPhone WiFi连接失败
限制级WIFI(部分公司内网)
通过USB授权WiFi连接并输入IP & Mac地址,参考获取方式,windows用户需先安装Bonjour SDK。