Android应用耗电分析与优化

版权声明:本文为博主原创文章,转载请注明出处。 https://blog.csdn.net/w7849516230/article/details/52098672
应用的耗电是个长期持续优化的事情,而且随着Android系统的不断更新,系统本身也提供了越来越详细的信息来辅助统计分析耗电。这里基于Android 6.0介绍一些耗电分析与优化的思路及实践,一方面可以在现有应用的基础上直接使用,同时也可在后续的开发中注意和排查新功能可能带来的耗电问题。


本文总的思路是先介绍官方的和已有的耗电分析思路和经验,然后从统计、查找、分析并优化的步骤来作优化实践
1.官方的建议
1.1 电池续航时间优化(Optimizing Battery Life)

参考文章:优化电池使用时间
已有中文的详细说明,此处做简要说明:
(1)监控电池电量和充电状态(Monitoring the Battery Level and Charging State)
通过系统广播,获取充电状态和电池电量的变化来调整数据更新等操作;如在充电时,更新数据及应用,在低电量时,减少更新频率或停止gen
(2)确定和监控基座对接状态和类型(Determining and Monitoring the Docking State and Type)
和监控充电状态类似,通过系统广播,获取充电基座类型(车载基座、桌面基座),改变应用更新频率和方式
(3)确定和监控网络连接状态(Determining and Monitoring the Connectivity Status)
也和监控充电状态类似,根据当前连接网络的类型采取不同的策略。一般情况WiFi耗电要比移动数据流量低很多。监听CONNECTIVITY_CHANGE,可以在网络状态变化时调整策略
(4)根据需要操作广播接收器(Manipulating Broadcast Receivers On Demand)
主要说明可通过PackageManager的setComponentEnabledSetting方法来改变组件的启用与禁用。需要注意的是,此方法会导致应用的通知栏变化,不过系统会发送Intent.ACTION_PACKAGE_CHANGED广播,而且要留心这种变化的持续性,避免误认为广播接收器偶尔不正常。


1.2 数据传输中减少耗电
参考文章: Transferring Data Without Draining the Battery
此系列文章主要介绍与数据传输相关方面,减少电量消耗。首先,以3G数据网络状态机为例,说明无线射频在standby 、low power 、full power三种状态下的切换,一般减少频繁的网络连接,而延长在full power模式,获取更多数据,如采取预获取、合并获取数据等;另一方面,减少不必要的重连接和获取无用的数据;最后还是要区分在不同的网络类型下,采用不同的策略,考虑GPRS等网络实际的速度带宽等


1.3 针对 Doze和App Standby的优化
文章链接:Optimizing for Doze and App Standby
在Android6.0上引入了Doze和应用的Standby。在Doze模式下,应用的网络连接,CPU的使用都被严格控制,甚至唤醒锁(wake lock)和普通的Alarm也被忽略,但是会周期性地退出,使应用可以完成被推迟的工作,如下的官方经典图:


为了适配此种模式,一方面考虑其被延迟执行的影响(如心跳等),以及在后台,程序是否有必要执行某些操作,另一方面,它还是保留了setAlarmClock() 和提供setAndAllowWhileIdle() 和 setExactAndAllowWhileIdle(),但应考虑不同设备,应用实际唤醒间隔时间。在官方描述是不少于9分钟或者15分钟。


应用的Standby,主要是指系统判定用户不在使用应用时,推迟应用在后台的活动,包括网络访问、周期任务等;而判定的条件,排除此应用具有前台进程和具有通知栏。


然后都给出了测试方法,可以直接利用adb命令进入测试模式
(1)Doze
$ adb shell dumpsys battery unplug
$ adb shell dumpsys deviceidle step
第二条指令需要执行多次
 (2)Standby
$ adb shell dumpsys battery unplug
$ adb shell am set-inactive <packageName> true
退出此模式:
$ adb shell am set-inactive <packageName> false
$ adb shell am get-inactive <packageName>

最后说明的是进入Doze是有比较严格的条件的,官方说明是在屏幕关闭后,没有连接电源且没有活动一定时间后(如1小时),而且屏幕一旦开启或连接电源即退出Doze模式。同时系统也提供了白名单功能,如果觉得自己的应用进入Doze模式后,依然需要正常使用,可以通过ACTION_IGNORE_BATTERY_OPTIMIZATION_SETTINGS 引导用户将自己加白。然而厂商实际执行可能会有差别,如在华为手机上,屏幕关闭几分钟后,应用就已经被挂起;定制ROM比较严重的厂商,还会对屏幕关闭后,执行杀死进程,关闭网络等操作,都需要额外的考虑。细节不描述,因为这是保活的问题,具体可参考Android微信智能心跳方案和其它方案,但需要考虑对自身应用耗电的影响,比如心跳包无法发出,导致频繁重连接,导致频繁的证书交换(在此提及的原因是用https或者直接利用ssl,连接过程中验证服务端都会涉及到证书链的下载,而单个证书可能就有几K大小,证书链可能会到10K,特别是在数据网络下,频繁的连接带来的消耗非常大)等都是耗电耗流量大户。


