Android7.0 PowerManagerService(3) 核心函数updatePowerStateLocked的主要流程

版权声明:本文为博主原创文章,遵循 CC 4.0 BY 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://blog.csdn.net/Gaugamela/article/details/52838654

前面的博客中,我们已经分析过,当Android中的进程要使用电量时,需要向PMS申请WakeLock;当进程完成工作后,需要释放对应的WakeLock。
PMS收到申请和释放WakeLock的请求后,均需要调用updatePowerStateLocked来更新电源的状态,该函数是PMS的核心方法。
接下来,我们就结合代码,看一下updatePowerStateLocked的工作流程。

/**
* Updates the global power state based on dirty bits recorded in mDirty.
*
* This is the main function that performs power state transitions.
* We centralize them here so that we can recompute the power state completely
* each time something important changes, and ensure that we do it the same
* way each time.  The point is to gather all of the transition logic here.
*/
private void updatePowerStateLocked() {
    //未启动完毕或mDirty没有记录变化
    if (!mSystemReady || mDirty == 0) {
        return;
    }
    ..........
    try {
        // Basic state updates.
        // 1、更新基本状态
        updateIsPoweredLocked(mDirty);
        updateStayOnLocked(mDirty);
        updateScreenBrightnessBoostLocked(mDirty);

        // Update wakefulness.
        // Loop because the wake lock and user activity computations are influenced
        // by changes in wakefulness.
        // 2、更新wakelock和用户活动 
        final long now = SystemClock.uptimeMillis();
        int dirtyPhase2 = 0;
        for (;;) {
            int dirtyPhase1 = mDirty;
            dirtyPhase2 |= dirtyPhase1;
            mDirty = 0;

            updateWakeLockSummaryLocked(dirtyPhase1);
            updateUserActivitySummaryLocked(now, dirtyPhase1);
            if (!updateWakefulnessLocked(dirtyPhase1)) {
                break;
            }
        }

        // Update display power state.
        // 3、更新display power state
        boolean displayBecameReady = updateDisplayPowerStateLocked(dirtyPhase2);

        // Update dream state (depends on display ready signal).
        // 4、更新dream state
        updateDreamLocked(dirtyPhase2, displayBecameReady);

        // Send notifications, if needed.
        finishWakefulnessChangeIfNeededLocked();

        // Update suspend blocker.
        // Because we might release the last suspend blocker here, we need to make sure
        // we finished everything else first!
        // 5、更新suspend blocker
        updateSuspendBlockerLocked();
    } finally {
        ..........
    }
}

在PMS中有个很重要的变量mDirty,该变量按位存储PMS中的各种变化状态。
例如,之前介绍PMS的acquire WakeLock流程时,就进行了以下操作:

.........
mDirty |= DIRTY_WAKE_LOCKS;
........

每当PMS检测到一些重要事件发生时,就会更新mDirty的相应的位。
从updatePowerStateLocked的代码可以看出,它将根据mDirty中的信息,来更新手机中的电源状态。

根据Android源码中的注释,可以看出updatePowerStateLocked的工作主要分为几个步骤,接下来我们一个一个步骤的来进行分析。

一、更新基本状态信息
1、updateIsPoweredLocked
我们先来看看updateIsPoweredLocked函数:

private void updateIsPoweredLocked(int dirty) {
    //DIRTY_BATTERY_STATE位置1时,表示终端的电源状态发生了改变
    if ((dirty & DIRTY_BATTERY_STATE) != 0) {
        //记录过去的状态
        final boolean wasPowered = mIsPowered;
        final int oldPlugType = mPlugType;
        final boolean oldLevelLow = mBatteryLevelLow;

        //得到终端现在是否在充电
        mIsPowered = mBatteryManagerInternal.isPowered(BatteryManager.BATTERY_PLUGGED_ANY);

        //得到充电的类型
        mPlugType = mBatteryManagerInternal.getPlugType();

        //得到当前的电量
        mBatteryLevel = mBatteryManagerInternal.getBatteryLevel();

        //判断是否为低电量
        mBatteryLevelLow = mBatteryManagerInternal.getBatteryLevelLow();

        //是否充电的状态发生改变,或者充电类型发生改变
        if (wasPowered != mIsPowered || oldPlugType != mPlugType) {
            mDirty |= DIRTY_IS_POWERED;

            // Update wireless dock detection state.
            //无线充电相关,暂时不用管
            final boolean dockedOnWirelessCharger = mWirelessChargerDetector.update(
                    mIsPowered, mPlugType, mBatteryLevel);

            final long now = SystemClock.uptimeMillis();
            //判断插拔充电器或者USB是否需要唤醒屏幕  
            if (shouldWakeUpWhenPluggedOrUnpluggedLocked(wasPowered, oldPlugType,
                    dockedOnWirelessCharger)) {
                //之前的博客中已经分析过这个函数,主要是做好唤醒终端屏幕前的准备工作
                wakeUpNoUpdateLocked(now, "android.server.power:POWER", Process.SYSTEM_UID,
                        mContext.getOpPackageName(), Process.SYSTEM_UID);
            }
            //触发一次用户活动,修改PMS中记录用户活动事件的时间,同时通知BatteryStatsService等
            userActivityNoUpdateLocked(
                    now, PowerManager.USER_ACTIVITY_EVENT_OTHER, 0, Process.SYSTEM_UID);

            // Tell the notifier whether wireless charging has started so that
            // it can provide feedback to the user.
            //无线充电相关的通知,暂时可以不管
            if (dockedOnWirelessCharger) {
                mNotifier.onWirelessChargingStarted();
            }
        }

        if (wasPowered != mIsPowered || oldLevelLow != mBatteryLevelLow) {
            //结束低电的状态
            if (oldLevelLow != mBatteryLevelLow && !mBatteryLevelLow) {
                ........
                //从命名来看,该标志用于决定终端在低电模式下是否“打盹”(接近休眠)
                mAutoLowPowerModeSnoozing = false;
            }
            //更新低电模式相关的操作
            updateLowPowerModeLocked();
        }
    }
}

从以上代码可以看出updateIsPoweredLocked主要用于:
更新PMS中的一些变量,包括记录终端是否在充电、充电的类型、电池的电量及电池电量是否处于低电状态;
当电源的充电状态,或者充电类型发生变化,判断出现插拔充电器等操作时,是否需要点亮或熄灭屏幕;
当电源充电状态发生变化,或者终端是否处于低电量的标志发生变化的时候,终端调用updateLowPowerModeLocked()更新低电模式相关的操作。

我们跟进一下updateLowPowerModeLocked函数:

