Android休眠流程

1. 概述

   设备的休眠是功耗分析中的重要篇章，有些问题经常会涉及到系统无法休眠，经常被唤醒等情况。在这里将从代码角度来分析下Android系统休眠和唤醒的机制，而本篇将着重阐述休眠机制。

Android系统的电源管理子系统是已Linux的电源管理系统为基础，针对现实问题又进行了改造，而这里的现实问题来自于PC和移动设备的差异，其核心在于什么时候休眠，什么时候唤醒。在PC系统中，什么时候让系统进入休眠（通常是STR、Standby、Hibernate等suspend操作）这个问题很容易理解：答案就是由用户在其不再使用时触发。

然而移动设备的特性决定了用户可能随时随地会使用设备，那么休眠的时机就变得非常不明确了。于是Android上提出了Opportunistic suspend这个概念，通俗的讲就是逮住机会就赶紧休眠一会儿直到下次被唤醒，而这个机会就是系统没有任务需要处理的时候。由此就衍生除了autosleep机制和wake source的概念。Android的休眠是一种自动休眠，当系统中不存在唤醒源时就进行系统整体休眠。相比于Linux内核中复杂的单独模块休眠管理（Dynamic PM），Android的此套设计方式简单粗暴，但是实实在在的解决了移动设备上面临的燃眉之急。

2.自动休眠

2. 1.Frameworks层

备注：自动休眠一定不能插上usb抓取log，因插上usb不会进入休眠模式。

系统休眠又用户主动发起的关系并不是很大，在用户和应用的行为中，主动通过power键发起灭屏或者是调用PowerManager的goToSleep接口来进行系统休眠是较常用的操作，其他也没有更多的手段。而系统休眠大多是系统主动检测并发起休眠流程，所以本篇中就不涉及上层的流程了，直接从Frameworks开始。

Frameworks层这部分的设计思想比较简单，主要是：电源管理通过监测display的状态，当灭屏时则发起休眠的流程，调用native层的方法继续往下走。这里就很好的体现了前文提到的Opportunistic suspend概念，伺机休眠这里的“机”的第一层就是以灭屏作为契机的。果然是简单粗暴的判断，但是非常实用，从用户角度来将，灭屏的现象确实是让设备休眠的理想触发。当然，在灭屏时需要后台处理任务的情况也是存在，所以在后面流程中会继续判断是否真正能够进入休眠。接下来从代码角度解读下frameworks层的实现。

  流程就先从灭屏开始看，系统中除了PowerManagerService外还有个叫做DisplayManagerService的核心服务来管理display相关的电源状态，它也是在SystemServer中启动起来的。在PowerManagerService中systemReady方法中会去初始化DisplayManagerService

frameworks/base/services/core/java/com/android/server/power/PowerManagerService.java

// Initialize display power management.mDisplayManagerInternal.initPowerManagement(        mDisplayPowerCallbacks, mHandler, sensorManager);

DisplayManagerService中的initPowerManagement相关部分如下：

