扣丁书屋

分析 Android 耗电原理后,飞书是这样做耗电治理的

飞书最近在进行耗电治理的专项优化,本篇文章将分析 Android 系统的耗电原理,分享飞书的耗电治理规划。

Android 耗电统计原理

我们先了解一下 Android 系统是如何进行耗电的统计的,最精确的方式当然是使用电流仪来进行统计,但是正常状态下手机硬件不支持,所以系统统计耗电时,使用的基本是??楣β?× ??楹氖?/strong>这个公式来进行的,但不同的??榛故腔嵊幸恍┎畋?。这种统计方式没法做到非常的精确,但是也基本能反应出各应用电量的消耗大小。

??楣β?/h3>

我们先来看看??楣β?,每个??榈暮牡绻β识际遣灰谎?,以计算方式来分,又分为下面三类:

  1. 第一类是 Camera、FlashLight、MediaPlayer 等一般传感器或设备的???/strong>。其工作功率基本和额定功率保持一致,所以??榈缌康募扑阒恍枰臣颇?榈氖褂檬背ぴ俪艘远疃üβ始纯?。
  2. 第二类是 Wifi、Mobile、BlueTooth 这类数据???/strong>。其工作功率可以分为不同的档位,比如,当手机的 Wifi 信号比较弱的时候,Wifi ??榫捅匦牍ぷ髟诒冉细叩墓β实滴灰晕质萘绰?,所以这类??榈牡缌考扑阌械憷嗨朴谖颐侨粘5牡绶鸭扑?,需要 “阶梯计费”。
  3. 第三类是屏幕,CPU ???/strong>。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 如下:

文件中每个??榈亩杂λ得?,可以在谷歌提供的文档中看到详细的说明。

https://source.android.com/devices/tech/power/values

??楹氖?/h3>

了解了??榈墓β?,我们再来看看??楹氖?,耗电??樵诠ぷ骰蛘咦刺涓?,都会通知 batterystats 这个 service,而 BatteryStatsService 会调用 BatteryStats 对象进行耗时的统计,BatteryStats 的构造函数中会初始化各个??榈?Timer,用来进行耗时的统计,并将统计的数据存储在batterystats.bin文件中。

我们来详细看看下面几个??榈氖侨绾谓型臣频模?/p>

  • wifi ???/li>
    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 ???/li>
    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 这个简单的??榭纯此侨绾瓮臣频缌康模?/p>

可以看到,里面只是简单的用了 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;

这七种状态的转换关系如下:

根据上图,他们的关系总结如下:

  1. 当设备亮屏或者处于正常使用状态时其就为 ACTIVE 状态;
  2. ACTIVE 状态下不充电且灭屏设备就会切换到 INACTIVE 状态;
  3. INACTIVE 状态经过 30 分钟,期间检测没有打断状态的行为 Doze 就切换到 IDLE_PENDING 的状态;
  4. 然后再经过 30 分钟以及一系列的判断,状态切换到 SENSING;
  5. 在 SENSING 状态下会去检测是否有地理位置变化,没有的话就切到 LOCATION 状态;
  6. LOCATION 状态下再经过 30s 的检测时间之后就进入了 Doze 的核心状态 IDLE;
  7. 在 IDLE 模式下每隔一段时间就会进入一次 IDLE_MAINTANCE,此间用来处理之前被挂起的一些任务,这个时间段为一个小时,两个小时,四个小时,最后稳定为最长为六个小时
  8. IDLE_MAINTANCE 状态持续 5 分钟之后会重新回到 IDLE 状态;
  9. 在除 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 个状态的转换关系如下:

根据上图,他们的转换关系总结如下:

  1. 当设备亮屏或者处于正常使用状态时其就为 ACTIVE 状态;
  2. ACTIVE 状态下不充电且灭屏设备就会切换到 INACTIVE 状态;
  3. INACTIVE 状态经过 3 分钟,期间检测没有打断状态的行为就切换到 PRE_IDLE 的状态;
  4. PRE_IDLE 状态经过 5 分钟,期间无打断就进入到 IDLE 状态
  5. 进入 IDLE 状态会根据是否有网络连接选择进入 WAITING_FOR_NETWORK 还是进入 MAINTENANCE 窗口期,进入窗口期的时间为:5 分钟,10 分钟,最后稳定最长为 15 分钟
  6. 进入 WAITING_FOR_NETWORK 会持续 5 分钟后重新进入到 IDLE 状态
  7. 进入 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 都需要达到一定条件后才能进入,并且进入后会定期提供窗口期来解除限制。

它们的对比如下:

Doze 模式实现原理

前面已经了解了 Doze 模式了,下面就在通过 Android 中的 Doze 机制的源码,深入了解 Doze 的实现原理。Doze 机制相关的源码都在 DeviceIdleController 这个类中。

进入 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 的状态转换都是通过scheduleAlarmLockedstepIdleStateLocked这两个函数进行的。在 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 的处理逻辑中,做了这几件事:

  1. 将当前状态设置为 LIGHT_STATE_PRE_IDLE;
  2. 并发送一个 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 等进行不同的优化策略。这里主要做的事情有这几件:

  1. 调用 mLocalPowerManager.setDeviceIdleMode 设置是否是 Deep Doze 的 Idle 状态,如果为 Idle,这一步会将应用设置成忽略 WakeLock 的状态
  2. 调用 mLocalPowerManager.setLightDeviceIdleMode 设置是否是 Light Doze 的 Idle 状态
  3. 调用 mNetworkPolicyManager.setDeviceIdleMode(true),通过添加防火墙规则,来进行网络访问限制
  4. 调用 BatteryStats.noteDeviceIdleMode 进行状态变更及耗时统计
  5. 调用 sendBroadcastAsUser 发送广播,进入 Deep Doze 或者 Light Doze 的 Idle 状态
  6. 释放 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 模式:

  1. 用户主动启动该 App;
  2. 该 App 当前有一个前台进程(或包含一个活动的前台服务,或被另一个 activity 或前台 service 使用);
  3. 在锁定屏幕或通知栏中看到的通知;
  4. 系统应用;
  5. 充电状态;