private void updateLowPowerModeLocked() {
    //处于充电状态,并且设置过低电模式的标志位
    if (mIsPowered && mLowPowerModeSetting) {
        ........    
        // Turn setting off if powered
        //更新数据库,关闭低电模式
        Settings.Global.putInt(mContext.getContentResolver(),
                Settings.Global.LOW_POWER_MODE, 0);
        mLowPowerModeSetting = false;
    }

    //判断是否可以进入自动省电模式
    //要求是:未充电 && 进行了自动省电的配置 && 没有设置低电“打盹” && 电池电量低
    final boolean autoLowPowerModeEnabled = !mIsPowered && mAutoLowPowerModeConfigured
            && !mAutoLowPowerModeSnoozing && mBatteryLevelLow;

    //当前是否为低电模式
    final boolean lowPowerModeEnabled = mLowPowerModeSetting || autoLowPowerModeEnabled;

    if (mLowPowerModeEnabled != lowPowerModeEnabled) {
        mLowPowerModeEnabled = lowPowerModeEnabled;
        //调用底层动态库的powerHint函数
        powerHintInternal(POWER_HINT_LOW_POWER, lowPowerModeEnabled ? 1 : 0);

        //开机完成后才能执行的Runnable对象
        postAfterBootCompleted(new Runnable() {
            //发送低电模式CHANGING的广播
            Intent intent = new Intent(PowerManager.ACTION_POWER_SAVE_MODE_CHANGING)
                    .putExtra(PowerManager.EXTRA_POWER_SAVE_MODE, mLowPowerModeEnabled)
                    .addFlags(Intent.FLAG_RECEIVER_REGISTERED_ONLY);
            mContext.sendBroadcast(intent);

            //PMS提供了registerLowPowerModeObserver的接口
            //其它进程可以调用该接口,注册观察者
            synchronized (mLock) {
                listeners = new ArrayList<PowerManagerInternal.LowPowerModeListener>(
                        mLowPowerModeListeners);
            }
            for (int i=0; i<listeners.size(); i++) {
                //调用回调接口的onLowPowerModeChanged函数,通知其它进程低电模式发生改变
                listeners.get(i).onLowPowerModeChanged(lowPowerModeEnabled);
            }

            //再次发送CHANGED广播
            intent = new Intent(PowerManager.ACTION_POWER_SAVE_MODE_CHANGED);
                intent.addFlags(Intent.FLAG_RECEIVER_REGISTERED_ONLY);
                mContext.sendBroadcast(intent);

            // Send internal version that requires signature permission.
            mContext.sendBroadcastAsUser(new Intent(
                    PowerManager.ACTION_POWER_SAVE_MODE_CHANGED_INTERNAL), UserHandle.ALL,
                    Manifest.permission.DEVICE_POWER);
        });
    }
}

从上面的代码可以看出updateLowPowerModeLocked函数,
首先判断手机是否在充电,如果手机在充电,退出LowPowerMode模式,同时更新数据库;
当手机的低电量模式发生了变化,就发送广播进行通知,并回调关于监听该模式变化的观察者的接口。
例如:UI对应的APK收到低电量省电模式的广播,就会弹出低电量省电模式的提醒界面。

可以看出这一部分除了更新PMS中的一些变量外,关注的重点还是集中在:
充电状态是否改变;
充电状态的改变,将引出对充电器插拔是否需要亮屏的考虑;
同样,充电状态的改变,将引出对终端的低电模式是否发生改变的考虑。
从这个角度来看,updateIsPoweredLocked函数的命名是实至名归的。

2、updateStayOnLocked
现在我们看看基本状态更新第二部分的updateStayOnLocked函数:

/**
* Updates the value of mStayOn.
* Sets DIRTY_STAY_ON if a change occurred.
*/
private void updateStayOnLocked(int dirty) {
    //电源状态或电源设置发生了改变
    if ((dirty & (DIRTY_BATTERY_STATE | DIRTY_SETTINGS)) != 0) {
        final boolean wasStayOn = mStayOn;
        //设置了充电器插入时亮屏(分为AC充电亮屏、USB充电亮屏或无线充电亮屏)
        if (mStayOnWhilePluggedInSetting != 0
                //判断mMaximumScreenOffTimeoutFromDeviceAdmin的是否处于0与Integer.MAX_VALUE之间
                //Android给出的注释是:
                //The maximum allowable screen off timeout according to the device
                // administration policy
                //初始为Integer.MAX_VALUE,因此这里是要求其它进程没有设置这个值
                //应该对应于强制息屏时间
                && !isMaximumScreenOffTimeoutFromDeviceAdminEnforcedLocked()) {
            //判断是否充电亮屏,定义于BatteryService.java中
            //从代码来看,只要mStayOnWhilePluggedInSetting设置了,就会亮屏
            mStayOn = mBatteryManagerInternal.isPowered(mStayOnWhilePluggedInSetting);
        } else {
            mStayOn = false;
        }

        if (mStayOn != wasStayOn) {
            mDirty |= DIRTY_STAY_ON;
        }
    }
}

这一部分的代码功能比较单一,主要用于更新变量mStayOn的值。
如果mStayOn如果为true,则屏幕保持长亮的状态。

3、updateScreenBrightnessBoostLocked
Android手机定义了一个最大屏幕亮度,用户可以手动或者让终端自动确定最大的屏幕亮度。
updateScreenBrightnessBoostLocked函数主要用于:更新终端可处于最大屏幕亮度的时间。

为了比较好的理解updateScreenBrightnessBoostLocked函数,
我们可以先分析一下与之相关的,PMS提供的对外的接口boostScreenBrightness。
该方法的作用是让屏幕在一段时间内保持最大的亮度,使屏幕在强光下有更好的可读性。

public void boostScreenBrightness(long eventTime) {
    ..........
    mContext.enforceCallingOrSelfPermission(
            android.Manifest.permission.DEVICE_POWER, null);

    final int uid = Binder.getCallingUid();
    final long ident = Binder.clearCallingIdentity();
    try {
        boostScreenBrightnessInternal(eventTime, uid);
    } finally {
        Binder.restoreCallingIdentity(ident);
    }
}

private void boostScreenBrightnessInternal(long eventTime, int uid) {
    synchronized (mLock) {
        //系统没有准备好或者当前为Asleep状态, 不处理新到的事件
        if (!mSystemReady || mWakefulness == WAKEFULNESS_ASLEEP
                //过时的事件不处理
                || eventTime < mLastScreenBrightnessBoostTime) {
            return;
        }
        ..............
        //记录事件到来的事件,也可以认为是终端处于最亮屏幕状态的起始时间
        mLastScreenBrightnessBoostTime = eventTime;

        //设置最亮屏幕的标志位true 
        if (!mScreenBrightnessBoostInProgress) {
            mScreenBrightnessBoostInProgress = true;
            //发送广播
            mNotifier.onScreenBrightnessBoostChanged();
        }

        //修改mDirty的值,表示最大屏幕亮度的状态发生了变化  
        mDirty |= DIRTY_SCREEN_BRIGHTNESS_BOOST;

        //记录
        userActivityNoUpdateLocked(eventTime,
            PowerManager.USER_ACTIVITY_EVENT_OTHER, 0, uid);

        //更新电源的状态信息
        updatePowerStateLocked();
    }
}