2.其他经验
此处的经验是在电量统计的基础上得出的(后面会做些电量统计的说明)。耗电大户主要是设备唤醒、CPU和网络、传感器。
(1)设备唤醒单提出来说是因为通过Alarm可唤醒设备,而项目中不限制的滥用,导致系统被频繁唤醒;再加上不恰当的使用wake lock,没有释放wake lock,使得系统长时间无法进入休眠,势必导致高耗电,可参考(android设备休眠
 ( 2)CPU和网络耗电方面,主要是减少I/O操作(包括数据库操作),大量的计算;减少网络网络请求次数和数据量
(3)传感器:设备屏幕亮度、颜色背景等需要考虑,但除了阅读类等应用,一般是不太考虑屏幕消耗的。更多的是对GPS的使用注意,减少无用的GPS请求和及时关闭GPS搜索,比如室内是无法使用GPS完成定位的。


原来统计耗电都参考《深入浅出Android App耗电量统计》
工具如腾讯的GT值得推荐


3.统计、查找、分析并优化实践
此处的统计主要针对batterystats上进行。在Android5.0已经提供了adb shell dumpsys batterystats命令,而且在Android6.0上数据统计更详细。官方的文档Batterystats and Battery Historian Walkthrough,简单的测试步骤:
(1)插入手机
  $adb shell dumpsys batterystats --reset
(2)拔掉手机,开始测试
(3)$adb shell dumpsys batterystats > filename.txt 保存统计数据
然后可以下载并使用官方的python脚本生成html查看,也可以直接用文本文档查看。统计数据中包括了详尽的电量,wake lock,网络使用的统计,具体到UID及其中的进程。列出一部分微信的在自己手机中使用的数据,有删减:
  
u0a90:
  Mobile network: 908.38KB received, 144.94KB sent (packets 1063 received, 1219 sent)
  Mobile radio active: 5m 27s 337ms (31.9%) 15x @ 143 mspp
  Wi-Fi network: 3.52MB received, 454.37KB sent (packets 3628 received, 3645 sent)
  Wake lock WakerLock:180110109: 12s 444ms partial (52 times) realtime
  Wake lock *alarm*: 3s 362ms partial (24 times) realtime
    ...
  TOTAL wake: 59s 188ms partial realtime
  Foreground activities: 18m 37s 145ms realtime (32 times)
  Foreground for: 1h 49m 14s 993ms
  Total cpu time: u=3m 57s 240ms s=1m 4s 170ms p=0mAh
  Proc com.tencent.mm:tools:
  CPU: 1m 57s 260ms usr + 31s 570ms krn ; 0ms fg
  3 starts
  Proc com.tencent.mm:exdevice:
  CPU: 1s 290ms usr + 2s 590ms krn ; 0ms fg
  Proc com.tencent.mm:
  CPU: 1m 46s 610ms usr + 22s 920ms krn ; 4m 21s 940ms fg
  Proc com.tencent.mm:push:
  CPU: 7s 250ms usr + 5s 50ms krn ; 0ms fg
  Proc com.tencent.mm:sandbox:
  CPU: 0ms usr + 0ms krn ; 0ms fg
  1 starts
  Apk com.tencent.mm:
  Wakeup alarm *walarm*:ALARM_ACTION(7277): 22 times
  Wakeup alarm *walarm*:com.tencent.mm/.booter.MMReceivers$AlarmReceiver: 7 times
  Service com.tencent.mm.sandbox.updater.UpdaterService:
  Created for: 11s 53ms uptime
  Starts: 1, launches: 1
 ...
  Service com.tencent.mm.plugin.webview.stub.WebViewStubService:
  Created for: 0ms uptime
  Starts: 0, launches: 9

从上能够分析出微信在这段测试时间详细的网络消耗,包括移动网络和WiFi网络,CPU的使用,Alarm,以及Service的启动和运行时长等信息,基于此,再逐项排查和减少电量消耗。对于alarm的触发,网络的请求问题的定位从代码上能比较方便的搜索到,但是CPU的消耗,则需要通过Android提供的Profiling工具来实现,它会帮你定位出CPU的时间都消耗在哪个函数上。具体可参考Profiling with Traceview and dmtracedump,网络上有很多的使用教程。

简单附上统计的说明:

应用UID:u0a90

移动网络数据统计和时长统计

WiFi网络数据统计

Wake lock统计,包括通过alarm触发次数

应用前台页面信息

CPU使用统计,包括各个进程的使用信息

Servce信息


转载请注明出处:http://blog.csdn.net/w7849516230,欢迎关注微信公众号“编程阳光”

没有更多推荐了,返回首页