Standby 模式优化策略

应用在进入 Standby 后,会根据该应用所属的状态,对 Jobs,Alarms 和 Network 进行相应的限制,应用的状态分为五个等级:

  1. Activie:如果用户当前正在使用应用,应用将被归到“atcitive”状态中
  2. WORKING_SER:如果应用经常运行(12 至 24 小时内使用过),但当前未处于活跃状态,它将被归到“工作集”群组中。例如,用户在大部分时间都启动的某个社交媒体应用可能就属于“工作集”群组。如果应用被间接使用,它们也会被升级到“工作集”群组中 。
  3. FREQUENT:如果应用会定期使用,但不是每天都必须使用(亮屏时间差超过 1 小时、使用时间差超过 24 小时),它将被归到“常用”群组中。例如,用户在健身房运行的某个锻炼跟踪应用可能就属于“常用”群组。
  4. RARE:如果应用不经常使用(亮屏时间差超过 2 小时、使用时间差超过 48 小时),那么它属于“极少使用”群组。例如,用户仅在入住酒店期间运行的酒店应用就可能属于“极少使用”群组。如果应用处于“极少使用”群组,系统将对它运行作业、触发警报和接收高优先级 FCM 消息的能力施加严格限制。系统还会限制应用连接到网络的能力。
  5. NEVER:安装但是从未运行过的应用会被归到“从未使用”群组中。系统会对这些应用施加极强的限制。

下面是对这个五个等级的应用的限制情况:

https://developer.android.com/topic/performance/power/power-details

Standby 模式实现原理

Standby 模式的逻辑实现在 AppStandbyController 对象中,该对象提供了 reportEvent,来让外部进行 app 行为变化的通知,如 ams,NotificationManagerService 等都会调用 reportEvent 来告知 app 有行为变化并更新 Bucket

更新 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<String, AppUsageHistory> userHistory = getUserHistory(userId);
    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 获取应用的:

  • 在设备上的估计耗电量
  • 网络信息
  • 唤醒锁定次数
  • 服务
  • 进程信息

官方文档已经讲的非常详细,就不在这儿细说了:

https://developer.android.com/topic/performance/power/setup-battery-historian?hl=zh-cn

Slardar

Slardar 电量相关的统计指标项包括:

  • app 处于前台时,提供电流作为耗电指标
  • 通过采集 app 的 cpu、流量和 gps 等的使用,来计算出一个加权和作为耗电指标
  • 电池温度,作为衡量耗电的辅助参考

归因项有:

  • 高 CPU 可以通过 cpu 菜单查看高耗 CPU 的堆栈
  • gps(location),alarm 和 wakelock 使用在超过指定持有时间和频次后,会上报当时的采集堆栈

虽然 Slardar 有上报很多功耗相关指标,但是目前还只能作为整体功耗的参考,并且很多指标波动起伏大,没法对更细化的治理提供帮助。

飞书耗电治理

治理目标

  1. 消除主流手机的高功耗提醒
  2. 建立健全的功耗监控及防劣化体系

治理方案

在前面我们已经知道耗电=??楣β?× ??楹氖?/strong>,所以治理本质就是在不影响性能和功能的情况下,减少飞书中所使用到的??榈暮氖?,并且我们了解了系统进行耗电优化的策略,在飞书的耗电治理中,也可以同样的参考对应的策略。

治理方案主要分为监控的完善和耗电的治理。

功耗治理

为了能体系化地进行功耗治理,这里分为了针对耗电??榻兄卫砗驼攵宰刺兄葱辛酱罄?。

分??橹卫?/h5>

??榈暮牡缰卫碇饕逑衷谙旅婕父龇矫妫?/p>

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. 整体和场景的电量消耗

  • 飞书整体的电量消耗和不同场景的电量消耗,用来度量版本功耗的质量

https://mp.weixin.qq.com/s/uKFNjvW6_rZXIyIzo6fHYw

最多阅读

简化Android的UI开发 3年以前  |  515560次阅读
Android 深色模式适配原理分析 2年以前  |  27101次阅读
Android 样式系统 | 主题背景覆盖 2年以前  |  8452次阅读
Android Studio 生成so文件 及调用 2年以前  |  6353次阅读
30分钟搭建一个android的私有Maven仓库 3年以前  |  5205次阅读
Android设计与开发工作流 3年以前  |  4926次阅读
Google Enjarify:可代替dex2jar的dex反编译 3年以前  |  4786次阅读
移动端常见崩溃指标 2年以前  |  4686次阅读
Android内存异?;?用户空间)_NE 2年以前  |  4417次阅读
Android多渠道打包工具:apptools 3年以前  |  4390次阅读
Android-??榛?面向接口编程 2年以前  |  4365次阅读
Google Java编程风格规范(中文版) 3年以前  |  4269次阅读
Android死锁初探 2年以前  |  4167次阅读
Android UI基本技术点 3年以前  |  4083次阅读

手机扫码阅读
18禁止午夜福利体验区,人与动人物xxxx毛片人与狍,色男人窝网站聚色窝
<蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <文本链> <文本链> <文本链> <文本链> <文本链> <文本链>