从上面的代码可以看出,该函数:
首先,使用mLastScreenBrightnessBoostTime变量记录了终端处于最大屏幕亮度的起始时间;
然后,将最大屏幕亮度的标志位置为true,并修改mDirty标志位,以表示最大屏幕亮度的状态发生了变化;
最后,调用updatePowerStateLocked方法更新电源状态信息。
我们已经知道,updatePowerStateLocked将会调用到updateScreenBrightnessBoostLocked。

接下来,我们看看updateScreenBrightnessBoostLocked对应的代码:

private void updateScreenBrightnessBoostLocked(int dirty) {
    //根据mDirty的标志位来判断终端屏幕最大可用亮度的状态是否发生了变化
    if ((dirty & DIRTY_SCREEN_BRIGHTNESS_BOOST) != 0) {

        //上面的代码已经提到过,当boostScreenBrightness接口被调用时,mScreenBrightnessBoostInProgress置为true
        if (mScreenBrightnessBoostInProgress) {

            //移除旧的超时事件
            final long now = SystemClock.uptimeMillis();
            mHandler.removeMessages(MSG_SCREEN_BRIGHTNESS_BOOST_TIMEOUT);

            //终端处于最大屏幕亮度的时间,在sleep的时间之后,说明终端还未息屏之类的
            if (mLastScreenBrightnessBoostTime > mLastSleepTime) {

                //此时,重新计算终端可处于最大屏幕亮度的时间
                final long boostTimeout = mLastScreenBrightnessBoostTime +
                        SCREEN_BRIGHTNESS_BOOST_TIMEOUT;
                if (boostTimeout > now) {
                    Message msg = mHandler.obtainMessage(MSG_SCREEN_BRIGHTNESS_BOOST_TIMEOUT);
                    msg.setAsynchronous(true);

                    //发送延迟的超时事件
                    //当屏幕离开最大亮度状态时,该事件将被发送
                    //当该事件被处理时,会再次进入到updateScreenBrightnessBoostLocked函数
                    mHandler.sendMessageAtTime(msg, boostTimeout);
                    return;
                }
            }

            //进入到这个分支时,说明屏幕处于最大亮度状态的时间已经超时了
            //将该标志置为false
            mScreenBrightnessBoostInProgress = false;

            //发送广播
            mNotifier.onScreenBrightnessBoostChanged();

            //触发一次用户活动,写入mDirty标志位,同时做一些其它记录
            userActivityNoUpdateLocked(now,
                    PowerManager.USER_ACTIVITY_EVENT_OTHER, 0, Process.SYSTEM_UID);
        }
    }
}

至此,PMS第一阶段更新基本状态信息的流程结束。

二、更新wakelock和用户活动

for (;;) {
    int dirtyPhase1 = mDirty;
    dirtyPhase2 |= dirtyPhase1;
    mDirty = 0;

    updateWakeLockSummaryLocked(dirtyPhase1);
    updateUserActivitySummaryLocked(now, dirtyPhase1);

    //updateWakefulnessLocked将决定系统是否进入休眠或dreaming状态
    //主要是更新DIRTY_WAKEFULNESS位,如果不需要更新,则返回false
    if (!updateWakefulnessLocked(dirtyPhase1)) {
        break;
    }
}

1、updateWakeLockSummaryLocked
updateWakeLockSummaryLocked函数根据PMS当前持有的所有WakeLock,得到当前终端整体的信息,保存到mWakeLockSummary变量中。

/**
* Updates the value of mWakeLockSummary to summarize the state of all active wake locks.
* Note that most wake-locks are ignored when the system is asleep.
*/
private void updateWakeLockSummaryLocked(int dirty) {
    //PMS持有的WakeLock发生变化,或者唤醒状态发生变化时,才重新进行更新mWakeLockSummary
    //例如:调用PMS的acquireWakeLock时,就会将dirty的DIRTY_WAKE_LOCKS位置1
    if ((dirty & (DIRTY_WAKE_LOCKS | DIRTY_WAKEFULNESS)) != 0) {
        mWakeLockSummary = 0;

        final int numWakeLocks = mWakeLocks.size();
        for (int i = 0; i < numWakeLocks; i++) {
            final WakeLock wakeLock = mWakeLocks.get(i);

            //这里只关注WakeLock的level
            //下面的代码其实就是实现每个level WakeLock对应的注释信息
            switch (wakeLock.mFlags & PowerManager.WAKE_LOCK_LEVEL_MASK) {
                case PowerManager.PARTIAL_WAKE_LOCK:
                    //在分析PMS acquireWakeLock的流程时,已经提到过
                    //在doze模式下,不在白名单内的非系统应用申请PARTIAL_WAKE_LOCK时,将被disabled
                    if (!wakeLock.mDisabled) {
                        // We only respect this if the wake lock is not disabled.
                        mWakeLockSummary |= WAKE_LOCK_CPU;
                    }
                    break;
                case PowerManager.FULL_WAKE_LOCK:
                    mWakeLockSummary |= WAKE_LOCK_SCREEN_BRIGHT | WAKE_LOCK_BUTTON_BRIGHT;
                    break;
                case PowerManager.SCREEN_BRIGHT_WAKE_LOCK:
                    mWakeLockSummary |= WAKE_LOCK_SCREEN_BRIGHT;
                    break;
                case PowerManager.SCREEN_DIM_WAKE_LOCK:
                    mWakeLockSummary |= WAKE_LOCK_SCREEN_DIM;
                    break;
                case PowerManager.PROXIMITY_SCREEN_OFF_WAKE_LOCK:
                    mWakeLockSummary |= WAKE_LOCK_PROXIMITY_SCREEN_OFF;
                    break;
                case PowerManager.DOZE_WAKE_LOCK:
                    mWakeLockSummary |= WAKE_LOCK_DOZE;
                    break;
                case PowerManager.DRAW_WAKE_LOCK:
                    mWakeLockSummary |= WAKE_LOCK_DRAW;
                    break;
            }
        }

        // Cancel wake locks that make no sense based on the current state.
        //从下面的代码可以看出,PMS中的mWakefulness变量记录了终端当前的状态
        //下面就是移除在特定状态下,没有意义的WakeLock
        if (mWakefulness != WAKEFULNESS_DOZING) {
            //如果不是Dozing状态,移除相应的wakeLock标志位
            mWakeLockSummary &= ~(WAKE_LOCK_DOZE | WAKE_LOCK_DRAW);
        }
        if (mWakefulness == WAKEFULNESS_ASLEEP
                || (mWakeLockSummary & WAKE_LOCK_DOZE) != 0) {
            //如果当前为Asleep或者有Doze的wakeLock锁的时候,应该移除掉屏幕亮度相关的wakeLock锁
            mWakeLockSummary &= ~(WAKE_LOCK_SCREEN_BRIGHT | WAKE_LOCK_SCREEN_DIM
                    | WAKE_LOCK_BUTTON_BRIGHT);
            if (mWakefulness == WAKEFULNESS_ASLEEP) {
                //休眠时,sensor不再需要监听终端是否靠近物体,以触发亮灭屏
                mWakeLockSummary &= ~WAKE_LOCK_PROXIMITY_SCREEN_OFF;
            }
        }

        // Infer implied wake locks where necessary based on the current state.
        //根据当前的状态,及PMS持有的WakeLock,推断出隐含的持锁需求
        //例如:当PMS持有亮屏锁WAKE_LOCK_SCREEN_BRIGHT时,若当前终端为唤醒态
        //那么CPU显然也需要处于唤醒态
        if ((mWakeLockSummary & (WAKE_LOCK_SCREEN_BRIGHT | WAKE_LOCK_SCREEN_DIM)) != 0) {
            if (mWakefulness == WAKEFULNESS_AWAKE) {
                mWakeLockSummary |= WAKE_LOCK_CPU | WAKE_LOCK_STAY_AWAKE;
            } else if (mWakefulness == WAKEFULNESS_DREAMING) {
                mWakeLockSummary |= WAKE_LOCK_CPU;
            }
        }
        if ((mWakeLockSummary & WAKE_LOCK_DRAW) != 0) {
            mWakeLockSummary |= WAKE_LOCK_CPU;
        }
        ...................
    }
}

