纯净后台log分析

上传人:jiups****uk12 文档编号:56878825 上传时间:2018-10-16 格式:PPTX 页数:15 大小:958.59KB
返回 下载 相关 举报
纯净后台log分析_第1页
第1页 / 共15页
纯净后台log分析_第2页
第2页 / 共15页
纯净后台log分析_第3页
第3页 / 共15页
纯净后台log分析_第4页
第4页 / 共15页
纯净后台log分析_第5页
第5页 / 共15页
点击查看更多>>
资源描述

《纯净后台log分析》由会员分享,可在线阅读,更多相关《纯净后台log分析(15页珍藏版)》请在金锄头文库上搜索。

1、纯净后台log分析,1.LogReport如何找出有效log 2.Log名词解释 3.纯净后台测试标准,LogReport,1.应用商店搜索并安装LogReport工具 (PS:第一步建议测试前完成) 2.打开并点击“一键抓取LOG”按钮 3.手机连接电脑,打开“内部存储设备Androidlog”目录,将log取出 4.解压打开log文件 新版logreport工具的batterystatslog在dumpsys文件夹下的dumpsys_batterystats中,搜索对应APP包名,以天气为例,定位至Apk com.meizu.flyme.weather 若无法定位Apk,则Proc com

2、.meizu.flyme.weather亦可,Log名词解释,Wi-Fi network: 85.88KB received, 49.61KB sent (packets 293 received, 470 sent) Wi-Fi 网络数据使用情况:接受数据量,发送数据量,对应包数 标准中监控数据为:接受数据量+发送数据量,即 85.88 + 49.61 KB,Wifi Scan: 51m 12s 981ms (5.5%) 479x Wifi扫描时间,若应用未调用wifi scan则不会出现该数据 非标准监控项,Log名词解释,Mobile network: 27.44KB received,

3、 29.84KB sent (packets 279 received, 430 sent) Mobile 网络数据使用情况:接受数据量,发送数据量,对应包数 标准中监控数据为:接受数据量+发送数据量,即 27.44 + 29.84 KB,Mobile radio active: 1h 23m 52s 154ms (19.2%) 59x 7098 mspp Mobile 网络数据使用时间 标准中监控数据为:时间,即1h 23m 52s(毫秒级4舍5入至秒级),注意:wifi测试场景中由于飞行模式下所以不会出现mobile的两个数据 同理,modem测试场景中关闭wifi故不会出现wifi的数据

4、,若出现,则测试环境搭建错误,待机走的是wifi通道,modem测试案例需重测,Log名词解释,Wake lock LocationManagerService realtime Wake lock *alarm*: 2s 780ms partial (136 times) realtime TOTAL wake: 2s 780ms partial realtime wakelock唤醒源:唤醒时间(唤醒次数) 总wakelock时间 标准中监控数据为:时间,即TOTAL wake后的3s(ms级4舍5入至s) 若无Total wake参数,说明仅有一个wake lock,记录该wake lo

5、ck唤醒时间即可,Total cpu time: u=44s 585ms s=22s 935ms p=0mAh CPU总使用时间 标准监控数据为:u + s,即 44585 + 22935ms(秒级以上时间换算为毫秒级) 若无Total参数,说明仅有一个proc,记录该proc cpu time即可,Log名词解释,Apk com.meizu.mzsyncservice: Wakeup alarm *walarm*:com.meizu.flyme.alarmsync.name: 1 times Alarm次数 标准监控数据为:次数,即1 times 若应用待机中未出现alarm,则log中无此

6、行数据,问题答疑,若无法定位Apk或者Proc + 包名,怎么确认这份log是有效? 答:在log中定位Statistics since last charge: 查看Time on battery记录时间是否符合测试时间 亮屏后台测试,Time on battery:时间应大于等于5小时 灭屏待机测试,Time on battery:时间应大于等于10小时 若出现Time on battery时间明显小于测试时间(经常碰到的是电池时间为1分钟左右),则说明本次测试无效,点击抓取log时batterystatslog已被人为清理 人为清理可能性:抓log前高电量接入usb 若Time on b

7、attery符合测试时间,则此log有效,无法定位至Apk或Proc则因为该应用在待机过程中未出现任何唤醒、cpu使用等,所有数据均为0,问题答疑,应用耗电详情log必定以u0a开头,如下: u0a32: Wi-Fi network: 4.10KB received, 3.24KB sent (packets 18 received, 16 sent) Wifi Scan: 0ms (0.0%) 0x Wake lock *alarm*: 58ms partial (15 times) realtime Wake lock mywakelock: 12h 28m 22s 84ms partia

8、l (0 times) realtime TOTAL wake: 12h 28m 22s 142ms partial realtime Active for: 12h 29m 42s 992ms Total cpu time: u=13m 7s 817ms s=13m 45s 267ms p=0mAh Proc com.meizu.media.video: CPU: 19s 310ms usr + 17s 580ms krn ; 0ms fg 而不是 Proc com.android.systemui: CPU: 16s 230ms usr + 5s 470ms krn ; 280ms fg

9、Proc com.flyme.systemuitools: CPU: 680ms usr + 180ms krn ; 0ms fg u0a32: Wi-Fi network: 4.10KB received, 3.24KB sent (packets 18 received, 16 sent) Wifi Scan: 0ms (0.0%) 0x Wake lock *alarm*: 58ms partial (15 times) realtime 请注意缩进代表的意义,问题答疑,在应用log中搜索alarm时出现两个alarm,记录哪个的次数? 如: u0a31: Wake lock *alar

10、m* : 463ms full (1 times) realtime Total cpu time: u=19s 760ms s=10s 300ms p=0mAh Apk com.meizu.xxx Wakeup alarm *walarm*:com.meizu.xxx: 20 times 答: 在如上应用详情中会看到有两个alarm 第一个属于wakelock,只是这个名字叫*alarm* 第二个才是alarm Wakelock和alarm的区别在于:应用根据工作状态不同,会选择不一样的方式去唤醒系统。例如需要做一下数据同步,应用在执行同步的时候不希望系统休眠,所以一般会申请wakelock锁,在同步完了之后释放掉,这个过程时间可以很长。 而应用想跟服务器保持个握手,这个时候时间很短呐,而且需要定时,例如说应用现在想在16:00的时候去做,就可以申请alarm去进行定时短唤醒了 抽象点,wakelock可以理解成通宵打麻将,而alarm则是半夜上厕所,纯净后台测试标准,

展开阅读全文
相关资源
相关搜索

当前位置:首页 > 行业资料 > 其它行业文档

电脑版 |金锄头文库版权所有
经营许可证:蜀ICP备13022795号 | 川公网安备 51140202000112号