纯净后台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.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, 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的数据，若出现，则测试环境搭建错误，待机走的是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 lock唤醒时间即可,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中无此行数据,问题答疑,若无法定位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 battery符合测试时间，则此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 partial (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 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 *alarm* : 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则是半夜上厕所,纯净后台测试标准,