Android 的电源管理也是很重要的一部分。比如在待机的时候关掉不用的设备，timeout之后的屏幕和键盘背光的关闭，用户操作的时候该打开多少设备等等，这些都直接关系到产品的待机时间，以及用户体验。
　　framework层主要有这两个文件：
　　frameworks/base/core/java/android/os/PowerManager.java
　　frameworks/base/services/java/com/android/server/PowerManagerService.java
　　其中PowerManager.java是提供给应用层调用的，最终的核心还是在PowerManagerService.java。这个类的作用就是提供PowerManager的功能，以及整个电源管理状态机的运行。里面函数和类比较多，就从对外和对内分两块来说。
　　先说对外，PowerManagerService如何来进行电源管理，那就要有外部事件的时候去通知它，这个主要是在frameworks/base /services/java/com/android/server/WindowManagerService.java里面。 WindowManagerService会把用户的点击屏幕，按键等作为user activity事件来调用userActivity函数，PowerManagerService就会在userActivity里面判断事件类型作出反映，是点亮屏幕提供操作，还是完全不理会，或者只亮一下就关掉。供WindowManagerService调用的方法还有gotoSleep和其他一些获取电源状态的函数比如screenIsOn等等。
　　在说对内，作为对外接口的userActivity方法主要是通过setPowerState来完成功能。把要设置的电源状态比如开关屏幕背光什么的作为参数调用setPowerState，setPowerState先判断下所要的状态能不能完成，比如要点亮屏幕的话但是现在屏幕被lock了那就不能亮了，否则就可以调用Power.setScreenState（true）来透过jni跑到driver里面去点亮屏幕了。
　　而电源的状态循环则主要是通过Handler来实现的。PowerManagerService在init里面会启动一个HandlerThread一个后台消息循环来提供任务的延迟发送，就可以使用Handler来在定制推迟某一任务的执行时间，从而实现状态机的循环。比如timeout，一段时间之后无操作要让屏幕变暗，然后关闭，反映在代码里如下：
　　userActivity里面在调用setPowerState之后会用setTimeoutLocked来设置timeout。然后在 setTimeoutLocked里面会根据当前的状态来计算下一个状态以及时间，判断完再调用 mHandler.postAtTime（mTimeoutTask， when）来post一个TimeoutTask。这样在when毫秒后就会执行TimeoutTask。在TimeoutTask里面则根据设定的状态来调用setPowerState来改变电源状态，然后再设定新的状态，比如现在是把屏幕从亮改暗了，那就再用 setTimeoutLocked（now， SCREEN_OFF）来等下把屏幕完全关掉。如果这次已经是把屏幕关了，那这轮的timeout状态循环就算是结束了。
　　如果要定制的话，比如需求是在timeout屏幕关掉之后还要再关掉一些外围设备等等，那就在TimeoutTask里面把屏幕关掉之后再加上关闭其他设备的代码就好了。即使新的状态需求完全和原来的不一样，用Handler应该也不难。逻辑理清了把代码摆在合适的地方就好了。
　　总体上来说Android的电源管理还是比较简单的， 主要就是通过锁和定时器来切换系统的状态，使系统的功耗降至最低，整个系统的电源管理架构图如下： （注该图来自Steve Guo）
　　
　　接下来我们从Java应用层面， Android framework层面， Linux内核层面分别进行详细的讨论：
　　应用层的使用：
　　Android提供了现成android.os.PowerManager类，该类用于控制设备的电源状态的切换。
　　该类对外有三个接口函数：
　　void goToSleep（long time）; //强制设备进入Sleep状态
　　Note：
　　尝试在应用层调用该函数，却不能成功，出现的错误好象是权限不够， 但在Framework下面的Service里调用是可以的。
　　newWakeLock（int flags， String tag）;//取得相应层次的锁
　　flags参数说明：
　　PARTIAL_WAKE_LOCK： Screen off， keyboard light off
　　SCREEN_DIM_WAKE_LOCK： screen dim， keyboard light off
　　SCREEN_BRIGHT_WAKE_LOCK： screen bright， keyboard light off
　　FULL_WAKE_LOCK： screen bright， keyboard bright
　　ACQUIRE_CAUSES_WAKEUP： 一旦有请求锁时强制打开Screen和keyboard light
　　ON_AFTER_RELEASE： 在释放锁时reset activity timer
Note：
　　如果申请了partial wakelock，那么即使按Power键，系统也不会进Sleep，如Music播放时
　　如果申请了其它的wakelocks，按Power键，系统还是会进Sleep
　　void userActivity（long when， boolean noChangeLights）;//User activity事件发生，设备会被切换到Full on的状态，同时Reset Screen off timer.
　　Sample code：
　　PowerManager pm = （PowerManager）getSystemService（Context.POWER_SERVICE）;
　　PowerManager.WakeLock wl = pm.newWakeLock （PowerManager.SCREEN_DIM_WAKE_LOCK， “My Tag”）;
　　wl.acquire（）;
　　……。
　　wl.release（）;
　　Note：
　　1. 在使用以上函数的应用程序中，必须在其Manifest.xml文件中加入下面的权限：
　　《uses-permission android:name=“android.permission.WAKE_LOCK” /》
　　《uses-permission android:name=“android.permission.DEVICE_POWER” /》
　　2. 所有的锁必须成对的使用，如果申请了而没有及时释放会造成系统故障。如申请了partial wakelock，而没有及时释放，那系统就永远进不了Sleep模式。
　　Android Framework层面：
　　其主要代码文件如下：
　　frameworks/base/core/java/android/os/PowerManager.java
　　frameworks/base/services/java/com/android/server/PowerManagerService.java
　　frameworks/base/core/java/android/os/Power.java
　　frameworks/base/core/jni/android_os_power.cpp
　　hardware/libhardware/power/power.c
　　其中PowerManagerService.java是核心， Power.java提供底层的函数接口，与JNI层进行交互， JNI层的代码主要在文件android_os_Power.cpp中，与Linux kernel交互是通过Power.c来实现的， Andriod跟Kernel的交互主要是通过sys文件的方式来实现的，具体请参考Kernel层的介绍。
　　这一层的功能相对比较复杂，比如系统状态的切换，背光的调节及开关，Wake Lock的申请和释放等等，但这一层跟硬件平台无关，而且由Google负责维护，问题相对会少一些，有兴趣的朋友可以自己查看相关的代码。
　　Kernel层：
　　其主要代码在下列位置：
　　drivers/android/power.c
　　其对Kernel提供的接口函数有
　　EXPORT_SYMBOL（android_init_suspend_lock）; //初始化Suspend lock，在使用前必须做初始化
　　EXPORT_SYMBOL（android_uninit_suspend_lock）; //释放suspend lock相关的资源
　　EXPORT_SYMBOL（android_lock_suspend）; //申请lock，必须调用相应的unlock来释放它
　　EXPORT_SYMBOL（android_lock_suspend_auto_expire）;//申请partial wakelock， 定时时间到后会自动释放
　　EXPORT_SYMBOL（android_unlock_suspend）; //释放lock
　　EXPORT_SYMBOL（android_power_wakeup）; //唤醒系统到on
　　EXPORT_SYMBOL（android_register_early_suspend）; //注册early suspend的驱动
　　EXPORT_SYMBOL（android_unregister_early_suspend）; //取消已经注册的early suspend的驱动
　　提供给Android Framework层的proc文件如下：
　　“/sys/android_power/acquire_partial_wake_lock” //申请partial wake lock
　　“/sys/android_power/acquire_full_wake_lock” //申请full wake lock
　　“/sys/android_power/release_wake_lock” //释放相应的wake lock
　　“/sys/android_power/request_state” //请求改变系统状态，进standby和回到wakeup两种状态
　　“/sys/android_power/state” //指示当前系统的状态
Android的电源管理主要是通过Wake lock来实现的，在最底层主要是通过如下三个队列来实现其管理：
　　static LIST_HEAD（g_inactive_locks）;
　　static LIST_HEAD（g_active_partial_wake_locks）;
　　static LIST_HEAD（g_active_full_wake_locks）;
　　所有初始化后的lock都会被插入到g_inactive_locks的队列中，而当前活动的partial wake lock都会被插入到g_active_partial_wake_locks队列中， 活动的full wake lock被插入到g_active_full_wake_locks队列中， 所有的partial wake lock 和full wake lock在过期后或unlock后都会被移到inactive的队列，等待下次的调用。
　　在Kernel层使用wake lock步骤如下：
　　1. 调用函数android_init_suspend_lock初始化一个wake lock
　　2. 调用相关申请lock的函数android_lock_suspend 或 android_lock_suspend_auto_expire请求lock，这里只能申请partial wake lock， 如果要申请Full wake lock，则需要调用函数android_lock_partial_suspend_auto_expire（该函数没有EXPORT出来），这个命名有点奇怪，不要跟前面的android_lock_suspend_auto_expire搞混了。
　　3. 如果是auto expire的wake lock则可以忽略，不然则必须及时的把相关的wake lock释放掉，否则会造成系统长期运行在高功耗的状态。
　　4. 在驱动卸载或不再使用Wake lock时请记住及时的调用android_uninit_suspend_lock释放资源。
　　系统的状态：
　　USER_AWAKE， //Full on status
　　USER_NOTIFICATION， //Early suspended driver but CPU keep on
　　USER_SLEEP // CPU enter sleep mode
　　其状态切换示意图如下：
　　
　　系统正常开机后进入到AWAKE状态， Backlight会从最亮慢慢调节到用户设定的亮度，系统screen off timer（settings-》sound & display-》 Display settings -》 Screen timeout）开始计时，在计时时间到之前，如果有任何的activity事件发生，如Touch click， keyboard pressed等事件， 则将Reset screen off timer， 系统保持在AWAKE状态。 如果有应用程序在这段时间内申请了Full wake lock，那么系统也将保持在AWAKE状态， 除非用户按下power key. 在AWAKE状态下如果电池电量低或者是用AC供电screen off timer时间到并且选中Keep screen on while pluged in选项，backlight会被强制调节到DIM的状态。
如果Screen off timer时间到并且没有Full wake lock或者用户按了power key，那么系统状态将被切换到NOTIFICATION，并且调用所有已经注册的g_early_suspend_handlers函数， 通常会把LCD和Backlight驱动注册成early suspend类型，如有需要也可以把别的驱动注册成early suspend， 这样就会在第一阶段被关闭。 接下来系统会判断是否有partial wake lock acquired， 如果有则等待其释放， 在等待的过程中如果有user activity事件发生，系统则马上回到AWAKE状态;如果没有partial wake lock acquired， 则系统会马上调用函数pm_suspend关闭其它相关的驱动， 让CPU进入休眠状态。
　　系统在Sleep状态时如果检测到任何一个Wakeup source， 则CPU会从Sleep状态被唤醒，并且调用相关的驱动的resume函数，接下来马上调用前期注册的early suspend驱动的resume函数，最后系统状态回到AWAKE状态。这里有个问题就是所有注册过early suspend的函数在进Suspend的第一阶段被调用可以理解，但是在resume的时候， Linux会先调用所有驱动的resume函数，而此时再调用前期注册的early suspend驱动的resume函数有什么意义呢？个人觉得android的这个early suspend和late resume函数应该结合Linux下面的suspend和resume一起使用，而不是单独的使用一个队列来进行管理.