APP的噩梦——“XXX正在后台高耗电”
几个场景
场景一：查查资料，看个视频，突然提示我：微信正在后台高耗电！想想，微信嘛，高耗电太正常了，把通知一关，该干啥干啥。
场景二：支付宝付完款，放后台干别的，突然提示我：支付宝正在后台高耗电！想想，支付宝高耗电也正常，把进程一杀，该干啥干啥。
场景三：要去哪个地方，地图导航完，放后台。过段时间提示又来了：XX地图正在后台高耗电！杀掉进程，该干啥干啥。
场景四：刚用完哪个不知名小APP，放后台，刷完朋友圈放松一下。我擦，XXX正在高耗电，你谁啊就敢耗我的电池，找出来，卸载。
某不知名APP开发者哭晕在厕所……
高耗电的危害
很多APP都遇到过后台耗电的窘境，莫名其妙不知道发生了啥就被系统给黄牌警告。被提示耗电量高，会显著降低用户好感度，增加用户卸载率。一旦卸载，任凭你功能多牛叉，体验多优秀，一切玩完。
噩梦的源头——“Talk is cheap. Show me the code.”
要解决高耗电这一问题，得从源头来分析。APP耗电分哪些部分，各是怎么计算的，才好对症下药，远离系统的黄牌警告。
以android 25的代码为例，计算APP耗电量的核心代码是这个类——BatteryStatsHelper，接下来我们一步步来分析。
里面有啥？
我们来看一下这个类有哪些成员变量，这个类的成员变量不多，比较重要的有这些。
PowerCalculator mCpuPowerCalculator;
PowerCalculator mWakelockPowerCalculator;
MobileRadioPowerCalculator mMobileRadioPowerCalculator;
PowerCalculator mWifiPowerCalculator;
PowerCalculator mBluetoothPowerCalculator;
PowerCalculator mSensorPowerCalculator;
PowerCalculator mCameraPowerCalculator;
PowerCalculator mFlashlightPowerCalculator;
看这些变量名，是不是察觉到了什么？对，这是系统对于不同维度耗电量的计算工具。
private PowerProfile mPowerProfile;
这个是对系统整个耗电情况的一个描述，比如CPU各频段功耗、WIFI耗电情况、蓝牙耗电情况等。
private BatteryStats mStats;
这个成员提供了了对电源各项参数的访问接口，诸如各进程在cpu、wakelock等方面的详细耗电情况，可以将耗电情况细化到进程级别。
其余成员变量较多，不再一一赘述，有兴趣的可以查看一下源码。
耗电是咋计算的？
可以看到这个类对外提供了一系列的refreshStats()方法，跟进查看一下。
public void refreshStats(int statsType, SparseArray asUsers, long rawRealtimeUs, long rawUptimeUs) {
//初始化电源信息，各维度电量Calculator，以及时间参数
…………
//注意这个方法里会去详细计算各维度的耗电量
processAppUsage(asUsers);
//计算完成后各uid的排序，以及格式化等操作
…………
}
再看processAppUsage()方法
private void processAppUsage(SparseArray asUsers) {
…………
for(int iu =0;iu < NU; iu++) {
finalUid u = uidStats.valueAt(iu);
finalBatterySipper app =newBatterySipper(BatterySipper.DrainType.APP,u,0);
mCpuPowerCalculator.calculateApp(app,u,mRawRealtimeUs,mRawUptimeUs,mStatsType);
mWakelockPowerCalculator.calculateApp(app,u,mRawRealtimeUs,mRawUptimeUs,mStatsType);
mMobileRadioPowerCalculator.calculateApp(app,u,mRawRealtimeUs,mRawUptimeUs,mStatsType);
mWifiPowerCalculator.calculateApp(app,u,mRawRealtimeUs,mRawUptimeUs,mStatsType);
mBluetoothPowerCalculator.calculateApp(app,u,mRawRealtimeUs,mRawUptimeUs,mStatsType);
mSensorPowerCalculator.calculateApp(app,u,mRawRealtimeUs,mRawUptimeUs,mStatsType);
mCameraPowerCalculator.calculateApp(app,u,mRawRealtimeUs,mRawUptimeUs,mStatsType);
mFlashlightPowerCalculator.calculateApp(app,u,mRawRealtimeUs,mRawUptimeUs,mStatsType);
…………
}
…………
}
可以看到，这里针对每个uid，都计算了CPU/wakelock/移动数据/WIFI数据/蓝牙/传感器/摄像头/闪光灯八个维度的详细电量信息，并做了排序。
水落石出
看到这里，一切就清楚了。APP耗电高，一定是这八个维度的某一方面消耗了大量电量。
（这里仅分析了APP耗电量的来源，具体的计算方法有兴趣的读者可以自行查看源码）
捻手搭脉，对症下药
CPU耗电
CPU耗电主要分为以下几个场景
进程被频繁拉起
大多数场景是存在不恰当的静态广播注册，导致进程不断被广播拉起，产生一系列的初始化操作，不久又被ROM的省电策略所清理，大量初始化不仅会造成大量CPU耗电，还有可能被ROM记录为频繁自启甚至提示用户，降低用户好感度。
不恰当的对外提供的ContentProvider与Service也存在这个问题。
如何定位：不同厂商的ROM有不同的启动日志，观察APP的启动情况以及启动原因。
解决办法：分析梳理上述场景，并根据实际业务情况做清理与优化。
高CPU占用率
由于CPU耗电分为多个不同的等级，低占用率耗电量比高占用率要低很多。而在一些业务场景中，会存在非常高的CPU占用，比如大量IO/快速循环等，会产生很高的耗电。
如何定位：利用top命令查看当前包名下所有线程的CPU占用率，找出占用率很高的线程，分析这个线程在做什么。
解决办法：根据实际业务场景做优化（利用缓存机制减少IO的次数，快速循环里增加延时，或者直接重构等）。
低CPU占用率
这个场景比较复杂，比如有的动画机制是基于循环Handler的Message，导致每隔一小段时间就会有CPU活动，久而久之也是不小的耗电量。
如何定位：这种场景下CPU占用率比较低，无法直接找出对应线程。可采用MAT内存分析工具，查看当前内存内是否存在可疑的东西，比如大量堆积的Message等。
解决办法：按照实际问题与业务场景来做优化。
移动数据&WIFI耗电
这两个统称流量耗电，耗电场景如下：
图片/视频加载
这是最常见的耗电场景，但是没有什么特别好的办法来解决，如果图片是由自身服务器配置的话，可以通过优化图片大小来减少流量消耗。另外WIFI耗电是小于移动数据耗电的，大的图片可以考虑在WIFI网络下去加载。
服务器网络请求
这种场景需要查看与服务器请求的时机是否不合理，或者过多，服务器返回的消息内容是否过长，并做相应优化。
其他耗电场景
其他的场景视各业务实际场景而定，整体思路是优化耗电动作的时机，减少耗电动作的次数。
从噩梦中醒来——“后记”
负责项目功耗专项也有大半年了，一开始手足无措，后来慢慢理清思路，开始钻研源码，把耗电算法理解透。最后再分析代码，从CPU/流量维度讨论出了优化方案，并最终修改解决。
最大的收获是在源码面前，一切BUG都无所遁形。
关于耗电量的算法，这位仁兄研究要比我透彻得多，参考
