Skip to main content

Bugly电量监控使用教程

一、功能简介

不同于PC等插着电使用的场景,像移动终端、笔记本等都会比较在乎设备的续航能力,而与续航直接相关的则是各种硬件,比如说CPU、GPU、屏幕以及各种外设等等,每个硬件是有额定的功率的,当应用使用这个硬件的时候,应用的功耗可以近似于这个硬件的功耗开销。所以要想估算一个应用的耗电情况,我们至少需要知道两个数据:

  • 生命周期里面使用了哪些硬件;
  • 硬件的使用频率和累计时长;

每个硬件的耗电量是不一样的,有大有小,太小的耗电,用户一般不会关注到,另外正常的耗电,例如前台使用相机时的耗电,用户是有预期的,所以更需要监控的是异常的耗电行为,Bugly目前是基于这两个点来建设电量监控功能。

a) 监控耗电量大的硬件;

例如 CPU、WiFi、移动网络、GPS、WakeLock、Alarm等,这里也不仅仅只是考虑它们的耗电量大小,也考虑了程序员编码容易出错的行为,因为像Camera相机,虽然它的耗电更大,但是一般使用它的时候,用户都能感知到,所以一般在开发阶段也都能发现并解决。 另外有些硬件的使用,我们也没手段去监控,例如内存访问、Bus总线,还有一些sensor传感器等,暂时也没有放到我们的监控范围。

b) 监控异常耗电行为;

例如10分钟内,频繁的请求刷新GPS、 长时间的获取WakeLock导致CPU无法休眠等异常情况; Bugly的电量监控目前提供如下功能:

1、前台耗电指标,监控和统计进程在前台状态时整机的电流值和电池温度。

2、耗电因素指标,监控和统计进程生命周期里面耗电硬件的使用频率以及使用时长信息。

3、耗电因素异常个例,固定周期内,如果硬件使用的次数或者时长超过某个阈值,则会被认为是异常个例,针对异常个例,Bugly会提供堆栈以及每次开启的时间以及持续时长等信息来供下钻分析。

二、SDK接入

Bugly电量监控目前只有Android平台支持,同时需要升级SDK到4.4.2之后的版本,Bugly的各项监控功能一般采用客户端和后台配置共同控制的方式,也就是说客户端必须要调用如下的RMonitor.startMonitor语句,同时后台设置采样率值,这个功能才会真正开启。

2.1、 开启方式

专业版默认开启,只要配置一下相应的采样率就可以了;

2.2、开启成功的日志

如上所述,电量监控是通过客户端执行startMonitors语句和后台采样率配合才会最终开启,开启成功之后,如果Bugly设置的日志级别是I级别以上,会有如下日志输出,如果没有该日志,可以先查看客户端是否有调用startMonitors语句以及后台的配置是否成功拉取到。

Logger.INSTANCE.i(TAG, "start battery metric plugin");  // 前台耗电指标

Logger.INSTANCE.i(TAG, "start battery element metric plugin"); // 耗电因素指标

Logger.INSTANCE.i(TAG, "start battery element plugin"); // 耗电因素异常个例

2.3、上报日志

1、前台耗电指标上报日志(重启进程等5分钟上报)
04-22 01:04:26.665 17704 17758 D RMonitor_report_Json: url: ***************** eventName: battery_metric, client_identify: 86316415c412a9ed43cd0f43d601ff3f


2、耗电元素指标上报日志(重启进程等5分钟上报)
04-22 01:04:26.665 17704 17758 D RMonitor_report_Json: url: ***************** eventName: battery_ele_metric, client_identify: 96316415c412a9ed43cd0f43d601ff3f

3、耗电因素异常个例上报(如果有异常,每10分钟上报一次)
04-22 01:04:26.665 17704 17758 D RMonitor_report_Json: url: ***************** eventName: BatteryElement, client_identify: 76316415c412a9ed43cd0f43d601ff3f

三、功能使用

3.1、前台耗电指标

前台耗电指标这个功能,统计数据的时候,Bugly自动会过滤掉一些场景:

  • 应用位于后台;
  • 移动设备处于充电状态;
  • 移动设备处于满格电量状态;

同时该指标统计的是统计的进程生命周期,所以是在进程重启之后才会上报,前台耗电指标主要用来从大盘衡量前台使用应用的时候用户的“体感”, 是否有过热以及掉电严重的问题,支持查看平均值以及各个分位值,同时也支持多维分析,查看不同版本、不同机型、不同系统版本的指标分位值。

3.2、耗电因素指标

耗电因素指标统计的是进程整个生命周期里面硬件的使用情况,主要统计 “CPU Time”、“定位”、“Alarm”、“WakeLock”、“进程使用时长” 等信息,例如进程生命周期里面,使用了多少次WakeLock,累积使用时长等。

CPU使用率 = 统计周期内进程CPU Time /  统计周期内整机CPU Time

耗电因素指标除了查看不同指标的分位值之外,还可以查看不同设备ID的上报详情信息,点击“查看详情”,可以跳转到高级搜索页面

在高级搜索页面能查看这台设备在选定周期内发生的所有事件,例如所有的耗电因素异常个例的上报、启动事件、卡顿等事件的上报也会包含。

3.3、耗电因素异常个例

无论是前台耗电指标还是耗电因素指标,都是从大盘数据来衡量问题的严重程度,但是缺少下钻分析信息,而耗电因素异常个例更侧重于下钻分析的角度,从异常个例,我们可以直观的了解到这次异常耗电的函数调用堆栈以及使用时长等信息,Bugly目前可以监控如下的异常类型

异常类型说明
定位单次使用最长时长定位单次使用多久当作异常上报,单位为秒。
定位10分钟内获取次数10分钟内使用几次定位当作异常上报。
定位10分钟内查询时长10分钟内使用定位多久当作异常,上报单位为秒。
wake lock单次持有时长wake lock 单次持有多久当作异常上报。单位为秒。
wake lock 10分钟内获取次数wake lock 10分钟内获取几次当作异常上报。
wake lock 10分钟内持有时长wake lock 10分钟内持有多久当作异常上报。单位为秒。
wake_up类型 Alarm 10分钟内唤醒次数Alarm(wake_up类型)10分钟内唤醒几次当作异常上报。
其他类型Alarm 10分钟内唤醒次数Alarm10分钟内唤醒几次当作异常上报。

耗电因素主要包括以下两种异常:

一种是单次超过阈值;
一种是统计周期内,累计超过阈值,累计超过阈值又包含累计次数和累计时长;

四、配置指南

电量监控这个功能后台配置默认是关闭的,所以即使客户端调用了startMonitors也还是无法开启的,需要在产品的配置页面新建或者添加配置项,接入调试阶段,建议sample_ratio都配置为1,也就是全开启。

配置项含义默认值
sample_ratio采样率: 0代表关闭, 1代表全开0
daily_report_limit当天上报量上限值,超过这个上限值,当天无法再开启该功能1000
single_location_duration_in_ms单次使用GPS最大时长,单位ms120000
total_location_duration_in_ms10分钟内总的更新GPS时长,单位ms240000
max_location_open_num10分钟内打开GPS的最大次数4
single_wakelock_duration_in_ms单次使用WakeLock的最大时长,单位ms5000
total_wakelock_duration_in_ms10分钟内总的使用WakeLock最大时长,单位ms120000
max_wakelock_open_num10分钟内打开WakeLock的最大次数240
max_alarm_open_num10分钟内打开alarm的最大次数10
max_wakeup_alarm_open_num10分钟内打开wakeup 类型的alarm的最大次数5