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

前面的博客中，我们已经分析过，当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(
                        mLowPowerModeListeners);
            }
            for (int i=0; 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的知识。