结合每个WakeLock level的注释信息,以上代码还是比较好理解的。

这里唯一需要说明的是,Android定义一个mWakeLockSummary变量的原因是:
PMS将WakeLock定义为不同进程的请求信息,这些请求信息对CPU、屏幕和键盘有不同的需求。
对于每一种资源而言,只要有一个申请满足获取条件,PMS就需要为终端分配该申请对应的资源。
例如:假设PMS有20个WakeLock,只有1个申请亮屏,另外19个只申请CPU唤醒,PMS仍然需要保持终端亮屏。
因此,mWakeLockSummary就提供了一种整合多个WakeLock请求的功能,方便PMS进行集中的控制。

2、updateUserActivitySummaryLocked
updateUserActivitySummaryLocked主要根据用户最后的活动来决定当前屏幕的状态。

/**
* Updates the value of mUserActivitySummary to summarize the user requested
* state of the system such as whether the screen should be bright or dim.
* Note that user activity is ignored when the system is asleep.
*/
private void updateUserActivitySummaryLocked(long now, int dirty) {
    if ((dirty & (DIRTY_WAKE_LOCKS | DIRTY_USER_ACTIVITY
            | DIRTY_WAKEFULNESS | DIRTY_SETTINGS)) != 0) {
        mHandler.removeMessages(MSG_USER_ACTIVITY_TIMEOUT);

        long nextTimeout = 0;
        if (mWakefulness == WAKEFULNESS_AWAKE
                || mWakefulness == WAKEFULNESS_DREAMING
                || mWakefulness == WAKEFULNESS_DOZING) {

            //获取进入休眠状态的时间sleepTimeout
            //getSleepTimeoutLocked中会判断休眠时间和屏幕熄灭时间的关系
            //如果休眠时间sleepTimeout小于屏幕熄灭时间screenOfftime,  
            //则休眠时间被调整为屏幕熄灭时间,因为屏幕亮屏状态下,终端不能进入休眠
            final int sleepTimeout = getSleepTimeoutLocked();

            //获取屏幕熄灭的时间
            final int screenOffTimeout = getScreenOffTimeoutLocked(sleepTimeout);

            //获取屏幕变暗的时间
            final int screenDimDuration = getScreenDimDurationLocked(screenOffTimeout);

            //当Window Manager判定用户inactive时,将此标志置为true
            final boolean userInactiveOverride = mUserInactiveOverrideFromWindowManager;

            //类似于之前的mWakeLockSummary,将当前的用户事件,转化为PMS可以处理的屏幕状态
            mUserActivitySummary = 0;

            //在唤醒的状态下,发生过用户事件
            if (mLastUserActivityTime >= mLastWakeTime) {

                //重新计算出屏幕需要变暗的时间
                nextTimeout = mLastUserActivityTime
                        + screenOffTimeout - screenDimDuration;
                if (now < nextTimeout) {
                    //如果没有到达需要变暗的时间,那么当前屏幕的状态为USER_ACTIVITY_SCREEN_BRIGHT(亮屏)
                    mUserActivitySummary = USER_ACTIVITY_SCREEN_BRIGHT;
                } else {
                    //到达变暗的时间,则计算出屏幕熄灭的时间
                    nextTimeout = mLastUserActivityTime + screenOffTimeout;

                    if (now < nextTimeout) {
                        //还没到熄灭的时间,则当前屏幕的状态为USER_ACTIVITY_SCREEN_DIM(暗屏)
                        mUserActivitySummary = USER_ACTIVITY_SCREEN_DIM;
                    }
                }
            }

            //注意mUserActivitySummary为0才会进入下面的分支
            //即上面改变mUserActivitySummary的条件不满足时,才会进入这个分支(例如:唤醒状态下,没发生过改变屏幕状态的UserActivity)
            if (mUserActivitySummary == 0
                    //mLastUserActivityTimeNoChangeLights表示用户最后的活动不会改变屏幕当前的状态
                    && mLastUserActivityTimeNoChangeLights >= mLastWakeTime) {

                //计算下次屏幕熄灭的时间
                nextTimeout = mLastUserActivityTimeNoChangeLights + screenOffTimeout;

                //还未到达熄屏时间
                if (now < nextTimeout) {
                    if (mDisplayPowerRequest.policy == DisplayPowerRequest.POLICY_BRIGHT) {
                        //当前屏幕是亮屏,仍然设置为亮屏
                        mUserActivitySummary = USER_ACTIVITY_SCREEN_BRIGHT;
                    } else if (mDisplayPowerRequest.policy == DisplayPowerRequest.POLICY_DIM) {
                        //当前屏幕是变暗,仍然设置为变暗
                        mUserActivitySummary = USER_ACTIVITY_SCREEN_DIM;
                    }
                }
            }

            if (mUserActivitySummary == 0) {
                //若定义了有效的休眠时间
                if (sleepTimeout >= 0) {
                    //计算用户最后的活动时间
                    final long anyUserActivity = Math.max(mLastUserActivityTime,
                            mLastUserActivityTimeNoChangeLights);

                    //只有在唤醒状态下,进行了用户活动,才会重新更新休眠时间 (此时,应该是有过用户活动,但过了息屏时间了)
                    if (anyUserActivity >= mLastWakeTime) {
                        nextTimeout = anyUserActivity + sleepTimeout;
                        if (now < nextTimeout) {
                            //走到这个分支,应该是屏幕已经熄灭,但还未到达休眠状态,先进入dream态
                            mUserActivitySummary = USER_ACTIVITY_SCREEN_DREAM;
                        }
                    }
                } else {
                    //直接进入dream态,后文的updateWakefulnessLocked将判断是否休眠
                    mUserActivitySummary = USER_ACTIVITY_SCREEN_DREAM;
                    nextTimeout = -1;
                }
            }

            //如果屏幕未进入dream态,但Window Manager判定用户inactive,则进入下面分支
            if (mUserActivitySummary != USER_ACTIVITY_SCREEN_DREAM && userInactiveOverride) {
                //如果屏幕未熄灭
                if ((mUserActivitySummary &
                        (USER_ACTIVITY_SCREEN_BRIGHT | USER_ACTIVITY_SCREEN_DIM)) != 0) {
                    // Device is being kept awake by recent user activity
                    if (nextTimeout >= now && mOverriddenTimeout == -1) {
                        // Save when the next timeout would have occurred
                        mOverriddenTimeout = nextTimeout;
                    }
                }
                //Window Manager的权限很大,如果它判断用户inactive,直接进入dream态
                mUserActivitySummary = USER_ACTIVITY_SCREEN_DREAM;
                nextTimeout = -1;
            }

            //根据nextTimeOut延迟发送信息,信息被处理后,将重新调用updatePowerStateLocked,于是再次进入到该方法
            //通过不断进入该方法,不断评估是否根据用户动作亮、熄屏等
            if (mUserActivitySummary != 0 && nextTimeout >= 0) {
                Message msg = mHandler.obtainMessage(MSG_USER_ACTIVITY_TIMEOUT);
                msg.setAsynchronous(true);
                mHandler.sendMessageAtTime(msg, nextTimeout);
            }
        } else {
            mUserActivitySummary = 0;
        }
        ..........
    }
}

