这篇文章中简绍Android的耗电原理，以及飞书的耗电治理规划。
Android耗电统计原理
我们先了解一下Android系统是如何进行耗电的统计的，最精确的方式当然是使用电流仪来进行统计，但是正常状态下手机硬件不支持，所以系统统计耗电时，使用的基本是模块功率✖️模块耗时这个公式来进行的，但不同的模块还是会有一些差别。这种统计方式没法做到非常的精确，但是也基本能反应出各应用电量的消耗大小。
模块功率
我们先来看看模块功率，每个模块的耗电功率都是不一样的，以计算方式来分，又分为下面三类
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-CGHVVadX-1669622450015)(https://upload-images.jianshu.io/upload_images/25149744-3339ca88cb4c9d83.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)]
第一类是Camera、FlashLight、MediaPlayer等一般传感器或设备的模块的模块。其工作功率基本和额定功率保持一致，所以模块电量的计算只需要统计模块的使用时长再乘以额定功率即可。
第二类是Wifi、Mobile、BlueTooth这类数据模块。其工作功率可以分为不同的档位，比如，当手机的 Wifi 信号比较弱的时候，Wifi 模块就必须工作在比较高的功率档位以维持数据链路，所以这类模块的电量计算有点类似于我们日常的电费计算，需要 “阶梯计费”。
第三类是屏幕，CPU模块。CPU 模块除了每一个CPU Core 需要像数据模块那样阶梯计算电量之外，CPU 的每一个集群（Cluster，一般一个集群包含一个或多个规格相同的 Core）也有额外的耗电，此外整个 CPU 处理器芯片也有功耗。简单计算的话，CPU 电量 = SUM (各核心功耗) + 各集群（Cluster）功耗 + 芯片功耗 。屏幕模块的电量计算就更麻烦了，很难把屏幕功耗合理地分配给各个 App， 因此 Android 系统只是简单地计算 App 屏幕锁（WakeLock）的持有时长，按固定系数增加 App CPU 的统计时长，粗略地把屏幕功耗算进 CPU 里面。
每个模块的功耗大小位于framework的power_profile.xml文件中，由厂商自己提供，里面规定了每个模块的功耗，下面是一台一加9的测试机的power_profile文件
通过apktook反解出来的power_profile如下
文件中每个模块的对应说明，可以在谷歌提供的文档中看到详细的说明。
source.android.com/devices/tec…
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-tQd0vUVB-1669622450023)(https://upload-images.jianshu.io/upload_images/25149744-cc95805a25b402a6.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)]
模块耗时
了解了模块的功率，我们再来看看模块耗时，耗电模块在工作或者状态变更时，都会通知batterystats这个service，而BatteryStatsService会调用BatteryStats对象进行耗时的统计，BatteryStats的构造函数中会初始化各个模块的Timer，用来进行耗时的统计，并将统计的数据存储在batterystats.bin文件中。
BatteryStatsImpl.java
我们来详细看看下面几个模块的是如何进统计的，
wifi模块
public void noteWifiOnLocked() {
if (!mWifiOn) {
final long elapsedRealtime = mClocks.elapsedRealtime();
final long uptime = mClocks.uptimeMillis();
mHistoryCur.states2 |= HistoryItem.STATE2_WIFI_ON_FLAG;
addHistoryRecordLocked(elapsedRealtime, uptime);
mWifiOn = true;
mWifiOnTimer.startRunningLocked(elapsedRealtime);
scheduleSyncExternalStatsLocked("wifi-off", ExternalStatsSync.UPDATE_WIFI);
}
}
public void noteWifiOffLocked() {
final long elapsedRealtime = mClocks.elapsedRealtime();
final long uptime = mClocks.uptimeMillis();
if (mWifiOn) {
mHistoryCur.states2 &= ~HistoryItem.STATE2_WIFI_ON_FLAG;
addHistoryRecordLocked(elapsedRealtime, uptime);
mWifiOn = false;
mWifiOnTimer.stopRunningLocked(elapsedRealtime);
scheduleSyncExternalStatsLocked("wifi-on", ExternalStatsSync.UPDATE_WIFI);
}
}
Audio模块
public void noteAudioOnLocked(int uid) {
uid = mapUid(uid);
final long elapsedRealtime = mClocks.elapsedRealtime();
final long uptime = mClocks.uptimeMillis();
if (mAudioOnNesting == 0) {
mHistoryCur.states |= HistoryItem.STATE_AUDIO_ON_FLAG;
if (DEBUG_HISTORY) Slog.v(TAG, "Audio on to: "
+ Integer.toHexString(mHistoryCur.states));
addHistoryRecordLocked(elapsedRealtime, uptime);
mAudioOnTimer.startRunningLocked(elapsedRealtime);
}
mAudioOnNesting++;
getUidStatsLocked(uid).noteAudioTurnedOnLocked(elapsedRealtime);
}
public void noteAudioOffLocked(int uid) {
if (mAudioOnNesting == 0) {
return;
}
uid = mapUid(uid);
final long elapsedRealtime = mClocks.elapsedRealtime();
final long uptime = mClocks.uptimeMillis();
if (--mAudioOnNesting == 0) {
mHistoryCur.states &= ~HistoryItem.STATE_AUDIO_ON_FLAG;
if (DEBUG_HISTORY) Slog.v(TAG, "Audio off to: "
+ Integer.toHexString(mHistoryCur.states));
addHistoryRecordLocked(elapsedRealtime, uptime);
mAudioOnTimer.stopRunningLocked(elapsedRealtime);
}
getUidStatsLocked(uid).noteAudioTurnedOffLocked(elapsedRealtime);
}
Activity状态改变
public void noteActivityResumedLocked(int uid) {
uid = mapUid(uid);
getUidStatsLocked(uid).noteActivityResumedLocked(mClocks.elapsedRealtime());
}
public void noteActivityPausedLocked(int uid) {
uid = mapUid(uid);
getUidStatsLocked(uid).noteActivityPausedLocked(mClocks.elapsedRealtime());
}
public static class Uid extends BatteryStats.Uid {
@Override
public void noteActivityPausedLocked(long elapsedRealtimeMs) {
if (mForegroundActivityTimer != null) {
mForegroundActivityTimer.stopRunningLocked(elapsedRealtimeMs);
}
}
@Override
public void noteActivityPausedLocked(long elapsedRealtimeMs) {
if (mForegroundActivityTimer != null) {
mForegroundActivityTimer.stopRunningLocked(elapsedRealtimeMs);
}
}
}
通过上面三个例子可以看到，BatteryStats在统计模块耗时，主要通过Timer来进行时长的统计，如WifiOnTimer、AudioOnTimer、ForegroundActivityTimer，并且根据是否有UID来决定是否要统计到UID对应的数据中，系统在统计应用的耗电时，就是根据UID下各个模块的统计数据，来进行应用的耗电计算的。
耗电计算
当我们知道了每个模块的耗时，每个模块的功耗，那么就能计算各个模块的耗电量了，耗电量的计算在BatteryStatsHelper这个类中，下面详细看一下Setting中，应用耗电详情这个功能统计耗电的实现，Setting中的耗电统计这个应用主要是调用了BatteryStatsHelper中的refreshStats() 函数
refreshStats主要两个方法是processappUsage计算应用的耗电，记忆processMiscUsage计算杂项耗电，如WIFI，通话等等
计算app的电量
这里以CameraPowerCalculator这个简单的模块看看它是如何统计电量的
CameraPowerCalculator.java
可以看到，里面只是简单的用了totalTime * mCameraPowerOnAvg，mCameraPowerOnAvg则是从power_profile.xml读取出来，其他教负责的如CPU模块的计算，感兴趣的可以自己看看，就不在这里说了。
计算misc杂项的电量
杂项电量用来统计一些没有特定UID的耗电，如蓝牙，屏幕等等，计算方式也是类似的。
Android的耗电优化策略
Doze模式
Doze模式也被称为低电耗模式，是针对整个系统进行一个耗电优化策略，进入Doze模式后会暂停所有的Jobs，Alarm和Network活动并推迟到窗口期执行，以及其他的一些限制来节约电量。
Doze模式的进入和退出
Doze模式分为Deep Doze和Light Doze两种模式，Doze模式是在Android6.0引入的，也就是Deep Doze模式，Light Doze是Android7.0引入的，两者进入的条件不一样，Deep Doze的条件会更严格，下面先介绍Deep Doze
Deep Doze
系统处于息屏状态，并且30分钟不移动的情况下，就会进入到Deep Doze模式，Deep Doze机制中有七种状态，分别如下
//mState值，表示设备处于活动状态
private static final int STATE_ACTIVE = 0;
//mState值，表示设备处于不交互状态,灭屏、静止
private static final int STATE_INACTIVE = 1;
//mState值，表示设备刚结束不交互状态,等待进入IDLE状态
private static final int STATE_IDLE_PENDING = 2;
//mState值，表示设备正在感应动作
private static final int STATE_SENSING = 3;
//mState值，表示设备正在定位
private static final int STATE_LOCATING = 4;
//mState值，表示设备处于空闲状态,也即Doze模式
private static final int STATE_IDLE = 5;
//mState值，表示设备正处于Doze模式，紧接着退出Doze进入维护状态
private static final int STATE_IDLE_MAINTENANCE = 6;
这七种状态的转换关系如下
根据上图，他们的关系总结如下
当设备亮屏或者处于正常使用状态时其就为ACTIVE状态；
ACTIVE状态下不充电且灭屏设备就会切换到INACTIVE状态；
INACTIVE状态经过30分钟，期间检测没有打断状态的行为Doze就切换到IDLE_PENDING的状态；
然后再经过30分钟以及一系列的判断，状态切换到SENSING；
在SENSING状态下会去检测是否有地理位置变化，没有的话就切到LOCATION状态；
LOCATION状态下再经过30s的检测时间之后就进入了Doze的核心状态IDLE；
在IDLE模式下每隔一段时间就会进入一次IDLE_MAINTANCE，此间用来处理之前被挂起的一些任务，这个时间段为一个小时，两个小时，四个小时，最后稳定为最长为六个小时
IDLE_MAINTANCE状态持续5分钟之后会重新回到IDLE状态；
在除ACTIVE以外的所有状态中，检测到打断的行为如亮屏、插入充电器，位置的改变等状态就会回到ACTIVE，重新开始下一个轮回。
Light Doze
从上面可以看到想要进入Doze模式的条件是很苛刻，需要在手机息屏并且没有移动的状态下才能进入，所以Android7.0开始引入了Light Doze，处于息屏状态，但仍处于移动状态可进入Light Doze，LightDoze有7个状态，分别如下：
//mLightState状态值，表示设备处于活动状态
private static final int LIGHT_STATE_ACTIVE = 0;
//mLightState状态值，表示设备处于不活动状态
private static final int LIGHT_STATE_INACTIVE = 1;
//mLightState状态值，表示设备进入空闲状态前，需要等待完成必要操作
private static final int LIGHT_STATE_PRE_IDLE = 3;
//mLightState状态值，表示设备处于空闲状态，该状态内将进行优化
private static final int LIGHT_STATE_IDLE = 4;
//mLightState状态值，表示设备处于空闲状态,要进入维护状态，先等待网络连接
private static final int LIGHT_STATE_WAITING_FOR_NETWORK = 5;
//mLightState状态值，表示设备处于维护状态
private static final int LIGHT_STATE_IDLE_MAINTENANCE = 6;
这个6个状态的转换关系如下
根据上图，他们的转换关系总结如下
当设备亮屏或者处于正常使用状态时其就为ACTIVE状态；
ACTIVE状态下不充电且灭屏设备就会切换到INACTIVE状态；
INACTIVE状态经过3分钟，期间检测没有打断状态的行为就切换到PRE_IDLE的状态；
PRE_IDLE状态经过5分钟，期间无打断就进入到IDLE状态
进入IDLE状态会根据是否有网络连接选择进入WAITING_FOR_NETWORK还是进入MAINTENANCE窗口期，进入窗口期的时间为：5分钟，10分钟，最后稳定最长为15分钟
进入WAITING_FOR_NETWORK会持续5分钟后重新进入到IDLE状态
进入MAINTENANCE会解除耗电策略的限制，并在1分钟后重新进入到IDLE状态
Doze模式的优化策略
了解了Doze模式的进入和退出策略，我们再来看一下在Doze模式中，会做哪些策略来优化耗电
Deep Doze
当系统处于Doze模式下，系统和白名单之外的应用将受到以下限制：
无法访问网络
Wake Locks被忽略
AlarmManager闹铃会被推迟到下一个maintenance window响应
使用setAndAllowWhileIdle或SetExactAndAllowWhileIdle设置闹铃的闹钟则不会受到Doze模式的影响setAlarmClock设置的闹铃在Doze模式下仍然生效，但系统会在闹铃生效前退出Doze 系统不执行Wi-Fi/GPS扫描；
系统不允许同步适配器运行；
系统不允许JobScheduler运行；
Deep Doze也提供了白名单，位于白名单中的应用可以：
继续使用网络并保留部分wake lock
Job和同步仍然会被推迟
常规的AlarmManager闹铃也不会被触发
Light Doze
Light Doze的限制没有Deep Doze这么严格，主要有下面几种
不允许进行网络访问
不允许同步适配器运行
不允许JobScheduler运行
Deep Doze和Light Doze的总结对比如下：
Deep Doze和Light Doze都需要达到一定条件后才能进入，并且进入后会定期提供窗口期来解除限制。
他们的对比如下
操作Deep DozeLight Doze触发因素屏幕关闭，无充电，静止屏幕关闭，无充电维持时间不断增长，最长为6个小时不断增长，最长为15分钟限制无法进行网络访问，唤醒锁忽略，GPS/WIFI/蓝牙等无法扫描，闹钟/SyncAdapter/JobScheduler推迟无法进行网络访问，SyncAdapter/JobScheduler推迟退出设备移动，和用户有交互，屏幕开启屏幕开启
Doze模式实现原理
前面已经了解了Doze模式了，下面就在通过Android中的Doze机制的源码，深入了解Doze的实现原理。Doze机制相关的源码都在DeviceIdleController这个类中
DeviceIdleController.java
进入INACTIVE状态
从ACTIVIE进入到INACTIVE的入口方法是becomeInactiveIfAppropriateLocked中，当充电状态发生改变，屏幕息屏等条件触发时，都会调用该方法判断是否可进入INACTIVE状态。
//deep doze进入INACTIVE后的延时时间，这里的COMPRESS_TIME默认为false
long inactiveTimeoutDefault = (mSmallBatteryDevice ? 15 : 30) * 60 * 1000L;
INACTIVE_TIMEOUT = mParser.getDurationMillis(KEY_INACTIVE_TIMEOUT,
!COMPRESS_TIME ? inactiveTimeoutDefault : (inactiveTimeoutDefault / 10));
LIGHT_IDLE_AFTER_INACTIVE_TIMEOUT = mParser.getDurationMillis(
KEY_LIGHT_IDLE_AFTER_INACTIVE_TIMEOUT,
!COMPRESS_TIME ? 3 * 60 * 1000L : 15 * 1000L);
void becomeInactiveIfAppropriateLocked() {
final boolean isScreenBlockingInactive =
mScreenOn && (!mConstants.WAIT_FOR_UNLOCK || !mScreenLocked);
//判断是否是灭屏且非充电状态
if (!mForceIdle && (mCharging || isScreenBlockingInactive)) {
return;
}
if (mDeepEnabled) {
if (mQuickDozeActivated) {
//1\. QuickDoze是Android 10新引入的低电量的情况下，快速进入Doze的机制，会缩短进入Doze的耗时
if (mState == STATE_QUICK_DOZE_DELAY || mState == STATE_IDLE
|| mState == STATE_IDLE_MAINTENANCE) {
return;
}
mState = STATE_QUICK_DOZE_DELAY;
resetIdleManagementLocked();
scheduleAlarmLocked(mConstants.QUICK_DOZE_DELAY_TIMEOUT, false);
EventLogTags.writeDeviceIdle(mState, "no activity");
} else if (mState == STATE_ACTIVE) {
mState = STATE_INACTIVE;
resetIdleManagementLocked();
long delay = mInactiveTimeout;
if (shouldUseIdleTimeoutFactorLocked()) {
delay = (long) (mPreIdleFactor * delay);
}
//2\. 执行时间为mInactiveTimeout延时的任务，这里是30分钟
scheduleAlarmLocked(delay, false);
EventLogTags.writeDeviceIdle(mState, "no activity");
}
}
if (mLightState == LIGHT_STATE_ACTIVE && mLightEnabled) {
mLightState = LIGHT_STATE_INACTIVE;
resetLightIdleManagementLocked();
//3\. 执行时间为LIGHT_IDLE_AFTER_INACTIVE_TIMEOUT延时的任务，这里是3分钟
scheduleLightAlarmLocked(mConstants.LIGHT_IDLE_AFTER_INACTIVE_TIMEOUT);
EventLogTags.writeDeviceIdleLight(mLightState, "no activity");
}
}
从源码中可以看到Deep Doze，Light Doze的处理都在这里，并且这里还有一个Quick Doze，它是Android 10引入，能在低电量情况下快速进入Doze的机制。
我们接着看INACTIVE向下一个状态的改变
Deep Doze通过scheduleAlarmLocked(delay, false)向下一个状态转变，在这个时间过程中，有开屏，充电等操作，都会导致状态转换失败
Light Doze通过scheduleLightAlarmLocked(mConstants.LIGHT_IDLE_AFTER_INACTIVE_TIMEOUT)向下一个状态改变，同样在开屏和充电状态下，都会导致进入下一个状态失败
从INACTIVE状态开始，Light Doze和Deep Doze转换的入口就不一样了，所以下面会分开讲解
Deep Doze
1. 从INACTIVE进入STATE_IDLE_PENDING
becomeInactiveIfAppropriateLocked函数中将mState设置为STATE_INACTIVE，然后调用scheduleAlarmLocked设置了一个30分钟的定时任务，它的逻辑实现如下。
void scheduleAlarmLocked(long delay, boolean idleUntil) {
if (mMotionSensor == null) {
//如果没有运动传感器，则返回，因为无法判断设备是否保持静止
if (mMotionSensor == nullr) {
return;
}
//设置DeepDoze的定时Alarm
mNextAlarmTime = SystemClock.elapsedRealtime() + delay;
if (idleUntil) {
mAlarmManager.setIdleUntil(AlarmManager.ELAPSED_REALTIME_WAKEUP,
mNextAlarmTime, "DeviceIdleController.deep",
mDeepAlarmListener, mHandler);
} else {
mAlarmManager.set(AlarmManager.ELAPSED_REALTIME_WAKEUP,
mNextAlarmTime, "DeviceIdleController.deep",
mDeepAlarmListener, mHandler);
}
}
private final AlarmManager.OnAlarmListener mDeepAlarmListener
= new AlarmManager.OnAlarmListener() {
@Override
public void onAlarm() {
synchronized (DeviceIdleController.this) {
///每次Doze状态转换都会在该方法中进行
stepIdleStateLocked("s:alarm");
}
}
};
Deep Doze的scheduleAlarmLocked定时任务触发后，会回调onAlarm，执行stepIdleStateLocked函数。
void stepIdleStateLocked(String reason) {
final long now = SystemClock.elapsedRealtime();
//说明1小时内有Alarm定时时间到，暂不进入IDLE状态，30min后再进入
if ((now+mConstants.MIN_TIME_TO_ALARM) >
mAlarmManager.getNextWakeFromIdleTime()) {
if (mState != STATE_ACTIVE) {
//将当前设备变为活动状态，LightDoze和DeepDoze都为Active状态
becomeActiveLocked("alarm", Process.myUid());
becomeInactiveIfAppropriateLocked();
}
return;
}
switch (mState) {
case STATE_INACTIVE:
//启动Sensor
startMonitoringMotionLocked();
//设置STATE_IDLE_PENDING状态时长的定时Alarm，30mins
scheduleAlarmLocked(mConstants.IDLE_AFTER_INACTIVE_TIMEOUT,
false);
mNextIdlePendingDelay = mConstants.IDLE_PENDING_TIMEOUT;//5mins
mNextIdleDelay = mConstants.IDLE_TIMEOUT;//60mins
//此时状态变为PENDING状态
mState = STATE_IDLE_PENDING;
break;
case STATE_IDLE_PENDING:
//此时状态变为SENSING状态
mState = STATE_SENSING;
//设置STATE_SENSING状态超时时长的定时Alarm，DEBUG?1:4mins
scheduleSensingTimeoutAlarmLocked(mConstants.SENSING_TIMEOUT);
//取消通用位置更新和GPS位置更新
cancelLocatingLocked();
mNotMoving = false;
mLocated = false;
mLastGenericLocation = null;
mLastGpsLocation = null;
//开始检测是否有移动
mAnyMotionDetector.checkForAnyMotion();
break;
case STATE_SENSING:
//取消用于STATE_SENSING状态超时时长的Alarm
cancelSensingTimeoutAlarmLocked();
//此时状态变为LOCATING
mState = STATE_LOCATING;
//设置STATE_LOCATING状态时长的Alarm
scheduleAlarmLocked(mConstants.LOCATING_TIMEOUT,
false);//DEBUG?15:30
//请求通用位置
if (mLocationManager != null
&& mLocationManager.getProvider(LocationManager.
NETWORK_PROVIDER) != null) {
mLocationManager.requestLocationUpdates(mLocationRequest,
mGenericLocationListener, mHandler.getLooper());
mLocating = true;
} else {
mHasNetworkLocation = false;
}
//请求GPS位置
if (mLocationManager != null
&& mLocationManager.getProvider(LocationManager.
GPS_PROVIDER) != null) {
mHasGps = true;
mLocationManager.requestLocationUpdates(LocationManager.
GPS_PROVIDER, 1000, 5,
mGpsLocationListener, mHandler.getLooper());
mLocating = true;
} else {
mHasGps = false;
}
//如果true,则break，因为在Location的Listener中会进入下一个状态，
//否则进入下一步状态
if (mLocating) {
break;
}
case STATE_LOCATING:
//取消DeepDoze的Alarm
cancelAlarmLocked();
//取消位置更新
cancelLocatingLocked();
//Sensor停止检测
mAnyMotionDetector.stop();
case STATE_IDLE_MAINTENANCE:
//设置STATE_IDLE状态时长的定时Alarm，到时后将退出IDLE状态
scheduleAlarmLocked(mNextIdleDelay, true);
//设置下次IDLE时间
mNextIdleDelay = (long)(mNextIdleDelay * mConstants.IDLE_FACTOR);
mNextIdleDelay = Math.min(mNextIdleDelay, mConstants.MAX_IDLE_TIMEOUT);
if (mNextIdleDelay < mConstants.IDLE_TIMEOUT) {
mNextIdleDelay = mConstants.IDLE_TIMEOUT;
}
mState = STATE_IDLE;
//进入DeepDoze的IDLE后，覆盖LightDoze
if (mLightState != LIGHT_STATE_OVERRIDE) {
mLightState = LIGHT_STATE_OVERRIDE;
//取消LightDoze的定时Alarm
cancelLightAlarmLocked();
}
//申请wakelock保持CPU唤醒
mGoingIdleWakeLock.acquire();
//handler中处理idle状态后各个模块的限制工作
mHandler.sendEmptyMessage(MSG_REPORT_IDLE_ON);
break;
case STATE_IDLE:
mActiveIdleOpCount = 1;//表示现在有正在活动的操作
//申请wakelock锁保持cpu唤醒
mActiveIdleWakeLock.acquire();
//设置STATE_IDLE_MAINTENANCE状态时长的定时Alarm，
//到时后将退出维护状态
scheduleAlarmLocked(mNextIdlePendingDelay, false);
mMaintenanceStartTime = SystemClock.elapsedRealtime();
mNextIdlePendingDelay =
Math.min(mConstants.MAX_IDLE_PENDING_TIMEOUT,
(long)(mNextIdlePendingDelay *
mConstants.IDLE_PENDING_FACTOR));
if (mNextIdlePendingDelay < mConstants.IDLE_PENDING_TIMEOUT) {
mNextIdlePendingDelay = mConstants.IDLE_PENDING_TIMEOUT;
}
mState = STATE_IDLE_MAINTENANCE;
//Handler中处理退出idle状态进入维护状态后取消限制的工作
mHandler.sendEmptyMessage(MSG_REPORT_IDLE_OFF);
break;
}
}
可以看到，Deep Doze的状态转换都是通过scheduleAlarmLocked和stepIdleStateLocked这两个函数进行的。 在case为STATE_INACTIVE的逻辑中，将mState设置成了STATE_IDLE_PENDING，启动Sensor监听，并设置了一个30分钟的延时任务。
2. 从STATE_DLE_PENDING进入STATE_SENSING
当30分钟无中断，state就从PENDING进入到了SENSING状态中。
case STATE_IDLE_PENDING:
//此时状态变为SENSING状态
mState = STATE_SENSING;
//设置STATE_SENSING状态超时时长的定时Alarm，4分钟
scheduleSensingTimeoutAlarmLocked(mConstants.SENSING_TIMEOUT);
//取消通用位置更新和GPS位置更新
cancelLocatingLocked();
mNotMoving = false;
mLocated = false;
mLastGenericLocation = null;
mLastGpsLocation = null;
//开始检测是否有运动
mAnyMotionDetector.checkForAnyMotion();
break;
在这个状态中，会开始运动检测，并持续4分钟。
3. 从STATE_SENSING进入到STATE_LOCATING
4. 从STATE_LOCATING进入到STATE_IDLE
5. 从STATE_IDLE_MAINTENANCE进入到STATE_IDLE
SENSING的下一个状态是STATE_LOCATING，STATE_LOCATING和STATE_IDLE_MAINTENANCE的下一个状态都是STATE_IDLE，这里一起讲
case STATE_SENSING:
//取消用于STATE_SENSING状态超时时长的Alarm
cancelSensingTimeoutAlarmLocked();
//此时状态变为LOCATING
mState = STATE_LOCATING;
//设置STATE_LOCATING状态时长的Alarm,
scheduleAlarmLocked(mConstants.LOCATING_TIMEOUT,
false);
//请求通用位置
if (mLocationManager != null
&& mLocationManager.getProvider(LocationManager.
NETWORK_PROVIDER) != null) {
mLocationManager.requestLocationUpdates(mLocationRequest,
mGenericLocationListener, mHandler.getLooper());
mLocating = true;
} else {
mHasNetworkLocation = false;
}
//请求GPS位置
if (mLocationManager != null
&& mLocationManager.getProvider(LocationManager.
GPS_PROVIDER) != null) {
mHasGps = true;
mLocationManager.requestLocationUpdates(LocationManager.
GPS_PROVIDER, 1000, 5,
mGpsLocationListener, mHandler.getLooper());
mLocating = true;
} else {
mHasGps = false;
}
//如果true,则break，因为在Location的Listener中会进入下一个状态，
//否则进入下一步状态
if (mLocating) {
break;
}
case STATE_LOCATING:
//取消DeepDoze的Alarm
cancelAlarmLocked();
//取消位置更新
cancelLocatingLocked();
//Sensor停止检测
mAnyMotionDetector.stop();
case STATE_IDLE_MAINTENANCE:
//设置STATE_IDLE状态时长的定时Alarm，到时后将退出IDLE状态
scheduleAlarmLocked(mNextIdleDelay, true);
//设置下次IDLE时间
mNextIdleDelay = (long)(mNextIdleDelay * mConstants.IDLE_FACTOR);
mNextIdleDelay = Math.min(mNextIdleDelay, mConstants.MAX_IDLE_TIMEOUT);
if (mNextIdleDelay < mConstants.IDLE_TIMEOUT) {
mNextIdleDelay = mConstants.IDLE_TIMEOUT;
}
mState = STATE_IDLE;
//进入DeepDoze的IDLE后，覆盖LightDoze
if (mLightState != LIGHT_STATE_OVERRIDE) {
mLightState = LIGHT_STATE_OVERRIDE;
//取消LightDoze的定时Alarm
cancelLightAlarmLocked();
}
//申请wakelock保持CPU唤醒
mGoingIdleWakeLock.acquire();
//handler中处理idle状态后各个模块的限制工作
mHandler.sendEmptyMessage(MSG_REPORT_IDLE_ON);
break;
在这个过程中检测是否有gps以及是否有位置移动，如果有gps，则通过break跳出循环，并进行30S的位置移动检测；没有gps，则进入到case为STATE_IDLE_MAINTENANCE的处理中，并将state设置为STATE_IDLE。
进入到STATE_IDLE后，会申请wakelock，同时调用MSG_REPORT_IDLE_ON的handler任务来进行耗电策略的限制，这里和light doze的idle状态处理都是同一个入口，所以MSG_REPORT_IDLE_ON在下面light doze中在详细将。
同时，我们可以看到，进入STATE_IDLE后，会设置一个时间为：
IDLE_TIMEOUT = mParser.getDurationMillis(KEY_IDLE_TIMEOUT,
!COMPRESS_TIME ? 60 * 60 * 1000L : 6 * 60 * 1000L);
mNextIdleDelay = (long)(mNextIdleDelay * mConstants.IDLE_FACTOR);
mNextIdleDelay = Math.min(mNextIdleDelay, mConstants.MAX_IDLE_TIMEOUT);
if (mNextIdleDelay < mConstants.IDLE_TIMEOUT) {
mNextIdleDelay = mConstants.IDLE_TIMEOUT;
}
的延时任务，IDLE_FACTOR为2，mNextIdleDelay初始值为60分钟，MAX_IDLE_TIMEOUT为6个小时，所以这个时间为1个小时，2个小时，4个小时，最后稳定为6个小时
6. 从STATE_IDLE进入到STATE_IDLE_MAINTENANCE
case STATE_IDLE:
mActiveIdleOpCount = 1;//表示现在有正在活动的操作
//申请wakelock锁保持cpu唤醒
mActiveIdleWakeLock.acquire();
//设置STATE_IDLE_MAINTENANCE状态时长的定时Alarm，
//到时后将退出维护状态
scheduleAlarmLocked(mNextIdlePendingDelay, false);
mMaintenanceStartTime = SystemClock.elapsedRealtime();
mNextIdlePendingDelay =
Math.min(mConstants.MAX_IDLE_PENDING_TIMEOUT,
(long)(mNextIdlePendingDelay *
mConstants.IDLE_PENDING_FACTOR));
if (mNextIdlePendingDelay < mConstants.IDLE_PENDING_TIMEOUT) {
mNextIdlePendingDelay = mConstants.IDLE_PENDING_TIMEOUT;
}
mState = STATE_IDLE_MAINTENANCE;
//Handler中处理退出idle状态进入维护状态后取消限制的工作
mHandler.sendEmptyMessage(MSG_REPORT_IDLE_OFF);
break;
进入MAINTENANCE状态后，会在MSG_REPORT_IDLE_OFF的handler中取消各种限制，并位置mNextIdlePendingDelay时间段
mNextIdlePendingDelay =
Math.min(mConstants.MAX_IDLE_PENDING_TIMEOUT,
(long)(mNextIdlePendingDelay *
mConstants.IDLE_PENDING_FACTOR));
if (mNextIdlePendingDelay < mConstants.IDLE_PENDING_TIMEOUT) {
mNextIdlePendingDelay = mConstants.IDLE_PENDING_TIMEOUT;
}
IDLE_PENDING_TIMEOUT为5分钟
Light Doze
1. 从INACTIVE进入LIGHT_STATE_PRE_IDLE
scheduleLightAlarmLocked到达时间后，会触发下面的回调
void scheduleLightAlarmLocked(long delay) {
mNextLightAlarmTime = SystemClock.elapsedRealtime() + delay;
//到达时间后，回调mLightAlarmListener.onAlarm()
mAlarmManager.set(AlarmManager.ELAPSED_REALTIME_WAKEUP,
mNextLightAlarmTime, "DeviceIdleController.light",
mLightAlarmListener, mHandler);
}
private final AlarmManager.OnAlarmListener mLightAlarmListener
= new AlarmManager.OnAlarmListener() {
@Override
public void onAlarm() {
synchronized (DeviceIdleController.this) {
//每次LightDoze的状态改变，都会调用该方法进行处理
stepLightIdleStateLocked("s:alarm");
}
}
};
Light Doze的状态改变也都是在stepLightIdleStateLocked函数中处理
void stepLightIdleStateLocked(String reason) {
//如果mLigthSate为LIGHT_STATE_OVERRIDE,说明DeepDoze处于Idle状态，由
// DeepDoze将LightDoze覆盖了，因此不需要进行LightDoze了
if (mLightState == LIGHT_STATE_OVERRIDE) {
return;
}
switch (mLightState) {
case LIGHT_STATE_INACTIVE:
//当前最小预算时间
mCurIdleBudget =
mConstants.LIGHT_IDLE_MAINTENANCE_MIN_BUDGET;//1min
//表示LightDoze 进入空闲(Idle)状态的时间
mNextLightIdleDelay = mConstants.LIGHT_IDLE_TIMEOUT;//5mins
//LightDoze进入维护状态(maintenance)的开始时间
mMaintenanceStartTime = 0;
if (!isOpsInactiveLocked()) {
//将状态置为LIGHT_STATE_PRE_IDLE状态
mLightState = LIGHT_STATE_PRE_IDLE;
//设置一个3分钟的定时器
scheduleLightAlarmLocked(mConstants.LIGHT_PRE_
IDLE_TIMEOUT);
break;
}
case LIGHT_STATE_PRE_IDLE:
case LIGHT_STATE_IDLE_MAINTENANCE:
if (mMaintenanceStartTime != 0) {
//维护状态的时长
long duration = SystemClock.elapsedRealtime() -
mMaintenanceStartTime;
if (duration <
mConstants.LIGHT_IDLE_MAINTENANCE_MIN_BUDGET) {
mCurIdleBudget += (mConstants.LIGHT_IDLE_MAINTENANCE
_MIN_BUDGET-duration);
} else {
mCurIdleBudget -= (duration-mConstants.LIGHT_IDLE_
MAINTENANCE_MIN_BUDGET);
}
}
mMaintenanceStartTime = 0;//重置维护开始时间
//设置一个定时器，到达时间后用来处理LightDoze处于IDLE状态的操作
scheduleLightAlarmLocked(mNextLightIdleDelay);
//计算下次进入Idle状态的
mNextLightIdleDelay =
Math.min(mConstants.LIGHT_MAX_IDLE_TIMEOUT,
(long)(mNextLightIdleDelay *
mConstants.LIGHT_IDLE_FACTOR));
if (mNextLightIdleDelay < mConstants.LIGHT_IDLE_TIMEOUT) {
mNextLightIdleDelay = mConstants.LIGHT_IDLE_TIMEOUT;
}
//将LightDoze模式置为IDLE状态,开始进行一些限制
mLightState = LIGHT_STATE_IDLE;
addEvent(EVENT_LIGHT_IDLE);
//申请一个wakelock锁，保持CPU唤醒
mGoingIdleWakeLock.acquire();
//处理LightDoze进入Idle状态后的操作
mHandler.sendEmptyMessage(MSG_REPORT_IDLE_ON_LIGHT);
break;
case LIGHT_STATE_IDLE:
case LIGHT_STATE_WAITING_FOR_NETWORK:
if (mNetworkConnected || mLightState ==
LIGHT_STATE_WAITING_FOR_NETWORK) {
//如果网络有链接或者当前LightDoze模式为等待网络状态，则进行维护，
// 并将LightDoze模式退出IDLE状态,进入维护状态
mActiveIdleOpCount = 1;
mActiveIdleWakeLock.acquire();
mMaintenanceStartTime = SystemClock.elapsedRealtime();
// 保证10<=mCurIdleBudget<=30mins ，mCurIdleBudget是维护状态的时间
if (mCurIdleBudget <
mConstants.LIGHT_IDLE_MAINTENANCE_MIN_BUDGET) {
mCurIdleBudget =
mConstants.LIGHT_IDLE_MAINTENANCE_MIN_BUDGET;
} else if (mCurIdleBudget >
mConstants.LIGHT_IDLE_MAINTENANCE_MAX_BUDGET) {
mCurIdleBudget =
mConstants.LIGHT_IDLE_MAINTENANCE_MAX_BUDGET;
}
//设置一个定时器，到达时间后用来处理LightDoze处于维护状态的操作
scheduleLightAlarmLocked(mCurIdleBudget);
mLightState = LIGHT_STATE_IDLE_MAINTENANCE;//进入维护状态
addEvent(EVENT_LIGHT_MAINTENANCE);
//处理LightDoze进入Maintenance状态后的操作
mHandler.sendEmptyMessage(MSG_REPORT_IDLE_OFF);
} else {
//将LightDoze模式置为LIGHT_STATE_WAITING_FOR_NETWORK,
//在进入维护状态前需要获取网络
//设置一个定时器，到达时间后用来处理LightDoze处于
//WAITING_FOR_NETWORK状态的操作
scheduleLightAlarmLocked(mNextLightIdleDelay);//600000,5mins
mLightState = LIGHT_STATE_WAITING_FOR_NETWORK;
EventLogTags.writeDeviceIdleLight(mLightState, reason);
}
break;
}
}
从代码中可以看到，case为LIGHT_STATE_INACTIVE的处理逻辑中，做了这几件事
将当前状态设置为LIGHT_STATE_PRE_IDLE，
并发送一个3分钟的闹钟，准备进入下一个状态。
后续状态也全部是通过scheduleLightAlarmLocked来设置定时任务，然后在stepLightIdleStateLocked函数中处理状态的转换和对应状态的逻辑
2. 从LIGHT_STATE_PRE_IDLE进入LIGHT_STATE_IDLE
3. 从LIGHT_STATE_IDLE_MAINTENANCE进入LIGHT_STATE_IDLE
LIGHT_STATE_PRE_IDLE和LIGHT_STATE_IDLE_MAINTENANCE的下一个状态都是LIGHT_STATE_IDLE，所以他们的处理也在同一个入口
LIGHT_IDLE_TIMEOUT = mParser.getDurationMillis(KEY_LIGHT_IDLE_TIMEOUT,
!COMPRESS_TIME ? 5 * 60 * 1000L : 15 * 1000L);
LIGHT_MAX_IDLE_TIMEOUT = mParser.getDurationMillis(KEY_LIGHT_MAX_IDLE_TIMEOUT,
!COMPRESS_TIME ? 15 * 60 * 1000L : 60 * 1000L);
void stepLightIdleStateLocked(String reason) {
//如果mLigthSate为LIGHT_STATE_OVERRIDE,说明DeepDoze处于Idle状态，由
// DeepDoze将LightDoze覆盖了，因此不需要进行LightDoze了
if (mLightState == LIGHT_STATE_OVERRIDE) {
return;
}
switch (mLightState) {
……
case LIGHT_STATE_PRE_IDLE:
case LIGHT_STATE_IDLE_MAINTENANCE:
if (mMaintenanceStartTime != 0) {
//维护状态的时长
long duration = SystemClock.elapsedRealtime() -
mMaintenanceStartTime;
if (duration <
mConstants.LIGHT_IDLE_MAINTENANCE_MIN_BUDGET) {
mCurIdleBudget += (mConstants.LIGHT_IDLE_MAINTENANCE
_MIN_BUDGET-duration);
} else {
mCurIdleBudget -= (duration-mConstants.LIGHT_IDLE_
MAINTENANCE_MIN_BUDGET);
}
}
mMaintenanceStartTime = 0;//重置维护开始时间
//设置一个定时器，到达时间后用来处理LightDoze处于IDLE状态的操作
scheduleLightAlarmLocked(mNextLightIdleDelay);
//计算下次进入Idle状态的
mNextLightIdleDelay =
Math.min(mConstants.LIGHT_MAX_IDLE_TIMEOUT,
(long)(mNextLightIdleDelay *
mConstants.LIGHT_IDLE_FACTOR));
if (mNextLightIdleDelay < mConstants.LIGHT_IDLE_TIMEOUT) {
mNextLightIdleDelay = mConstants.LIGHT_IDLE_TIMEOUT;
}
//将LightDoze模式置为IDLE状态,开始进行一些限制
mLightState = LIGHT_STATE_IDLE;
addEvent(EVENT_LIGHT_IDLE);
//申请一个wakelock锁，保持CPU唤醒
mGoingIdleWakeLock.acquire();
//处理LightDoze进入Idle状态后的操作
mHandler.sendEmptyMessage(MSG_REPORT_IDLE_ON_LIGHT);
break;
……
}
}
这里会将state设置成LIGHT_STATE_IDLE，并设置一个mNextLightIdleDelay的计时任务，以便进入下一个状态，mNextLightIdleDelay的初始值是5分钟。
这里我们可以看到LIGHT_STATE_PRE_IDLE和LIGHT_STATE_IDLE_MAINTENANCE是同一个case处理逻辑，这两个状态的下一个状态都是LIGHT_STATE_IDLE。
如果上一个状态是LIGHT_STATE_IDLE_MAINTENANCE，则
mNextLightIdleDelay = Math.min(mConstants.LIGHT_MAX_IDLE_TIMEOUT,(long)(mNextLightIdleDelay * mConstants.LIGHT_IDLE_FACTOR))，LIGHT_MAX_IDLE_TIMEOUT为15分钟，LIGHT_IDLE_FACTOR为2
所以light doze的IDLE时间为5分钟，10分钟，最后稳定为15分钟。
当state的状态转换成IDLE后，这里会申请wakelock锁，让cpu唤醒，然后通过MSG_REPORT_IDLE_ON_LIGHT的Handler任务进行逻辑处理，然后再释放wakelock锁，让cpu休眠。
剩下的几种状态函数转换都在上面的函数中有注释，就不详细讲解了。
Doze限制逻辑
我们接着看MSG_REPORT_IDLE_ON_LIGHT中做了哪些事情
case MSG_REPORT_IDLE_ON:
case MSG_REPORT_IDLE_ON_LIGHT:: {
final boolean deepChanged;
final boolean lightChanged;
if (msg.what == MSG_REPORT_IDLE_ON) {
//通知PMS设置Deep Doze模式处于IDLE状态
deepChanged = mLocalPowerManager.setDeviceIdleMode(true);
//通知PMS为Light Doze模式不处于IDLE状态
lightChanged = mLocalPowerManager.setLightDeviceIdleMode(false);
} else {
//通知PMS设置Deep Doze模式不处于IDLE状态
deepChanged = mLocalPowerManager.setDeviceIdleMode(false);
//通知PMS为Light Doze模式处于IDLE状态
lightChanged = mLocalPowerManager.setLightDeviceIdleMode(true);
}
try {
//通知NetworkPolicyManager进入IDLE状态，进行网络访问的限制
mNetworkPolicyManager.setDeviceIdleMode(true);
//通知BatteryStatsService统计Light Doze或者Deep Doze进入IDLE状态
mBatteryStats.noteDeviceIdleMode(msg.what == MSG_REPORT_IDLE_ON
? BatteryStats.DEVICE_IDLE_MODE_DEEP
: BatteryStats.DEVICE_IDLE_MODE_LIGHT, null, Process.myUid());
} catch (RemoteException e) {
}
//发送DeepDoze模式改变的广播
if (deepChanged) {
getContext().sendBroadcastAsUser(mIdleIntent, UserHandle.ALL);
}
//发送Light模式改变的广播
if (lightChanged) {
getContext().sendBroadcastAsUser(mLightIdleIntent, UserHandle.ALL);
}
//释放wakelock
mGoingIdleWakeLock.release();
} break;
可以看到，Deep Doze和Light Doze在进入IDLE状态后的逻辑处理在同一个地方。这里根据模式的不同，通知PowerServiceManager，NetworkPolicyManager，BatteryStats等进行不同的优化策略。这里主要做的事情有这几件
调用mLocalPowerManager.setDeviceIdleMode设置是否是Deep Doze的Idle状态，如果为Idle，这一步会将应用设置成忽略WakeLock的状态
调用mLocalPowerManager.setLightDeviceIdleMode设置是否是Light Doze的Idle状态
调用mNetworkPolicyManager.setDeviceIdleMode(true)，通过添加防火墙规则，来进行网络访问限制
调用BatteryStats.noteDeviceIdleMode进行状态变更及耗时统计
调用sendBroadcastAsUser发送广播，进入Deep Doze或者Light Doze的Idle状态
释放WakeLock
Doze限制逻辑取消
Light Doze和Deep Doze进入MAINTENCANCE后都会取消各种限制，取消的逻辑在MSG_REPORT_IDLE_OFF的handler任务中处理。
case MSG_REPORT_IDLE_OFF: {
// mActiveIdleWakeLock is held at this point
EventLogTags.writeDeviceIdleOffStart("unknown");
final boolean deepChanged = mLocalPowerManager.setDeviceIdleMode(false);
final boolean lightChanged = mLocalPowerManager.setLightDeviceIdleMode(false);
try {
mNetworkPolicyManager.setDeviceIdleMode(false);
mBatteryStats.noteDeviceIdleMode(BatteryStats.DEVICE_IDLE_MODE_OFF,
null, Process.myUid());
} catch (RemoteException e) {
}
if (deepChanged) {
incActiveIdleOps();
getContext().sendOrderedBroadcastAsUser(mIdleIntent, UserHandle.ALL,
null, mIdleStartedDoneReceiver, null, 0, null, null);
}
if (lightChanged) {
incActiveIdleOps();
getContext().sendOrderedBroadcastAsUser(mLightIdleIntent, UserHandle.ALL,
null, mIdleStartedDoneReceiver, null, 0, null, null);
}
decActiveIdleOps();
} break;
Standby模式
Doze模式是针对整个系统的耗电优化模式，而Standby模式，即应用群组待机模式是针对单个应用的耗电优化模式，它是Android7.0引入的，当应用处于闲置状态时，系统会根据应用应用最近使用的时间和频率，设置成对应的群组，不同的群组下，jobs，alarm和network的使用限制程度不一样。
Standby模式的进入和退出
当用户有一段时间未触摸应用时，系统便会判断进入Standby模式，以下条件下不适用或者会退出Standby模式：
用户主动启动该App;
该App当前有一个前台进程（或包含一个活动的前台服务，或被另一个activity或前台service使用）;
在锁定屏幕或通知栏中看到的通知
系统应用
充电状态
Standby模式优化策略
应用在进入Standby后，会根据该应用所属的状态，对Jobs，Alarms和Network进行相应的限制，应用的状态分为五个等级
Activie:如果用户当前正在使用应用，应用将被归到“atcitive”状态中
WORKING_SER：如果应用经常运行(12至24小时内使用过)，但当前未处于活跃状态，它将被归到“工作集”群组中。 例如，用户在大部分时间都启动的某个社交媒体应用可能就属于“工作集”群组。 如果应用被间接使用，它们也会被升级到“工作集”群组中 。
FREQUENT：如果应用会定期使用，但不是每天都必须使用 （亮屏时间差超过1小时、使用时间差超过24小时） ，它将被归到“常用”群组中。 例如，用户在健身房运行的某个锻炼跟踪应用可能就属于“常用”群组。
RARE：如果应用不经常使用 (亮屏时间差超过2小时、使用时间差超过48小时) ，那么它属于“极少使用”群组。 例如，用户仅在入住酒店期间运行的酒店应用就可能属于“极少使用”群组。如果应用处于“极少使用”群组，系统将对它运行作业、触发警报和接收高优先级 FCM 消息的能力施加严格限制。系统还会限制应用连接到网络的能力。
NEVER：安装但是从未运行过的应用会被归到“从未使用”群组中。 系统会对这些应用施加极强的限制。
下面是对这个五个等级的应用的限制情况
developer.android.com/topic/perfo…
Standby模式实现原理
Standby模式的逻辑实现在AppStandbyController对象中，该对象提供了reportEvent，来让外部进行app行为变化的通知，如ams，NotificationManagerService等都会调用reportEvent来告知app有行为变化并更新Bucket
AppStandbyController.java
更新Bucket
void reportEvent(UsageEvents.Event event, long elapsedRealtime, int userId) {
if (!mAppIdleEnabled) return;
synchronized (mAppIdleLock) {
// TODO: Ideally this should call isAppIdleFiltered() to avoid calling back
// about apps that are on some kind of whitelist anyway.
final boolean previouslyIdle = mAppIdleHistory.isIdle(
event.mPackage, userId, elapsedRealtime);
// Inform listeners if necessary
if ((event.mEventType == UsageEvents.Event.ACTIVITY_RESUMED
|| event.mEventType == UsageEvents.Event.ACTIVITY_PAUSED
|| event.mEventType == UsageEvents.Event.SYSTEM_INTERACTION
|| event.mEventType == UsageEvents.Event.USER_INTERACTION
|| event.mEventType == UsageEvents.Event.NOTIFICATION_SEEN
|| event.mEventType == UsageEvents.Event.SLICE_PINNED
|| event.mEventType == UsageEvents.Event.SLICE_PINNED_PRIV
|| event.mEventType == UsageEvents.Event.FOREGROUND_SERVICE_START)) {
final AppUsageHistory appHistory = mAppIdleHistory.getAppUsageHistory(
event.mPackage, userId, elapsedRealtime);
final int prevBucket = appHistory.currentBucket;
final int prevBucketReason = appHistory.bucketingReason;
final long nextCheckTime;
final int subReason = usageEventToSubReason(event.mEventType);
final int reason = REASON_MAIN_USAGE | subReason;
//根据使用行为更新bucket
if (event.mEventType == UsageEvents.Event.NOTIFICATION_SEEN
|| event.mEventType == UsageEvents.Event.SLICE_PINNED) {
mAppIdleHistory.reportUsage(appHistory, event.mPackage,
STANDBY_BUCKET_WORKING_SET, subReason,
0, elapsedRealtime + mNotificationSeenTimeoutMillis);
nextCheckTime = mNotificationSeenTimeoutMillis;
} else if (event.mEventType == UsageEvents.Event.SYSTEM_INTERACTION) {
mAppIdleHistory.reportUsage(appHistory, event.mPackage,
STANDBY_BUCKET_ACTIVE, subReason,
0, elapsedRealtime + mSystemInteractionTimeoutMillis);
nextCheckTime = mSystemInteractionTimeoutMillis;
} else if (event.mEventType == UsageEvents.Event.FOREGROUND_SERVICE_START) {
// Only elevate bucket if this is the first usage of the app
if (prevBucket != STANDBY_BUCKET_NEVER) return;
mAppIdleHistory.reportUsage(appHistory, event.mPackage,
STANDBY_BUCKET_ACTIVE, subReason,
0, elapsedRealtime + mInitialForegroundServiceStartTimeoutMillis);
nextCheckTime = mInitialForegroundServiceStartTimeoutMillis;
} else {
mAppIdleHistory.reportUsage(appHistory, event.mPackage,
STANDBY_BUCKET_ACTIVE, subReason,
elapsedRealtime, elapsedRealtime + mStrongUsageTimeoutMillis);
nextCheckTime = mStrongUsageTimeoutMillis;
}
//设置延时消息，根据使用时间更新bucket
mHandler.sendMessageDelayed(mHandler.obtainMessage
(MSG_CHECK_PACKAGE_IDLE_STATE, userId, -1, event.mPackage),
nextCheckTime);
final boolean userStartedInteracting =
appHistory.currentBucket == STANDBY_BUCKET_ACTIVE &&
prevBucket != appHistory.currentBucket &&
(prevBucketReason & REASON_MAIN_MASK) != REASON_MAIN_USAGE;
maybeInformListeners(event.mPackage, userId, elapsedRealtime,
appHistory.currentBucket, reason, userStartedInteracting);
if (previouslyIdle) {
notifyBatteryStats(event.mPackage, userId, false);
}
}
}
}
reportEvent会根据mEventType进行一次Bucket更新，并根据mEventType设置一次延时任务，这个延时任务中会再次根据应用的使用行为再次更新Bucket。其中Notification类型的消息的延迟时间为12小时，SYSTEM_INTERACTION为10分钟，其他的mStrongUsageTimeoutMillis为1小时
MSG_CHECK_PACKAGE_IDLE_STATE的handler消息主要根据使用时长更新Bucket
static final int[] THRESHOLD_BUCKETS = {
STANDBY_BUCKET_ACTIVE,
STANDBY_BUCKET_WORKING_SET,
STANDBY_BUCKET_FREQUENT,
STANDBY_BUCKET_RARE
};
static final long[] SCREEN_TIME_THRESHOLDS = {
0,
0,
COMPRESS_TIME ? 120 * 1000 : 1 * ONE_HOUR,
COMPRESS_TIME ? 240 * 1000 : 2 * ONE_HOUR
};
static final long[] ELAPSED_TIME_THRESHOLDS = {
0,
COMPRESS_TIME ? 1 * ONE_MINUTE : 12 * ONE_HOUR,
COMPRESS_TIME ? 4 * ONE_MINUTE : 24 * ONE_HOUR,
COMPRESS_TIME ? 16 * ONE_MINUTE : 48 * ONE_HOUR
};
long[] mAppStandbyScreenThresholds = SCREEN_TIME_THRESHOLDS;
long[] mAppStandbyElapsedThresholds = ELAPSED_TIME_THRESHOLDS;
@StandbyBuckets int getBucketForLocked(String packageName, int userId,
long elapsedRealtime) {
int bucketIndex = mAppIdleHistory.getThresholdIndex(packageName, userId,
elapsedRealtime, mAppStandbyScreenThresholds, mAppStandbyElapsedThresholds);
return THRESHOLD_BUCKETS[bucketIndex];
}
AppIdleHistory.java
int getThresholdIndex(String packageName, int userId, long elapsedRealtime,
long[] screenTimeThresholds, long[] elapsedTimeThresholds) {
ArrayMap
AppUsageHistory appUsageHistory = getPackageHistory(userHistory, packageName,
elapsedRealtime, false);
if (appUsageHistory == null) return screenTimeThresholds.length - 1;
//app最后一次亮屏使用到现在,已经有多久的亮屏时间
long screenOnDelta = getScreenOnTime(elapsedRealtime) - appUsageHistory.lastUsedScreenTime;
//app最后一次使用到现在的时间点
long elapsedDelta = getElapsedTime(elapsedRealtime) - appUsageHistory.lastUsedElapsedTime;
for (int i = screenTimeThresholds.length - 1; i >= 0; i--) {
if (screenOnDelta >= screenTimeThresholds[i]
&& elapsedDelta >= elapsedTimeThresholds[i]) {
return i;
}
}
return 0;
}
App耗电分析
Battery Historian
Android官方提供了Battery Historian来进行电量使用的分析，Battery Historian 图表会显示一段时间内与电源相关的事件。
从上面的图也可以看到，进入到Doze后，BLE scanning，GPS等就无行为了，并且cpu，wakelock等活动的频率也变低了
我们还能通过Battery Historian获取应用的
在设备上的估计耗电量。
网络信息。
唤醒锁定次数。
服务
进程信息
官方文档已经讲的非常详细，就不在这儿细说了
developer.android.com/topic/perfo…
Slardar
Slardar电量相关的统计指标项包括
app处于前台时，提供电流作为耗电指标
通过采集app的cpu、流量和gps等的使用，来计算出一个加权和作为耗电指标
电池温度，作为衡量耗电的辅助参考
归因项有
高CPU可以通过cpu菜单查看高耗CPU的堆栈
gps(location),alarm和wakelock使用在超过指定持有时间和频次后，会上报当时的采集堆栈
虽然Slardar有上报很多功耗相关指标，但是目前还只能作为整体功耗的参考，并且很多指标波动起伏大，没法对更细化的治理提供帮助
飞书耗电治理
治理目标
消除主流手机的高功耗提醒
建立健全的功耗监控及防劣化体系
治理方案
在前面我们已经知道耗电=模块功率✖️模块耗时，所以治理本质就是在不影响性能和功能的情况下，减少飞书中所使用到的模块的耗时，并且我们了解了系统进行耗电优化的策略，在飞书的耗电治理中，也可以同样的参考对应的策略。
治理方案主要分为监控的完善和耗电的治理
功耗治理
为了能体系化的进行功耗治理，这里分为了针对耗电模块进行治理和针对状态进行执行两大类
分模块治理
模块的耗电治理主要体现在下面几个方面
1.CPU
死循环函数，高频函数，高耗时函数，无效函数等不必要的cpu消耗或消耗较多的函数治理cpu使用率较高的场景及业务治理 2.GPU和Display
过度绘制，过多的动画，不可见区域的动画等浪费GPU的场景治理主动降低屏幕亮度，使用深色UI等方案降低屏幕电量消耗 3.网络
不影响业务和性能前提下，降低网络访问频率Doze状态时减少无效的网络请求 4.GPS
对使用GPS的场景，如小程序等，合理的降低精度，减少请求频率 5.Audio、Camera、Video等项
除了分模块治理，还针对状态进行治理，主要状态有这几种
分状态治理
1.前台状态
渲染场景优化
音视频等场景优化
……
2.后台状态
task任务降频或者丢弃
网络访问降频，适配Doze模式
减少cpu消耗较多的函数执行
减少gps等高功耗场景
完善功耗分析和监控体系
为了能更好的进行治理，完善的功耗分析和监控体系是不可避免的，不然就会出现无的放矢的状态。在这一块主要建设的点有
1. 完善的CPU消耗监控
前后台高cpu消耗场景监控，高cpu消耗线程监控(slardar已有)高频task，高耗时task，后台task监控(已有)消耗较高，耗时较高的函数监控 2. GPU和Display消耗监控
动画场景，过度绘制检测，View层级检测，屏幕电量消耗监控等 3. 网络
Rust，OkHttp及其他网络请求场景，频率，消耗监控后台网络访问监控 4. GPS
GPS使用场景，时长，电量消耗监控 5. Audio、Camera、Video
使用场景，时长，电量消耗监控 6. 整体和场景的电量消耗
飞书整体的电量消耗和不同场景的电量消耗，用来度量版本功耗的质量
作者：helson赵子健 链接：https://juejin.cn/post/7165802603870158855
最后
如果想要成为架构师或想突破20~30K薪资范畴，那就不要局限在编码，业务，要会选型、扩展，提升编程思维。此外，良好的职业规划也很重要，学习的习惯很重要，但是最重要的还是要能持之以恒，任何不能坚持落实的计划都是空谈。
如果你没有方向，这里给大家分享一套由阿里高级架构师编写的《Android八大模块进阶笔记》，帮大家将杂乱、零散、碎片化的知识进行体系化的整理，让大家系统而高效地掌握Android开发的各个知识点。 相对于我们平时看的碎片化内容，这份笔记的知识点更系统化，更容易理解和记忆，是严格按照知识体系编排的。
全套视频资料：
一、面试合集 二、源码解析合集
三、开源框架合集
欢迎大家一键三连支持，若需要文中资料，直接点击文末CSDN官方认证微信卡片免费领取↓↓↓