自从接触Android系统已经一年多了，这段时间内对于Android系统的Framework层的各个模块都有过接触，有时也做过分析，但是一直没能形成一个总结性的东西。这次下定决心，好好整理整理对于Android系统的学习梳理一下自己的思路。本文一方面是为了自己梳理下知识，文中涉及的内容，基本是拾人牙慧，很少有自己的东西，最多也就算是自己的总结；除此作用之外，如果能为后来者引玉，也算是一点功德吧。这次首先是对Android系统中的PowerManagerService进行下整理。之所以先选择PowerManagerService，是因为这个模块相对于Android系统中其他的模块而言，与系统其他的模块之间的交互较少，而且Framework中的PowerManagerService模块是由Google开发并维护的，虽然以Linux Kernel的Power为基础，但是它们之间的耦合度低，完全可以把两者分开，单独进行分析也不会造成困惑。接下来，我会从不同的角度，分别介绍下PowerManagerService的功能。还是先来看看PowerManagerService在Framework中的目录结构吧。 PowerManagerService在Android4.2源码中的位置是：/frameworks/base/services/java/com/android/server/power/，在这个目录下有以下文件： DisplayBlanker.java DisplayPowerController.java DisplayPowerRequest.java DisplayPowerState.java ElectronBeam.java Notifier.java PowerManagerService.java RampAnimator.java ScreenOnBlocker.java ShutdownThread.java SuspendBlocker.java WirelessChargerDetector.java 这些文件中，个人认为对于PoweManagerService而言除了本身的代码，较为重要的有DisplayPowerController.java,DisPlayPowerState.java， Notifier.java. 而DisplayPowerRequest相当于一个辅助类，用来存储一些统一的属性和变量，让PowerManagerService和DisplayPoerController, DisplayPowerState交互时 能够使用统一的变量。 另外，还有及个接口文件SuspendBlocker.java,DisplayBlanker.java, ScreenOnBlanker.java。其次就是ShutdownThread.java, WirelessChargerDetector.java,RampAnimator.java, ElectronBeam.java. 下面，就先逐一介绍下PowerManagerService在Framework中的这些文件： PowerManagerService.java:  主要是计算系统中和Power相关的计算，然后决策系统应该如何反应。同时协调Power如何与系统其它模块的交互，比如没有用户 　　　　　　　　　　　　　活动时，屏幕变暗等等。 DisplayPowerController.java：管理Display设备的电源状态。仅在PowerManagerService中实例化了一个对象，它算是PowerManagerService的一部分，只不过是独立出 　　　　　　　　　　　　来了而已。主要处理和距离传感器，灯光传感器，以及包括关屏在内的一些动画，通过异步回调的方式来通知PowerManagerService某些事情发生了变化。 DisPlayPowerState.java：在本质上类似于View，只不过用来描述一个display的属性，当这些属性发生变化时，可以通过一个序列化的命令，让这些和display电源状态的属性 　　　　　　　　　　一起产生变化。这个类的对象只能被DispalyPowerController的Looper持有。而这个Looper应该就是PowerManagerService中新建的一个HandlerThread中的Looper。 　　　　　　　　　　和PowerManager相关的，包括DisplayPowerState和DisplayPowerController相关的消息处理应该都可以通过这个HandlerThread进行运转的。 Notifier.java:　　将Power Manager state的重要变化通过broadcast发送出去。 接下来就说说三个接口文件 SuspendBlocker.java： 相当于一个partial wake lock。在内部使用，避免了使用上层的唤醒锁机制 DisplayBlanker.java：主要功能一是BLANK DISPLAY: The display is blanked, but display memory is maintained and new data can be entered；而是UNBLANK DISPLAY: 　　　　　　　　　　The display is restored/turned to active state.（不知道这两个英文的解释是否恰当，还有待验证）。 ScreenOnBlanker.java：描述了一种较为低级的blocker机制，主要用于关屏或者隐藏屏幕内容，直到window manager准备好新的内容 DisplayPowerRequest.java：描述了一些对于display电源状态的请求。 最后看看剩余的这些类： ShutDownThread.java:　　主要功能就是关机和重启，当我想要执行重启或者关机的时候，这个新城就会被启动。 ElectronBeam.java：　　负责屏幕由开到关，或者由关到开的一些GL动画。在DisplayPowerController管理 WirelessChargerDetector.java：和无线充电相关的东西，没有细看。 每个文件的大致功能就是这样的，也许有些地方不是很恰当，还是需要仔细阅读源码，才能确切地知道到底是怎么回事，有些功能到底是如何实现的。   　　　　先从交互的角度去看看PowerManagerService的功能。在这里的交互是说PowerManagerService与应用程序或者Framework中其他的模块的交互，而不是指和用户之间的直接交互。和用户之间牵涉到交互的内容，在文章的最后也稍微有点介绍。下面就分成两个小节，对于PowerManagerService的交互作以总结。首先： 　　　　a). 与应用程序之间的交互 在Android中应用程序并不是直接同PowerManagerService交互的，而是通过PowerManager间接地与PowerManagerService打交道。不过在使用PowerManager和 PowerManager,WakeLock之前，我们要首先在APP中申请使用如下权限： <uses-permission android:name = "android.permission.WAKE_LOCK" /> <uses-permission android:name = "android.permission.DEVICE_POWER"/> 而APP能够与PowerManager做哪些交互，在Android提供的开发文档中给了我们答案。我们可以看到PowerManage提供了如下公共的接口： PowerManager PowerManagerService goToSleep(long time) goToSleep(long eventTime, int reason) isScreenOn() isScreenOn() reboot(String reason) reboot(boolean confirm, String reason, boolean wait) userActivity(long when, boolean noChangeLights) userActivity(long eventTime, int event, int flags) wakeUp(long time) wakeUp(long eventTime) 在这个表格中，仅仅列出了PowerManager的公开方法中的其中五个，同时列出在PowerManagerService中对应的方法。这里列出的，是与PowerManagerService关系比较紧密的方法，其余的和PowerManager相关的东西会在接下来，慢慢地都谈到的。如果阅读PowerManager的源码的话，你会很容易发现，其实PowerManager的方法在实现的过程中，都是通过调用PowerManagerService相应的函数来实现的。PowerManager就像是PowerManagerService的"代理类"。这里略过PowerManager是如何通过binder与PowerManagerService进行通信的。下面，我们逐一对PowerManagerService中这几个函数的实现进行下简单的分析，在对这些函数分析之前，我觉得还是先对代码中使用的一些变量作以简要的说明为好。其实，在PowerManagerService中绝大部分变量通过名字就能大概知道其意义，不过还有几个较为重要的还是仔细说说为好，首先是重要的变量mDirty,根据代码的注释是说，用来表示power state的变化，而这样的变化在系统中一共定义了12个，每一个state对应一个固定的数字，都是2的倍数。这样的话，当有若干个状态一起变化时，他们按位取或，这样得到的结果既是唯一的，又能准去标示出各个状态的变化。此外还有一个mWakefulness的变量，它用来标示的是device处于的一种状态，是醒着的还是睡眠中，或者处于两者之间的一种状态。这个状态是和 display的电源状态是不同的，display的电源状态是独立管理的。这个变量用来标示DIRTY_WAKEFULNESS这个power state下的一个具体的内容。比如说，系统从进入Draaming的时候，首先变化的是mDirty，在mDirty中对DIRTY_WAKEFULNESS位置位，这说明系统中的DIRTY_WAKEFULNESS发生了变化；此时，仅仅是知道DIRTY_WAKEFULNESS发生了变化，但是不知道wakefulness到底发生了怎样的变化，如果需要进一步知道系统的wakefulness变成了什么，就需要查看下mWakefulness的内容就知道了。相当于是对DIRTY_WAKEFULNESS的一个补充说明吧。 像这样的算是补充性质的变量还有mWakeLockSummary和mUserActivitySummary。好了，接下来我们可以从goToSleep(long eventTime, int reason)开始了，代码如下： 1 @Override // Binder call 2 public void goToSleep(long eventTime, int reason) { 3 if (eventTime > SystemClock.uptimeMillis()) { 4 throw new IllegalArgumentException("event time must not be in the future"); 5 } 6 　　　　　　//权限检查 7 mContext.enforceCallingOrSelfPermission(android.Manifest.permission.DEVICE_POWER, null); 8 9 final long ident = Binder.clearCallingIdentity(); 10 try { 11 goToSleepInternal(eventTime, reason);//这里会调用函数的实现，在PowerManagerService中有很多类似的使用方式，之后的代码中我会直接列出对应方法的实现 12 } finally { 13 Binder.restoreCallingIdentity(ident); 14 } 15 } 16 17 private void goToSleepInternal(long eventTime, int reason) { 18 synchronized (mLock) { 19 if (goToSleepNoUpdateLocked(eventTime, reason)) { 20 updatePowerStateLocked(); 21 } 22 } 23 } 　对于文中的代码，我会在不影响阅读的情况下，尽量地少。在这段代码中，涉及到另个重要的函数goToSleepNoUpdateLocked()和updatePowerStateLocked()，而 goToSleepNoUpdateLocked是goToSleep功能的计算者，来决定是否要休眠，而updatePowerStateLocked函数算是功能的执行者，而且这个执行者同时负责执行了很多其他的功能， 在总结的时候会着重分析这个函数。这里先看 goToSleepNoUpdateLocked方法的代码： 1 private boolean goToSleepNoUpdateLocked(long eventTime, int reason) { 2 if (DEBUG_SPEW) { 3 Slog.d(TAG, "goToSleepNoUpdateLocked: eventTime=" + eventTime + ", reason=" + reason); 4 } 5 6 if (eventTime < mLastWakeTime || mWakefulness == WAKEFULNESS_ASLEEP 7 || !mBootCompleted || !mSystemReady) { 8 return false; 9 } 10 11 switch (reason) { 12 case PowerManager.GO_TO_SLEEP_REASON_DEVICE_ADMIN: 13 Slog.i(TAG, "Going to sleep due to device administration policy..."); 14 break; 15 case PowerManager.GO_TO_SLEEP_REASON_TIMEOUT: 16 Slog.i(TAG, "Going to sleep due to screen timeout..."); 17 break; 18 default: 19 Slog.i(TAG, "Going to sleep by user request..."); 20 reason = PowerManager.GO_TO_SLEEP_REASON_USER; 21 break; 22 } 23 24 sendPendingNotificationsLocked(); 25 mNotifier.onGoToSleepStarted(reason); 26 mSendGoToSleepFinishedNotificationWhenReady = true; 27 28 mLastSleepTime = eventTime; 29 mDirty |= DIRTY_WAKEFULNESS; 30 mWakefulness = WAKEFULNESS_ASLEEP; 31 32 // Report the number of wake locks that will be cleared by going to sleep. 33 int numWakeLocksCleared = 0; 34 final int numWakeLocks = mWakeLocks.size(); 35 for (int i = 0; i < numWakeLocks; i++) { 36 final WakeLock wakeLock = mWakeLocks.get(i); 37 switch (wakeLock.mFlags & PowerManager.WAKE_LOCK_LEVEL_MASK) { 38 case PowerManager.FULL_WAKE_LOCK: 39 case PowerManager.SCREEN_BRIGHT_WAKE_LOCK: 40 case PowerManager.SCREEN_DIM_WAKE_LOCK: 41 numWakeLocksCleared += 1; 42 break; 43 } 44 } 45 EventLog.writeEvent(EventLogTags.POWER_SLEEP_REQUESTED, numWakeLocksCleared); 46 return true; 47 } 通过这段代码发现，其实这里并没有真正地让device进行sleep，仅仅只是把PowerManagerService中一些必要的属性进行了赋值，等会在分析updatePowerStateLocked的时候， 再给出解释。在PowerManagerService的代码中，有很多的方法的名字中都含有xxxNoUpdateLocked这样的后缀，我觉得这样做大概是因为，都类似于goToSleepNoUpdateLocked方法， 并没有真正地执行方法名字所描述的功能，仅仅是更新了一些必要的属性。 所以在Android系统中可以把多个power state属性的多个变化放在一起共同执行的，而真正的功能执行者就是 updatePowerStateLocked。 　　　　b).与系统其它模块之间的交互 PowerManagerService作为Android系统Framework中重要的能源管理模块，除了与应用程序交互之外，还要与系统中其它模块配合，在提供良好的能源管理同时提供友好的用户体验。 Android系统除了提供公共接口与其它模块交互外，还提供BroadCast机制，用来对系统中发生的重要变化做出反应。下表列出了，在PowerManagerService中注册的Receiver，以及 这些Receiver监听的事件，和处理方法： BatteryReceiver ACTION_BATTERY_CHANGED handleBatterStateChangeLocked() BootCompleteReceiver ACTION_BOOT_COMPLETED startWatchingForBootAnimationFinished() userSwitchReceiver ACTION_USER_SWITCHED handleSettingsChangedLocked DockReceiver ACTION_DOCK_EVENT updatePowerStateLocked DreamReceiver ACTION_DREAMING_STARTED 
ACTION_DREAMING_STOPPED scheduleSandmanLocked  PowerManagerService中除了注册了这五个Receiver之外，还定义了一个SettingsObserver，用于监视系统中以下属性的变化： SCREENSAVER_ENABLE，屏保的功能开启 SCREENSAVER_ACTIVE_ON_SLEEP，在睡眠时屏保启动 SCREENSAVER_ACTIVE_ON_DOCK，连接底座并且屏保启动 SCREEN_OFF_TIMEOUT，休眠时间 STAY_ON_PLUGGED_IN，有插入并且屏幕开启 SCREEN_BRIGHTNESS，屏幕的亮度 SCREEN_BRIGHTNESS_MODE，屏幕亮度的模式 当以上这些属性发生变化时，SettingObserver都会监视到，并且调用SettingObserver的onChange方法， 1 public void onChange(boolean selfChange, Uri uri) { 2 synchronized (mLock) { 3 handleSettingsChangedLocked(); 4 } 5 } 以上内容，说明PowerManagerService 不能能够接收用户的请求，被动地去做一些操作，还要主动监视系统中一些重要的属性的变化，和重要的事件的发生。 无论是处理主动还是被动的操作，在上面都一一列出了对应的处理函数。 虽然对这些方法没有逐一说明，但是通过上面的goToSleepNoUpdateLocke的例子， 自己阅读下应该没有问题的。如果看过这些方法之后，你会发现一个很重要的共同点，就是PowerManagerService在处理各种各样的事件的时候，最终都会经过 这么一个方法updatePowerStateLocked。 在上面这些内容中，我们说各种变化的时候，常用的一个词就是power state，而在updatePowerStateLocked方法 的名字中，我们很容易推测出这个方法要做的事情，就是把PowerManagerService中发生的变化，能够影响到Power Management的都要放在一起进行更新，让 其真正地起作用。    这么说下去，还是有点空口白话的意味，我们还是从代码中一点一点去阅读效果会好些。 updatePowerStateLocked 1 /** 2 * Updates the global power state based on dirty bits recorded in mDirty. 3 * 4 * This is the main function that performs power state transitions. 5 * We centralize them here so that we can recompute the power state completely 6 * each time something important changes, and ensure that we do it the same 7 * way each time. The point is to gather all of the transition logic here. 8 */ 9 private void updatePowerStateLocked() { 10 if (!mSystemReady || mDirty == 0) {//如果系统没有准备好，或者power state没有发生任何变化，这个方法可以不用执行的 11 return; 12 } 13 14 // Phase 0: Basic state updates. 15 updateIsPoweredLocked(mDirty); 16 updateStayOnLocked(mDirty); 17 18 // Phase 1: Update wakefulness. 19 // Loop because the wake lock and user activity computations are influenced 20 // by changes in wakefulness. 21 final long now = SystemClock.uptimeMillis(); 22 int dirtyPhase2 = 0; 23 for (;;) { 24 int dirtyPhase1 = mDirty; 25 dirtyPhase2 |= dirtyPhase1; 26 mDirty = 0; 27 28 updateWakeLockSummaryLocked(dirtyPhase1);//在前面解释几个变量的时候，就已经提到了WakeLockSummary和UserActivitySummary， 29 updateUserActivitySummaryLocked(now, dirtyPhase1);//在这里的两个方法中已经开始用到了。 想必通过方法名，大概也已经有所了解其功能了。 30 if (!updateWakefulnessLocked(dirtyPhase1)) { 31 break; 32 } 33 } 34 35 // Phase 2: Update dreams and display power state. 36 updateDreamLocked(dirtyPhase2); 37 updateDisplayPowerStateLocked(dirtyPhase2); 38 39 // Phase 3: Send notifications, if needed. 40 if (mDisplayReady) { 41 sendPendingNotificationsLocked(); 42 } 43 44 // Phase 4: Update suspend blocker. 45 // Because we might release the last suspend blocker here, we need to make sure 46 // we finished everything else first! 47 updateSuspendBlockerLocked(); 48 } 从这段代码中，很容易就看出，这个方法对于power state的更新时分成四个阶段进行的。从注释中看到，第一阶段： 基本状态的更新； 第二阶段：显示内容的更新； 第三阶段：dream和display状态的更新；第四阶段：suspend blocker的更新。之所以放在最后一步才进行suspend blocker的更新， 是因为在这里可能会释放suspend blocker。 对这个方法有了大概的了解之后，我们开始这个PowerManagerService中重要的函数进行分析吧，先看第一阶段的更新： updateIsPoweredLocked开始，这个方法的功能是判断设备是否处于充电状态中，如果DIRTY_BATTERY_STATE发生了变化，说明设备的电池的状态有过改变， 然后通过对比和判断（通过电池的状态前后的变化和充电状态的变化来判断），确定是否处于在充电，充电方式的改变也会在mDirty中标记出来。同时根据充电状态 的变化进行一些相应的处理，同时是否在充电或者充电方式的改变都会认为是一次用户事件或者叫用户活动的发生。 updateStayOnLocked用来更新device是否开启状态。也是通过mStayOn的前后变化作为判断依据，如果device的属性Settings.Global.STAY_ON_WHILE_PLUGGED_IN 为置位，并且没有达到电池充电时持续开屏时间的最大值（也就是说，在插入电源后的一段时间内保持开屏状态），那么mStayOn为真。 上面这两个方法完成了第一阶段的更新，通过代码我们可以看到，主要是进行了充电状态的判断，然后根据充电的状态更新了一些必要的属性的变化，同时也在更新mDirty。 在看第二阶段是如何变化的： 在前面说到过mWakefuless是表示device处于的醒着或睡眠或两者之间的一种状态，这种状态会影响到wake lock和user activity的计算，所以要进行更新。第二阶段是通过一个 死循环进行了，只有当updateWakefulnessLocked返回为false的时候，才能跳出这个循环。刚刚进入这个循环的时候，把mDirty进行了重置，这点从侧面说明了这次updatePowerState 之后，会把前面所有发生的power state执行，不会让其影响到下一次的变化。同时也在为下一次的power state从头开始更新做好准备。updateWakeLockSummaryLocked和 updateUserActivitySummaryLocked代码很容易明白，要注意的是在updateUserActivitySummaryLocked在中锁屏时间和变暗时间的的比较。假如说在系统中设置的睡眠时间是30s， 而在PowerManagerService中默认的SCREEN_DIM_DURATION是7s，这就意味着：如果没有用户活动的话，在第23s，设备的屏幕开始变换，持续7s时间，然后屏幕开始关闭。 下面就是开始看看，在何时才能跳出这个循环，主要就是看updateWakefulnessLocked的返回值，先看看其代码： 1 /** 2 * Updates the wakefulness of the device. 3 * 4 * This is the function that decides whether the device should start napping//这个方法的功能是：根据当前的wakeLocks和用户的活动情况，来决定设备是否需要小憩 5 * based on the current wake locks and user activity state. It may modify mDirty 6 * if the wakefulness changes. 7 * 8 * Returns true if the wakefulness changed and we need to restart power state calculation. 9 *///当wakefulness发生变化的时，返回true，同时也需要重新计算power state 10 private boolean updateWakefulnessLocked(int dirty) { 11 boolean changed = false; 12 if ((dirty & (DIRTY_WAKE_LOCKS | DIRTY_USER_ACTIVITY | DIRTY_BOOT_COMPLETED 13 | DIRTY_WAKEFULNESS | DIRTY_STAY_ON | DIRTY_PROXIMITY_POSITIVE 14 | DIRTY_DOCK_STATE)) != 0) { 15 if (mWakefulness == WAKEFULNESS_AWAKE && isItBedTimeYetLocked()) { 16 if (DEBUG_SPEW) { 17 Slog.d(TAG, "updateWakefulnessLocked: Bed time..."); 18 } 19 final long time = SystemClock.uptimeMillis(); 20 if (shouldNapAtBedTimeLocked()) { 21 changed = napNoUpdateLocked(time); 22 } else { 23 changed = goToSleepNoUpdateLocked(time, 24 PowerManager.GO_TO_SLEEP_REASON_TIMEOUT); 25 } 26 } 27 } 28 return changed; 29 } 先看函数isItBedTimeYetLocked，通过名字看，是在询问是否到了应该上床睡觉的的时间了。然后结合line 15整个判断来看，如果现在设备处于醒着的状态，但是到了该睡眠的时间了， 就要进行如下操作。那么我们就来看看设备是判断是否该睡眠的： 1 private boolean isItBedTimeYetLocked() { 2 return mBootCompleted && !isBeingKeptAwakeLocked();//个人认为mBootCompleted很重要，但是在设备正常使用的过程中我们可以认为其值是true。现在还没有必要讨论其他的情况 3 } 4 5 /** 6 * Returns true if the device is being kept awake by a wake lock, user activity 7 * or the stay on while powered setting. 8 */ 9 private boolean isBeingKeptAwakeLocked() { 10 return mStayOn 11 || mProximityPositive 12 || (mWakeLockSummary & WAKE_LOCK_STAY_AWAKE) != 0 13 || (mUserActivitySummary & (USER_ACTIVITY_SCREEN_BRIGHT 14 | USER_ACTIVITY_SCREEN_DIM)) != 0; 15 } 如果有应用程序持有wakelock，或者有用户活动的产生，或者处于充电状态，那么isBeingKeptAwakeLocked的返回值就是true，相应地isItBedTimeYetLocked 返回值就是false，说明还没有到睡眠的时间，因为还有wakelock没释放，或者有用户活动，或者是在充电等。但是，如果wakelock都释放了，并且也没有了用户活动了 也没有其他的顾虑了，那么就可以进入睡眠状态了。这时候我们就要考虑设备由醒着到睡眠的处理过程了。接着看代码updateWakefulnessLocked中的line20 ~ 25的内容， 在line 20中的方法代码如下 private boolean shouldNapAtBedTimeLocked() { return mDreamsActivateOnSleepSetting || (mDreamsActivateOnDockSetting && mDockState != Intent.EXTRA_DOCK_STATE_UNDOCKED); } mDreamsActivateOnSleepSetting的默认值为false，mDreamsActivateOnDockSetting的默认值为true。个人认为觉得Dock应该是类似于形似座充，或者能够接入汽车中的一个插孔吧， 具体是什么不是很了解。如果按我的理解，在一般的用户手中是没有接入Dock的，所以mDockState != Intent.EXTRA_DOCK_STATE_UNDOCKED应该为false。所以这个函数的返回值应该 是false的。这样的话，接下来执行的函数就是goToSleepNoUpdateLocked。这个方法在前面已经看到过了，当时是说这个方法只是更新了下power state中一些必要的属性，并没有进行真正的 执行能够让device进入sleep的代码，真正的执行代码在updatePowerStateLocked方法中，可是现在到这里，又调用了goToSleepNoUpdateLocked方法，这不还是没能让设备进入sleep嘛， 这到底是怎么回事？这个问题我们先放一放，接着往下看。大数学家华罗庚也经常使用这样的学习方法，如果在研究一个问题时，一时没能明白，不妨先放一放，接着往下读，说不定在研究后面的 问题时，你就会豁然开朗。让子弹飞一会。虽然我们一直假设shouldNapAtBedTimeLocked会返回false，但是他也是会返回为真的，比如只要开启Dreaming就行了，所以还有有必要看看 napNoUpdateLocked的实现挺简单的，就是在由醒着到应该睡眠之间的这个时间里，如果这个时间在醒着之前，或者设备不是醒着的状态，才会返回为false；其他情况都返回为true，所以我 个人认为在一般情况下这个方法是返回为true的。 到这里，对于第二阶段的power state更新就是叙述往了。 整个过程，用下面一个图表，也许可以帮助大家的理解吧： 到这里为止，第二阶段的power state的更新叙述完成了。下面接着看看第三阶段的更新的内容吧： updateDreamLocked(dirtyPhase2);根据mDirty的变化结合其他的属性一起判断是否要开始dreaming，其实就是开始屏保。如果需要开始屏保的话，通过DreamManagerService开始dreaming。 updateDisplayPowerStateLocked主要功能是每次都要重新计算一下display power state的值，即SCREEN_STATE_OFF,SCREEN_STATE_DIM,SCREEN_STATE_BRIGHT之一。此外，如果 在DisplayController中更新了display power state的话，DisplayController会发送消息通知我们，因此我们还要回来重新检查一次。我们可以看看updateDisplayPowerStateLocked是如何实现的： 1 private void updateDisplayPowerStateLocked(int dirty) { 2 if ((dirty & (DIRTY_WAKE_LOCKS | DIRTY_USER_ACTIVITY | DIRTY_WAKEFULNESS 3 | DIRTY_ACTUAL_DISPLAY_POWER_STATE_UPDATED | DIRTY_BOOT_COMPLETED 4 | DIRTY_SETTINGS | DIRTY_SCREEN_ON_BLOCKER_RELEASED)) != 0) { 5 int newScreenState = getDesiredScreenPowerStateLocked();//获取display 的power state将要变成的状态 6 if (newScreenState != mDisplayPowerRequest.screenState) {//mDisplayPowerRequest.screenState是目前display所处的power state 7 if (newScreenState == DisplayPowerRequest.SCREEN_STATE_OFF 8 && mDisplayPowerRequest.screenState 9 != DisplayPowerRequest.SCREEN_STATE_OFF) {//这个判断意味着：目前display的电源状态不是OFF，但是想要变为OFF 10 mLastScreenOffEventElapsedRealTime = SystemClock.elapsedRealtime(); 11 } 12 13 mDisplayPowerRequest.screenState = newScreenState; 14 nativeSetPowerState( 15 newScreenState != DisplayPowerRequest.SCREEN_STATE_OFF, 16 newScreenState == DisplayPowerRequest.SCREEN_STATE_BRIGHT); 17 } 18 19 int screenBrightness = mScreenBrightnessSettingDefault; 20 float screenAutoBrightnessAdjustment = 0.0f; 21 boolean autoBrightness = (mScreenBrightnessModeSetting == 22 Settings.System.SCREEN_BRIGHTNESS_MODE_AUTOMATIC);//获取屏幕亮度模式是否为自动变化 23 if (isValidBrightness(mScreenBrightnessOverrideFromWindowManager)) {//mScreenBrightnessOverideFromeWindowManager是WindowManager设置的亮度大小，默认值为-1 24 screenBrightness = mScreenBrightnessOverrideFromWindowManager; 25 autoBrightness = false; 26 } else if (isValidBrightness(mTemporaryScreenBrightnessSettingOverride)) {//mTemporaryScreenBrightnessSettingOverride在widget中中设置的临时亮度大小，默认为-1