测试开发进阶(四十八)
电量
统计耗电本身也是一件耗电行为,所以软件统计方式其实都不是很精确
统计方法/工具
- 功耗仪:统计整机的耗电
- 腾讯GT工具
- Battery Historian(Google 官方提供的工具,5.0及以后系统适用)
https://github.com/google/battery-historian
手机投屏软件
windows:apowermirror
Battery Historian
从手机中导出bugreport文件上传至页面,在网页中生成详细的图表数据来展示手机各模块电量消耗过程,然后通过App数据的分析制定出相关的电量优化的方法
- 安装GO python Java
- 使用Docker
1 | docker run -p 9999:9999 registry.cn-beijing.aliyuncs.com/center1/google_battery |
获取方式
记录唤醒锁的信息
1 | adb shell dumpsys batterystats --enable full-wake-history |
重置电量数据
1 | adb shell dumpsys batterystats --reset |
采集电量数据
1 | Android7.0之后 |
流畅度
帧率 & 刷新频率
Refresh Rate
屏幕在一秒内刷新屏幕的次数,取决于硬件的固定参数,如60Hz
Frame Rate
GPU在一秒内绘制操作的帧数,例如30fps,60fps
卡顿root cause
大多数用户感受到卡顿等性能问题的主要根源都是因为渲染性能,android系统无法及时完成那些复杂的界面渲染操作,就产生了卡顿/不流畅的想象
FPS指标
- fps低,但是不觉得App卡
因为本来就用不到那么高的fps,屏幕没有绘制要求,那么fps就为0
- app停止操作后,fps还是一直变化
屏幕每一帧的合成都是针对手机里面所有的进程,当前app停止后其他进程可能还在绘制
计算流畅度
- 系统合成帧率
数据形式最为直观,游戏/视频等连续绘制的应用可以考虑选用,但不适用于绝大多数非连续绘制的应用
- 流畅度(SM:SMoothness)
数据形式和FPS类似,可以很好的弥补FPS无法准确刻画非连续绘制的应用显示性能的缺陷
- 原理:在VSync机制中1s内Loop运行的次数
- 当流畅度越小的时候说明当前程序越卡顿
指标获取
FPS获取
1 | adb shell dumpsys gfxinfo 包名 |
Draw+Prepare+Process+Execute=完整显示一帧的时间
这个时间需要小于16.67ms才能保证不丢帧
- 计算总数据的行数(跳过第一行)
frameCount = rowNum
- 计算每帧的渲染时间
renderTime = Draw + Prepare + Process + Execute
- 当渲染时间renderTime大于16.67ms,该帧渲染超时,算一次丢帧,需要用掉额外的Vsync个数为(多需要同步的信号)
- 16.67整数倍
vsyncOverNum=int(renderTime/16.67)-1
- 非16.67整数倍
vsyncOverNum=int(renderTime/16.67)-1
- fps计算公式
fps=frameCount*60/(frameCount+vsyncOverNum=int)
SM获取
腾讯GT
流畅度影响因素
- UI渲染
界面过度渲染
布局边界合理性
- UI线程复杂运算
- 频繁GC垃圾回收
UI渲染
UI渲染由CPU和GPU两个部分协同完成
- CPU负责UI布局元素的Measure,Layout,Draw等相关运算执行。如果布局边界不合理,会导致卡顿
- GPU负责栅格化,将UI元素绘制到屏幕上,如果界面过度绘制,也可能导致卡顿
页面的过度绘制
一个像素点绘制次数超过1次
开发者选项->调试GPU过度绘制
- 没颜色:没有过度绘制
- 蓝色:1倍过度绘制,1个像素点绘制2次
- 绿色:2倍 3次
- 浅红色:3倍 4次
- 深红色:4倍以上 5次以上
蓝色和绿色可以接受
UI线程复杂运算
当android应用启动时,系统会为应用创建一个主线程,负责和UI组件进行交互
如果主线程里面进行复杂运算就会造成界面无响应/卡顿/不流畅(ANR已经是卡顿的极致了)
- TraceView
分析方法执行时间
- StrictMode(严苛模式)
在代码里或者开发者选项中开启,查看应用哪些操作在主线程上执行时间过长
当一些操作违背了严格模式时,屏幕四周会闪烁红色,同时输出StrictMode的相关信息到LOGCAT日志中