从上面的代码可以看出,在该函数中用mUserActivitySummary变量存储当前屏幕的状态。
一共有3中基本状态:
* USER_ACTIVITY_SCREEN_BRIGHT 点亮屏幕
* USER_ACTIVITY_SCREEN_DIM 屏幕变暗
* USER_ACTIVITY_SCREEN_DREAM 屏保状态
从代码可以看出,屏幕变化和userActivity活动有关,它根据最后的userActivity活动的时间决定点亮屏幕、调暗屏幕或熄灭屏幕。

之前的很多方法中都会调用userActivityNoUpdateLocked方法。该方法将触发一次用户活动,以更新用户活动的时间,这样屏幕变暗和熄灭时间就会重新进行计算。
这也就是为什么用户一直操作手机,屏幕不会熄灭或者变暗的原因。

大图地址
整体来讲,个人感觉这个函数的代码写的还是挺绕的,因此还是作一个图记录一下。
大家有兴趣可以看一下。

3、updateWakefulnessLocked
从之前的代码可以看出,updateWakefulnessLocked将决定第二阶段的电源状态更新是否结束。
我们看一下updateWakefulnessLocked函数:

/**
* Updates the wakefulness of the device.
*
* This is the function that decides whether the device should start dreaming
* based on the current wake locks and user activity state.  It may modify mDirty
* if the wakefulness changes.
*
* Returns true if the wakefulness changed and we need to restart power state calculation.
*/
private boolean updateWakefulnessLocked(int dirty) {
    boolean changed = false;
    //下面的条件还是比较容易满足的,基本上只要之前的流程更改过mDirty就会进入分支
    if ((dirty & (DIRTY_WAKE_LOCKS | DIRTY_USER_ACTIVITY | DIRTY_BOOT_COMPLETED
            | DIRTY_WAKEFULNESS | DIRTY_STAY_ON | DIRTY_PROXIMITY_POSITIVE
            | DIRTY_DOCK_STATE)) != 0) {
        //如果当前的状态是唤醒的,isItBedTimeYetLocked判定不能再保持唤醒态
        if (mWakefulness == WAKEFULNESS_AWAKE && isItBedTimeYetLocked()) {
            ................
            final long time = SystemClock.uptimeMillis();
            //主要根据设置信息,判断是否满足进入Dream状态的条件
            if (shouldNapAtBedTimeLocked()) {
                //将mWakefullness的值置为WAKEFULNESS_DREAMING,修改mDirty变量,并进行通知等
                changed = napNoUpdateLocked(time, Process.SYSTEM_UID);
            } else {
                //将mWakefullness的值置为WAKEFULNESS_DOZING
                //如果系统设置了跳过Dozing态,则将mWakefullness置为WAKEFULNESS_ASLEEP
                //同时修改mDirty变量,并进行通知等
                changed = goToSleepNoUpdateLocked(time,
                        PowerManager.GO_TO_SLEEP_REASON_TIMEOUT, 0, Process.SYSTEM_UID);
            }
            //注意:napNoUpdateLocked和goToSleepNoUpdateLocked函数正常执行后,
            //都会将mSandmanSummoned(被"睡魔"眷顾了)置为true
        }
    }
    return changed;
}

从上面的代码可以看出,如果终端可以一直保持唤醒状态,或一开始就是非唤醒态,
那么mWakefulness不会发生改变,第二阶段的for循环将会break;

如果终端要从唤醒态变为非唤醒态,那么for循环将再运行一次,即重新计算一次mWakeLockSummary和mUserActivitySummary。
这么做的原因是:updateWakeLockSummaryLocked和updateUserActivitySummaryLocked函数的一些计算,与终端是否处于唤醒状态,即mWakefulness的值有关。
由于这两个函数并不会修改mWakefulness,因此在这一次运行时,updateWakefulnessLocked将返回false,即第二阶段结束。

因此,我们可以得出结论:更新电源状态的第二阶段,正常情况下最多运行两次。
在第二阶段的最后,我们看一下isItBedTimeYetLocked函数:

/**
* Returns true if the device should go to sleep now.
* Also used when exiting a dream to determine whether we should go back
* to being fully awake or else go to sleep for good.
*/
private boolean isItBedTimeYetLocked() {
    //主要由isBeingKeptAwakeLocked决定
    return mBootCompleted && !isBeingKeptAwakeLocked();
}

/**
* Returns true if the device is being kept awake by a wake lock, user activity
* or the stay on while powered setting.  We also keep the phone awake when
* the proximity sensor returns a positive result so that the device does not
* lock while in a phone call.  This function only controls whether the device
* will go to sleep or dream which is independent of whether it will be allowed
* to suspend.
*/
//根据状态,判断终端是否应该处于唤醒状态
private boolean isBeingKeptAwakeLocked() {
    return mStayOn
            || mProximityPositive
            || (mWakeLockSummary & WAKE_LOCK_STAY_AWAKE) != 0
            || (mUserActivitySummary & (USER_ACTIVITY_SCREEN_BRIGHT
                    | USER_ACTIVITY_SCREEN_DIM)) != 0
            || mScreenBrightnessBoostInProgress;
}

参考原生代码的注释,这一部分代码还是比较好理解的。

三、更新display power state
第三阶段将负责更新屏幕的显示状态。

