电源管理（PowerManager）：WakeLock机制、Doze模式与App Standby、电池优化策略、PowerManagerService工作原理
电源管理这块，说实在的，是Android Framework里最容易被忽视、但一旦出问题就让人头疼的模块。我早年做系统开发时，遇到过一款设备待机一晚掉电30%，查了三天才发现是某个三方App持了个WakeLock没释放。嗯，从那以后，我对电源管理就格外上心了。
今天咱们就把PowerManager这套东西彻底捋清楚。从最基础的WakeLock，到Android 6.0引入的Doze和App Standby，再到PowerManagerService的底层运转逻辑，一个一个来。
WakeLock机制：别让CPU偷懒，也别让它累死
WakeLock说白了就是一个锁。App跟系统说：“嘿，我现在要干活，别让CPU睡过去。”系统收到请求后，就会保持CPU唤醒状态。
但问题来了——如果每个App都这么干，手机电池撑不过半天。所以WakeLock必须成对出现：acquire和release。
核心要点：WakeLock分为四种类型，每种影响不同的硬件模块。
| 类型 | 标志位 | CPU | 屏幕 | 键盘灯 |
|---|---|---|---|---|
| PARTIAL_WAKE_LOCK | 0x1 | 保持唤醒 | 可关闭 | 可关闭 |
| SCREEN_DIM_WAKE_LOCK | 0x6 | 保持唤醒 | 变暗 | 可关闭 |
| SCREEN_BRIGHT_WAKE_LOCK | 0xA | 保持唤醒 | 保持亮 | 可关闭 |
| FULL_WAKE_LOCK | 0x1A | 保持唤醒 | 保持亮 | 保持亮 |
我个人习惯，在项目里只用PARTIAL_WAKE_LOCK。为什么？因为屏幕和键盘灯太耗电了。你想想看，如果只是为了后台下载个文件，没必要把屏幕点亮吧？
代码怎么写？很简单：
PowerManager pm = (PowerManager) getSystemService(Context.POWER_SERVICE);
PowerManager.WakeLock wl = pm.newWakeLock(PowerManager.PARTIAL_WAKE_LOCK, "MyApp:DownloadLock");
wl.acquire();
// 执行耗时操作...
wl.release();注意：acquire和release必须成对出现。我曾经见过一个App在异常分支里忘了release，结果手机CPU一直处于唤醒状态，电量哗哗地掉。建议用try-finally包裹，或者直接用WakeLock的acquire(timeout)方法设置超时自动释放。
Doze模式与App Standby：系统帮你管电
Android 6.0开始，Google终于对App的“任性”行为下手了。Doze模式和App Standby就是两把利剑。
Doze模式，说白了就是手机静止不动且屏幕关闭一段时间后，系统进入的一种深度省电状态。这时候，所有App的网络访问被暂停，WakeLock被忽略，Alarm被延迟。
Doze分两个阶段：
- 轻量Doze：屏幕关闭后30分钟进入。App可以偶尔访问网络，但频率受限。
- 深度Doze：屏幕关闭更长时间后进入。网络完全切断，WakeLock失效。
App Standby则针对的是那些长时间没被用户点开的App。系统会判定这个App处于“空闲”状态，限制它的后台网络访问和任务执行。
我记得有一次，用户反馈某个IM软件收不到消息。查了半天，发现是App被标记为Standby了。解决方案是引导用户把该App加入“不受电池优化”的白名单。
避坑指南：如果你的App需要实时接收消息，建议使用Firebase Cloud Messaging（FCM）或者厂商推送通道。这些通道有系统级权限，不受Doze和Standby限制。我曾经硬扛过一段时间，自己维护长连接，结果被Doze搞得焦头烂额。
电池优化策略：从被动防御到主动管理
电池优化，不能只靠系统。App自身也要有策略。我总结了三条原则：
- 按需获取WakeLock：只在真正需要的时候才acquire，用完立刻release。别搞什么“先拿着，万一待会儿要用”的想法。
- 批量处理网络请求：把零散的小请求合并成一个大请求。比如每5分钟发一次心跳，不如改成每15分钟发一次，但一次带多条数据。
- 监听系统广播：监听ACTION_POWER_CONNECTED和ACTION_POWER_DISCONNECTED。充电时可以做些耗电的操作，比如同步大文件；拔掉电源后，立刻收敛。
另外，Android 8.0开始，后台执行限制更严格了。隐式广播大部分被砍掉，后台Service也活不了多久。这时候，JobScheduler和WorkManager就成了首选。
// 使用WorkManager做后台任务
OneTimeWorkRequest workRequest = new OneTimeWorkRequest.Builder(MyWorker.class)
.setConstraints(new Constraints.Builder()
.setRequiresCharging(true) // 只在充电时执行
.build())
.build();
WorkManager.getInstance(context).enqueue(workRequest);你想想看，这样既完成了任务，又不影响用户体验，多好。
PowerManagerService工作原理：系统级电源调度
PowerManagerService（PMS）是Framework层管理电源的核心服务。它运行在system_server进程里，负责处理所有电源相关的请求。
PMS的工作流程大致是这样的：
- App通过Binder调用PowerManager的接口（如acquireWakeLock）。
- PowerManager将请求转发给PMS。
- PMS检查权限、更新WakeLock计数、调整CPU频率和屏幕状态。
- PMS通过PowerManagerInternal通知其他模块（如DisplayManagerService、BatteryStatsService）。
这里有个关键点：WakeLock是内核级别的。PMS最终会通过/sys/power/wake_lock节点告诉内核：“别睡，有人要用CPU。”内核收到后，会阻止系统进入suspend状态。
我画了一张图，帮你理解PMS的整体架构：
从图里能看出来，PMS不是单打独斗的。它跟DisplayManagerService配合控制屏幕亮灭，跟BatteryStatsService配合统计电量消耗，跟AlarmManagerService配合管理闹钟唤醒。
嗯，这里要注意一个细节：WakeLock的计数是引用计数的。同一个WakeLock对象，acquire一次计数+1，release一次计数-1。只有计数归零时，WakeLock才会真正释放。我曾经踩过这个坑——在循环里acquire了多次，但只release了一次，结果WakeLock一直没释放。
核心总结：
- WakeLock是App主动请求CPU保持唤醒的机制，必须成对使用。
- Doze和App Standby是系统级的省电策略，App需要适配。
- 电池优化要从App自身做起，按需获取、批量处理、监听充电状态。
- PowerManagerService是电源管理的核心，通过Binder与App通信，通过内核节点控制硬件。
电源管理这块，说难不难，说简单也不简单。关键是要理解系统为什么要这么设计——一切都是为了在用户体验和电池续航之间找到平衡点。你想想看，如果手机半天就没电了，再牛的功能也没用，对吧？