private final class LocalService extends DisplayManagerInternal {    @Override    public void initPowerManagement(final DisplayPowerCallbacks callbacks, Handler handler,            SensorManager sensorManager) {        synchronized (mSyncRoot) {            DisplayBlanker blanker = new DisplayBlanker() {                @Override                public void requestDisplayState(int state, int brightness) {                    // The order of operations is important for legacy reasons.                    if (state == Display.STATE_OFF) {                        requestGlobalDisplayStateInternal(state, brightness);                    }                    callbacks.onDisplayStateChange(state);                    if (state != Display.STATE_OFF) {                        requestGlobalDisplayStateInternal(state, brightness);                    }                }            };            mDisplayPowerController = new DisplayPowerController(                    mContext, callbacks, handler, sensorManager, blanker);        }        mHandler.sendEmptyMessage(MSG_LOAD_BRIGHTNESS_CONFIGURATION);    }

实现了DisplayBlanker接口，并重写了其requestDisplayState方法，在此方法中又调用DisplayPowerCallbacks接口的onDisplayStateChange方法来进行display发生变化之后的操作。这一段为整个frameworks流程中的核心部分也是流程的中间部分，接下来补上它的头和尾。

首先是display改变的消息传递，也就是代码流程中如何会调用到DisplayBlanker接口的requestDisplayState，来看图就可以了：

首先是在DisplayPowerController中收到MSG_UPDATE_POWER_STATE消息，随后经过一系列的回调了DisplayBlanker接口的requestDisplayState，其中每个细节不是这里的重点就不展开一一分析了。然后是尾，DisplayPowerCallbacks接口的onDisplayStateChange方法在PowerManagerService中

public void onDisplayStateChange(int state) {    // This method is only needed to support legacy display blanking behavior    // where the display's power state is coupled to suspend or to the power HAL.    // The order of operations matters here.    synchronized (mLock) {        if (mDisplayState != state) {// display的状态发生改变            mDisplayState = state;            if (state == Display.STATE_OFF) {// 灭屏                if (!mDecoupleHalInteractiveModeFromDisplayConfig) {// 默认false                    setHalInteractiveModeLocked(false);// 关闭交互模式                }                if (!mDecoupleHalAutoSuspendModeFromDisplayConfig) {// 默认false                    setHalAutoSuspendModeLocked(true);// 开启autosleep模式                }            } else {// 亮屏                if (!mDecoupleHalAutoSuspendModeFromDisplayConfig) {                    setHalAutoSuspendModeLocked(false);// 关闭autosleep模式                }                if (!mDecoupleHalInteractiveModeFromDisplayConfig) {                    setHalInteractiveModeLocked(true);// 开启交互模式                }            }        }    }}

这一段中有一个非常重要的核心：前面提到了将灭屏作为休眠发起的条件，也就是说将灭屏和休眠作为了耦合的关系，而这里提供了解耦的操作，可以在代码配置中来选择是否要解耦。判断的依据就是mDecoupleHalAutoSuspendModeFromDisplayConfig这个变量，它的默认值定义在frameworks/base/core/res/res/values/config.xml中：

false

解读：默认情况下将suspend流程和display的状态耦合在一起，默认为false（不解耦），在默认情况下，在屏幕off之后调用启用autosuspend，在屏幕on之前关闭autosuspend_enable。而如果解耦，那么suspend的流程将被独立调用而不管屏幕状态，在此模式下就算是屏幕on也允许系统休眠。

这一段代码中还包括了另外一个操作，setHalInteractiveModeLocked来设置系统可交互模式，由mDecoupleHalInteractiveModeFromDisplayConfig这个变量来控制和display的耦合关系。同样附上这个默认值的定义：

false

解读：这里描述了系统的可交互模式和display的耦合关系。当设置为false时，两者为耦合的关系，在display状态on之前setInteractive(…, true)设置为可交互；在display状态为off之后设置为不可交互。而如果为解耦状态，那么交互模式也将可以被独立设置不论display的状态如何。

我们还是来继续看auto sleep的流程，当灭屏时，调用PowerManagerService的setHalAutoSuspendModeLocked(true)

frameworks/base/services/core/java/com/android/server/power/PowerManagerService.java

private void setHalAutoSuspendModeLocked(boolean enable) {    if (enable != mHalAutoSuspendModeEnabled) {        if (DEBUG) {            Slog.d(TAG, "Setting HAL auto-suspend mode to " + enable);        }        mHalAutoSuspendModeEnabled = enable;        Trace.traceBegin(Trace.TRACE_TAG_POWER, "setHalAutoSuspend(" + enable + ")");        try {            mNativeWrapper.nativeSetAutoSuspend(enable);        } finally {            Trace.traceEnd(Trace.TRACE_TAG_POWER);        }    }}

这里只是做了些判断和加调试代码，然后将流程通过nativeSetAutoSuspend带入到了native库中。

2.2. Native层

根据JNI的机制可以找到代码进入到了com_android_server_power_PowerManagerService.cpp中的nativeSetAutoSuspend中：

frameworks/base/services/core/jni/com_android_server_power_PowerManagerService.cpp

static void nativeSetAutoSuspend(JNIEnv* /* env /, jclass / clazz */, jboolean enable) {

if (enable) {

android::base::Timer t;

enableAutoSuspend();

if (t.duration() > 100ms) {

ALOGD(“Excessive delay in autosuspend_enable() while turning screen off”);

}

} else {

android::base::Timer t;

disableAutoSuspend();

if (t.duration() > 100ms) {

ALOGD(“Excessive delay in autosuspend_disable() while turning screen on”);

}

}

}

当灭屏时（默认情况下）调用autosuspend_enable()，然后进一步的实现在hal文件中，源代码位于system/hardware/interfaces/suspend/1.0/default/目录下。

2.2.1 休眠机制初始化

来看一下开启自动挂起模式的实现方法——enableAutoSuspend

com_android_server_power_PowerManagerService.cpp

void enableAutoSuspend() {

static bool enabled = false;

//suspendService != nullptr && suspendService->enableAutosuspend()：从后面的代码可以看到这个值决定了enlable的值，在开机执行一次

if (!enabled) {

sp suspendControl = getSuspendControl();

suspendControl->enableAutosuspend(&enabled);

}

{    std::lock_guard lock(gSuspendMutex);    if (gSuspendBlocker) {        gSuspendBlocker->release();        gSuspendBlocker.clear();    }}

}

sp getSuspendControl() {

static std::once_flag suspendControlFlag;

std::call_once(suspendControlFlag, {

while(gSuspendControl == nullptr) {

sp control =

defaultServiceManager()->getService(String16(“suspend_control”));

if (control != nullptr) {

gSuspendControl = interface_cast(control);

}

}

});

return gSuspendControl;

}

这里有一个难点，通过getSuspendControl方法获得的ISuspendControlService实现类是什么？ 请注意getSuspendControl方法里的这条语句： defaultServiceManager()->getService(String16(“suspend_control”))，这是一个典型的Binder调用，它请求了服务名称为 suspend_control 的远端服务。注册名称为suspend_control的服务到底是谁，我们可以在/system/hardware/interfaces/suspend/1.0/default/main.cpp中找到答案。

sp suspendControl = new SuspendControlService();

auto controlStatus = android::defaultServiceManager()->addService(

android::String16(“suspend_control”), suspendControl);

可以清楚的看到，SuspendControlService就是我们要寻找的答案。

SuspendControlService.cpp

binder::Status SuspendControlService::enableAutosuspend(bool* _aidl_return) {

//wp 升级为 sp，这条语句牵涉到 android 智能指针相关的知识点 promote方法可以将弱指针升级为强指针

const auto suspendService = mSuspend.promote();

//调用到了 SystemSuspend.cpp 的enableAutosuspend 方法

return retOk(suspendService != nullptr && suspendService->enableAutosuspend(), _aidl_return);

}

SuspendControlService.cpp

binder::Status retOk(const T& value, T* ret_val) {

*ret_val = value;

return binder::Status::ok();

}

SystemSuspend.cpp

bool SystemSuspend::enableAutosuspend() {

static bool initialized = false;

if (initialized) {

LOG(ERROR)