/**
* Updates the display power state asynchronously.
* When the update is finished, mDisplayReady will be set to true.  The display
* controller posts a message to tell us when the actual display power state
* has been updated so we come back here to double-check and finish up.
*
* This function recalculates the display power state each time.
*/
private boolean updateDisplayPowerStateLocked(int dirty) {
    final boolean oldDisplayReady = mDisplayReady;
    //mDirty满足条件时,进入以下分支
    if ((dirty & (DIRTY_WAKE_LOCKS | DIRTY_USER_ACTIVITY | DIRTY_WAKEFULNESS
            | DIRTY_ACTUAL_DISPLAY_POWER_STATE_UPDATED | DIRTY_BOOT_COMPLETED
            | DIRTY_SETTINGS | DIRTY_SCREEN_BRIGHTNESS_BOOST)) != 0) {
        //根据mWakefullness、mWakeLockSummary、mUserActivitySummary等,决定屏幕的policy
        //policy定义为DisplayPowerRequest.(POLICY_OFF、POLICY_DOZE、POLICY_BRIGHT和POLICY_DIM)
        mDisplayPowerRequest.policy = getDesiredScreenPolicyLocked();

        // Determine appropriate screen brightness and auto-brightness adjustments.
        //决定屏幕的亮度
        .................

        // Update display power request.
        // 更新mDisplayPowerRequest的参数
        ...................
        //实际上调用DisplayPowerController的requestPowerState函数
        //在初始时,PMS注册了mDisplayPowerCallbacks到DisplayPowerController中,
        //当更新完成后,会回调定义的接口,重新updatePowerStateLocked
        mDisplayReady = mDisplayManagerInternal.requestPowerState(mDisplayPowerRequest,
                mRequestWaitForNegativeProximity);
        ...................
    }
    return mDisplayReady && !oldDisplayReady;
}

我们跟进一下DisplayPowerController的requestPowerState函数:

/**
* Requests a new power state.
* The controller makes a copy of the provided object and then
* begins adjusting the power state to match what was requested.
*/
public boolean requestPowerState(DisplayPowerRequest request,
        boolean waitForNegativeProximity) {
    .........
    synchronized (mLock) {
        boolean changed = false;
        //新需求增加:proximity sensor需要检测距离
        if (waitForNegativeProximity
                //原来没有这个需求
                && !mPendingWaitForNegativeProximityLocked) {
            mPendingWaitForNegativeProximityLocked = true;
            changed = true;
        }

        //以下表示,参数中的Request对于DisplayPowerController而言,是一个新的需求
        if (mPendingRequestLocked == null) {
            mPendingRequestLocked = new DisplayPowerRequest(request);
            changed = true;
        } else if (!mPendingRequestLocked.equals(request)) {
            mPendingRequestLocked.copyFrom(request);
            changed = true;
        }

        if (changed) {
            //一但有新的需求,mDisplayReadyLocked就是false,表示屏幕有待调整
            mDisplayReadyLocked = false;
        }

        //有新需求,同时有对应的request
        if (changed && !mPendingRequestChangedLocked) {
            mPendingRequestChangedLocked = true;
            //发送消息,更新屏幕状态
            //最终通过DisplayPowerController的updatePowerState函数,进行屏幕状态更新
            //这部分代码也极其复杂,暂时不在这里展开分析
            //更新屏幕状态后,将回调PMS的接口
            sendUpdatePowerStateLocked();
        }

        return mDisplayReadyLocked;
    }
}

根据requestPowerState的代码,我们知道:
当PMS传入一个新的mDisplayPowerRequest时,requestPowerState应该返回为false;当DisplayPowerController按照mDisplayPowerRequest修改完屏幕状态,再次进入回到updateDisplayPowerStateLocked函数,调用requestPowerState时才会返回true。

整体的代码流程大概可以抽象成下图:

这一阶段的代码,我们只是分析了整个过程的冰山一角,并没有分析更新屏幕状态的实际操作。
但从现有的代码可以看出,PMS的作用仅仅是维护终端电源相关状态,实际的工作还是通过类似发送Request的方式,让其它的服务协助完成。
例如:在整个阶段,PMS根据之前得到信息,构造出DisplayPowerRequest,然后发送给DisplayPowerController进行实际的处理。
当DisplayPowerController完成实际的工作(部分工作还依赖于PhoneWindowManager)后,再通知PMS进行复查。

因此PMS的定位,确实可以用一个”Manager”来形容;
负责整个终端信息的搜集和维护,然后将相应的工作指派给具体的“员工”执行;
“员工”执行完毕后,向”Manager”汇报;
“Manager”检查工作的完成情况后,然后做出下一步的指示。

四、更新dream state
updateDreamLocked函数主要用于更新屏保状态,当设备进入或者退出屏保的时候都会触发这个方法:

private void updateDreamLocked(int dirty, boolean displayBecameReady) {
    if ((dirty & (DIRTY_WAKEFULNESS
            | DIRTY_USER_ACTIVITY
            | DIRTY_WAKE_LOCKS
            | DIRTY_BOOT_COMPLETED
            | DIRTY_SETTINGS
            | DIRTY_IS_POWERED
            | DIRTY_STAY_ON
            | DIRTY_PROXIMITY_POSITIVE
            | DIRTY_BATTERY_STATE)) != 0 || displayBecameReady) {
    if (mDisplayReady) {
        //mDirty满足条件,同时屏幕状态调整完毕,才进入下一步
        scheduleSandmanLocked();
    }
}

private void scheduleSandmanLocked() {
    if (!mSandmanScheduled) {
        //mSandmanScheduled的作用就是让MessageQueue中仅保留一个MSG_SANDMAN
        mSandmanScheduled = true;
        //由handleSandman处理
        Message msg = mHandler.obtainMessage(MSG_SANDMAN);
        msg.setAsynchronous(true);
        mHandler.sendMessage(msg);
    }
}

handleSandman函数比较复杂,主要用于决定设备是否应该停留在dreaming或dozing状态。
我们分段介绍该函数的功能。

1、决定是否可以进入屏保状态

/**
* Called when the device enters or exits a dreaming or dozing state.
*/
private void handleSandman() {
    final boolean startDreaming;
    final int wakefulness;
    synchronized (mLock) {
        mSandmanScheduled = false;
        wakefulness = mWakefulness;
        //前面提到过,当updateWakefulnessLocked判断进入dozing或sleep状态时,
        //会将mSandmanSummoned置为true
        //mDisplayReady主要确保前面屏幕状态更新完毕
        if (mSandmanSummoned && mDisplayReady) {
            //判断device是否可以dream或dozing
            startDreaming = canDreamLocked() || canDozeLocked();
            mSandmanSummoned = false;
        } else {
            startDreaming = false;
        }
    }
..........

这段代码主要用于确定,设备是否可以看是dreaming。
除去前置条件的限制外,此处的结果主要由canDreamLocked和canDozeLocked决定。

我们分别看看这两个函数:

/**
* Returns true if the device is allowed to dream in its current state.
*/
private boolean canDreamLocked() {
    //mWakefulness等于WAKEFULNESS_DREAMING
    if (mWakefulness != WAKEFULNESS_DREAMING
            //设备支持dreaming
            || !mDreamsSupportedConfig
            //设置开关开启
            || !mDreamsEnabledSetting
            //屏幕熄灭
            || !mDisplayPowerRequest.isBrightOrDim()
            || (mUserActivitySummary & (USER_ACTIVITY_SCREEN_BRIGHT
                    | USER_ACTIVITY_SCREEN_DIM | USER_ACTIVITY_SCREEN_DREAM)) == 0
            //初始化完成
            || !mBootCompleted) {
        return false;
    }
    //以上条件均满足,才能进入后面的判断

    //不处于唤醒态
    if (!isBeingKeptAwakeLocked()) {
        //没充电,电源选项也未配置,不可dreaming
        if (!mIsPowered && !mDreamsEnabledOnBatteryConfig) {
            return false;
        }

        //没充电,且电池电量过低,不可dreaming
        if (!mIsPowered
                 && mDreamsBatteryLevelMinimumWhenNotPoweredConfig >= 0
                 && mBatteryLevel < mDreamsBatteryLevelMinimumWhenNotPoweredConfig) {
            return false;
        }

        //充电,但电池电量过低,不可dreaming
        if (mIsPowered
                && mDreamsBatteryLevelMinimumWhenPoweredConfig >= 0
                && mBatteryLevel < mDreamsBatteryLevelMinimumWhenPoweredConfig) {
            return false;
        }
        //充电和未充电分别有一个最低的dreaming电量门限
    }

    return true;
}

从上面的代码可以看出,dreaming除了对终端当前的状态、配置项有关外,在非唤醒状态下还与当前的电池电量有关系。

canDozeLocked函数相对简单:

private boolean canDozeLocked() {
    return mWakefulness == WAKEFULNESS_DOZING;
}

2、在必要时,进入屏保状态

// Start dreaming if needed.
final boolean isDreaming;
if (mDreamManager != null) {
    if (startDreaming) {
        //结束旧梦
        mDreamManager.stopDream(false /*immediate*/);
        //开启新梦
        mDreamManager.startDream(wakefulness == WAKEFULNESS_DOZING);
    }
    //startDream成功后,一般isDreaming就会返回true
    isDreaming = mDreamManager.isDreaming();
} else {
    isDreaming = false;
}

决定了是否可以进入屏保状态后,这一部分就开始进行实际的工作。

mDreamManager为DreamManagerService的Binder代理。
我们重点看看DreamManagerService的startDream函数,stopDream的工作内容与startDream相反,不做细致分析:

//定义于DreamManagerService的内部类中
public void startDream(boolean doze) {
    startDreamInternal(doze);
}

//定义于DreamManagerService
private void startDreamInternal(boolean doze) {
    final int userId = ActivityManager.getCurrentUser();
    //个人觉得这里应该是获取屏保对象
    final ComponentName dream = chooseDreamForUser(doze, userId);
    if (dream != null) {
        synchronized (mLock) {
            startDreamLocked(dream, false /*isTest*/, doze, userId);
        }
    }
}

private void startDreamLocked(final ComponentName name,
        final boolean isTest, final boolean canDoze, final int userId) {
    //申请的屏保与当前的一致,不用进行修改
    if (Objects.equal(mCurrentDreamName, name)
            && mCurrentDreamIsTest == isTest
            && mCurrentDreamCanDoze == canDoze
            && mCurrentDreamUserId == userId) {
        return;
    }

    //立即停止当前的屏保
    stopDreamLocked(true /*immediate*/);

    final Binder newToken = new Binder();
    mCurrentDreamToken = newToken;
    mCurrentDreamName = name;
    mCurrentDreamIsTest = isTest;
    mCurrentDreamCanDoze = canDoze;
    mCurrentDreamUserId = userId;

    mHandler.post(new Runnable() {
        @Override
        public void run() {
            //调用DreamController的startDream函数
            mController.startDream(newToken, name, isTest, canDoze, userId);
        }
    });
}

//定义于DreamController中
public void startDream(Binder token, ComponentName name,
        boolean isTest, boolean canDoze, int userId) {
    //移除当前屏保并回调通知
    stopDream(true /*immediate*/);
    .........
    try {
        ..............
        //记录dream
        mCurrentDream = new DreamRecord(token, name, isTest, canDoze, userId);
        mDreamStartTime = SystemClock.elapsedRealtime();
        ..............
        //做好屏幕相关的准备工作
        try {
            mIWindowManager.addWindowToken(token, WindowManager.LayoutParams.TYPE_DREAM);
        } catch (RemoteException ex) {
            Slog.e(TAG, "Unable to add window token for dream.", ex);
            stopDream(true /*immediate*/);
            return;
        }

        Intent intent = new Intent(DreamService.SERVICE_INTERFACE);
        intent.setComponent(name);
        intent.addFlags(Intent.FLAG_ACTIVITY_EXCLUDE_FROM_RECENTS);
        try {
            //拉起屏保服务
            if (!mContext.bindServiceAsUser(intent, mCurrentDream,
                    Context.BIND_AUTO_CREATE | Context.BIND_FOREGROUND_SERVICE,
                    new UserHandle(userId))) {
                Slog.e(TAG, "Unable to bind dream service: " + intent);
                stopDream(true /*immediate*/);
                return;
            } catch (SecurityException ex) {
                ............
                stopDream(true /*immediate*/);
                return;
            }

            mCurrentDream.mBound = true;
            //在DREAM_CONNECTION_TIMEOUT到期时,bind服务还未成功,runnable就负责结束dream
            mHandler.postDelayed(mStopUnconnectedDreamRunnable, DREAM_CONNECTION_TIMEOUT);
    } finally {
        ........
    }
}

从这部分代码我们知道了,所谓的屏保其实就是拉起一个特殊的服务。

3、更新屏保状态

// Update dream state.
synchronized (mLock) {
    // Remember the initial battery level when the dream started.
    if (startDreaming && isDreaming) {
        mBatteryLevelWhenDreamStarted = mBatteryLevel;
        ................
    }

    // If preconditions changed, wait for the next iteration to determine
    // whether the dream should continue (or be restarted).
    //例如:mDisplayReady为false时, mSandmanSummoned保持为false
    if (mSandmanSummoned || mWakefulness != wakefulness) {
        return; // wait for next cycle
    }

    .............
    // Determine whether the dream should continue.
    if (wakefulness == WAKEFULNESS_DREAMING) {
        if (isDreaming && canDreamLocked()) {
            if (mDreamsBatteryLevelDrainCutoffConfig >= 0
                    //下面这句我是懵逼的,这不是必然成立的么?
                    //也就是只要配置了mDreamsBatteryLevelDrainCutoffConfig就会成立
                    //按注释来讲,这里好歹重新取一次mBatteryLevel啊!!!怀疑是bug点
                    && mBatteryLevel < mBatteryLevelWhenDreamStarted
                            - mDreamsBatteryLevelDrainCutoffConfig
                    && !isBeingKeptAwakeLocked()) {
                // If the user activity timeout expired and the battery appears
                // to be draining faster than it is charging then stop dreaming
                // and go to sleep.
            } else {
                return; // continue dreaming
            }
        }

        // Dream has ended or will be stopped.  Update the power state.
        if (isItBedTimeYetLocked()) {
            //休眠
            goToSleepNoUpdateLocked(SystemClock.uptimeMillis(),
                    PowerManager.GO_TO_SLEEP_REASON_TIMEOUT, 0, Process.SYSTEM_UID);
            updatePowerStateLocked();
        } else {
            //唤醒
            wakeUpNoUpdateLocked(SystemClock.uptimeMillis(), "android.server.power:DREAM",
                    Process.SYSTEM_UID, mContext.getOpPackageName(), Process.SYSTEM_UID);
            updatePowerStateLocked();
        }
    } else if (wakefulness == WAKEFULNESS_DOZING) {
        if (isDreaming) {
            return; // continue dozing
        }

        // Doze has ended or will be stopped.  Update the power state.
        reallyGoToSleepNoUpdateLocked(SystemClock.uptimeMillis(), Process.SYSTEM_UID);
        updatePowerStateLocked();
    }
}

// Stop dream.
//执行到这里说明退出了dreaming状态,如果之前拉起过屏保服务,此时应该停止它
if (isDreaming) {
    mDreamManager.stopDream(false /*immediate*/);
}
...........

以上是PMS更新屏保状态的基本流程,整体来看相当的繁琐。
我们还是用一个图来整体整理一下:

大图链接
这部分代码最后太乱,每次更新状态后都会重新调用updatePowerStateLocked,然后再次进入到handleSandman函数中。
这种反复地递归调用,比较难以把控。

五、更新suspend blocker
updateSuspendBlockerLocked函数主要根据之前流程的执行结果,持有或者释放CPU和屏幕的锁。
我们一起来看看对应的函数:

private void updateSuspendBlockerLocked() {
    //根据是否有CPU的wakelock,来决定cpu是保持否唤醒 
    final boolean needWakeLockSuspendBlocker = ((mWakeLockSummary & WAKE_LOCK_CPU) != 0);

    //根据前面屏幕相关的状态,来决定是否需要持有屏幕的锁
    final boolean needDisplaySuspendBlocker = needDisplaySuspendBlockerLocked();

    //屏幕如果不需要保持开启状态,那么可自动熄灭
    final boolean autoSuspend = !needDisplaySuspendBlocker;

    //应该是表示屏幕是否是可交互的
    final boolean interactive = mDisplayPowerRequest.isBrightOrDim();

    // Disable auto-suspend if needed.
    //autoSuspend为false,说明屏幕还需要点亮
    if (!autoSuspend && mDecoupleHalAutoSuspendModeFromDisplayConfig) {
        //通过native函数,调用底层的autosuspend_disable
        setHalAutoSuspendModeLocked(false);
    }

    // First acquire suspend blockers if needed.
    //在需要的情况下,获取CPU和屏幕的锁
    if (needWakeLockSuspendBlocker && !mHoldingWakeLockSuspendBlocker) {
        mWakeLockSuspendBlocker.acquire();
        mHoldingWakeLockSuspendBlocker = true;
    }
    if (needDisplaySuspendBlocker && !mHoldingDisplaySuspendBlocker) {
        mDisplaySuspendBlocker.acquire();
        mHoldingDisplaySuspendBlocker = true;
    }

    // Inform the power HAL about interactive mode.
    if (mDecoupleHalInteractiveModeFromDisplayConfig) {
        if (interactive || mDisplayReady) {
            //调用底层动态库的setInteractive函数,决定终端是否可以进行交互
            setHalInteractiveModeLocked(interactive);
        }
    }

    // Then release suspend blockers if needed.
    //如果不需要,则释放CPU和屏幕的锁 
    if (!needWakeLockSuspendBlocker && mHoldingWakeLockSuspendBlocker) {
        mWakeLockSuspendBlocker.release();
        mHoldingWakeLockSuspendBlocker = false;
    }
    if (!needDisplaySuspendBlocker && mHoldingDisplaySuspendBlocker) {
        mDisplaySuspendBlocker.release();
        mHoldingDisplaySuspendBlocker = false;
    }

    // Enable auto-suspend if needed.
    //如果需要设置自动休眠模式
    if (autoSuspend && mDecoupleHalAutoSuspendModeFromDisplayConfig) {
        setHalAutoSuspendModeLocked(true);
    }
}

从上面的代码可以看出PMS是非常依赖于native层的,真实的持锁、释放锁、设置交互状态等工作,均是移交到native层进行操作。
我们以mWakeLockSuspendBlocker的处理流程为例,看看native的调用过程:

..........
mWakeLockSuspendBlocker = createSuspendBlockerLocked("PowerManagerService.WakeLocks");
.........

之前的博客也提到过,PMS在其构造函数中调用createSuspendBlockerLocked函数,创建出了mWakeLockSuspendBlocker:

private SuspendBlocker createSuspendBlockerLocked(String name) {
    //实际对象为PMS内部类SuspendBlockerImpl
    SuspendBlocker suspendBlocker = new SuspendBlockerImpl(name);
    mSuspendBlockers.add(suspendBlocker);
    return suspendBlocker;
}

从上面的代码,我们知道当PMS需要获取底层锁时,调用的是SuspendBlockerImpl的acquire函数:

public void acquire() {
    synchronized (this) {
        mReferenceCount += 1;
        if (mReferenceCount == 1) {
            .......
            //调用到了native层
            nativeAcquireSuspendBlocker(mName);
        }
    }
}

在native层的com_android_server_power_PowerManagerService.cpp中,对应的native函数为:

static void nativeAcquireSuspendBlocker(JNIEnv *env, jclass /* clazz */, jstring nameStr) {
    ScopedUtfChars name(env, nameStr);
    //获取的是PARTIAL_WAKE_LOCK的类型,即保持CPU唤醒的
    acquire_wake_lock(PARTIAL_WAKE_LOCK, name.c_str());
}

从这里的代码我们不难发现,尽管PMS定义了不同的WakeLock等级,但当通过PMS的native函数调用HAL层函数acquire_wake_lock时,使用的都是PARTIAL_WAKE_LOCK。
个人觉得这是可以理解的,当其它进程向PMS申请保持屏幕唤醒的Framework层WakeLock后,PMS在Framework层就进行了对应的处理,例如将请求信息等地交给DisplayPowerController等处理。因此,对于底层的HAL层而言,只需要关注CPU是否需要保持唤醒即可。
HAL层函数acquire_wake_lock,最后会向/sys/power/wake_lock节点进行write操作。

总结
至此,updatePowerStateLocked的基本流程介绍完毕,大体上如下图所示:

通过其中的源码,我们也能看出仅管理当前的状态,涉及的细节就非常的琐碎。
而屏幕和CPU的实际控制,还牵扯到大量其它对象和HAL层代码。
Android电源的管理实际上是基于Linux电源管理策略的,因此若要真正掌握,还需要对Linux的电源管理策略作进一步的了解。
由于个人水平有限,目前还无法高屋建瓴地整体分析宏观的电源管理架构,细节也有一些遗漏。
后续争取以此博客为基础,不断迭代,以求更进一步地了解PMS的知识。

展开阅读全文

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