企业官网建设流程全解析

手机上“放着不用”的电量，往往比“一直在用”的时候更让人恼火。晚上充满电放在床头，早上醒来掉了百分之七八，后台也没跑什么大任务，可电量就是留不住。Android从6.0开始引入的Doze模式，配合PowerManagerService的电源管理调度，就是专门来收拾这笔“待机糊涂账”的。上篇聊了PowerManagerService的整体框架和wakelock机制，这篇聚焦Doze模式，把它从状态机到系统调度、再到应用侧配合的完整链路拆开讲清。做系统Framework也好，搞应用性能优化也好，把这套逻辑理顺，很多“诡异掉电”问题都会迎刃而解。

1. 待机功耗到底去哪儿了：Doze要解决的不是“耗电大户”，而是“高频路过”

很多开发者会有一个惯性思维：手机待机耗电，肯定是因为某个应用在后台偷偷跑大任务。但实际上，单纯一个应用持续占用CPU，功耗其实可控，真正让电量在待机时快速流失的，是“高频次的短唤醒”。

1.1 每隔几分钟就亮屏一下的“吸血鬼”

Android 6.0之前，只要应用拿到一个Alarm，哪怕只是做一次几秒钟的网络同步，系统都得把CPU从低功耗状态拉起来。如果装了十几个应用，每个都按自己的节奏定闹钟，比如天气每半小时同步一次、邮件每十五分钟轮询一次、社交应用每几分钟检查一次推送，那手机整晚就别想真正“睡”下去。

有人做过粗算：一次短唤醒从CPU唤醒到网络请求再到休眠，整个过程几百毫秒到一两秒，看起来不多。但一夜按八小时算，每个应用唤醒几十次，叠加起来就是几百次。每一次唤醒都要给CPU供上工作电压，屏幕虽然不亮，基带和Wi-Fi射频也在持续工作。这种“高频路过”式的消耗，比一个应用连续跑几分钟还要命。Doze模式的核心思路，就是不能只盯住某一次的功耗，而要把“唤醒次数”这个总频次压下来。

1.2 强制推迟不是野蛮切断

很多人把Doze理解为“后台全杀了”，其实不对。它不是一刀切地冻结应用，而是做了一层“时间重排”：把你的闹钟、网络请求、Job任务统一延后，攒到一段时间里集中处理。就像公司里的合并报税，不是说不用交，而是把零散的申报集中到几个固定节点，省去反复跑腿的麻烦。

这套逻辑落在PowerManagerService里，就是维护一个设备空闲状态，配合AlarmManager做批量唤醒。系统会先判断你是不是“真的没用手机”——屏幕灭着、没插充电、设备基本静止，然后才考虑进入Doze。如果你一边充电一边刷短视频，或者手机在口袋里被人拿着走动，系统是打死也不会进深层Doze的，因为你的“正在使用”信号太强了。

1.3 为什么要分浅层和深层两层

Android 7.0加入了浅层Doze（Light Doze），Android 9之后又加深了整体策略。浅层Doze是“轻量限流”：网络访问、Job任务、Alarm都能跑，只是频率被压低。深层Doze是“重拳管控”：大部分网络和闹钟都被冻结，只有高优先级通道能穿透。分两层的原因很实际——如果一刀切直接进深层Doze，很多应用连通知推送都收不到，用户的不满意度会比省电收益高得多。系统需要一套渐进式的收拢策略。

2. 状态机不是玄学：从灭屏到深度闲置的每一道关口

PowerManagerService内部对Doze的管理，核心是一个设备闲置状态机。理解它，是分析一切待机耗电问题的基础。

2.1 一条完整的状态迁移链

整条链路可以概括为：

ACTIVE（活跃）→ INACTIVE（不活跃）→ IDLE_PENDING（待定闲置）→ SENSING（感应检测）→ LOCATING（定位确认）→ IDLE（深层闲置）→ IDLE_MAINTENANCE（闲置维护）→ 回到IDLE

每个状态都有自己的任务和判定标准，我来逐个说。

ACTIVE状态下，屏幕亮着或有正在进行的用户交互，系统不做任何Doze判定。屏幕灭掉之后进入INACTIVE，此时会启动一个“静止检测”，通过SensorManager监听加速度计等设备运动数据，判断手机是不是长时间没被移动。如果一直静止，就会进入IDLE_PENDING，这时候系统开始酝酿进入深层Doze，但还留着一个探测窗口，防止误判——比如你屏幕灭了但正在用手势操作，或者设备刚从口袋掏出来。

SENSING阶段会短暂亮起一个很暗的探测层，目的是做一次“人是否在场”的检测，比如脸部识别。如果检测失败或者拿到“设备仍在使用”的信号，就退回INACTIVE。通过检测后进入LOCATING，这个状态下系统会尝试确认设备位置是否稳定。如果你在移动交通工具上，GPS信号在跳变，说明设备不是静止的，就会取消进入Doze。

等所有这些条件都满足，才真正进入IDLE状态，也就是深层Doze。应用的网络访问被挂起，Alarm被批量推迟，然后周期性地进入IDLE_MAINTENANCE窗口，统一放行这段时间积压的任务。维护窗口跑完，再回到IDLE。这套机制从Android 6.0到后面的版本，骨架基本没变，变的只是各环节的阈值和参数。

2.2 关键参数：这些时间窗口直接决定续航体验

下面这张表整理的是几个核心参数，大家在分析系统行为时经常用到：

这些数值在不同厂商ROM里有自己的调优，但理解默认值能帮你判断一个问题：为什么手机灭屏半小时后，掉电曲线才明显放缓？因为前面浅层Doze还在试探，深层Doze的进入条件需要多种信号叠加确认。用户日常感受到的“待机一夜不掉电”，背后其实是这套时间策略在起作用。

2.3 退出Doze的“随时在线”通道

进入Doze之后，系统不可能把所有东西都堵死。电话、短信、系统级通知这类高优先级通道必须穿透。Android提供了一套白名单机制，明确标出哪些应用、哪些组件在Doze期间仍然被允许持有唤醒锁、接收Alarm、访问网络。

有两类需要特别说明：一类是系统预置的高优先级应用，比如拨号器、短信、即时通讯的系统组件；另一类是通过用户设置或开发者在清单里申请“电池优化豁免”的应用，通常是聊天软件、邮件、网盘这类需要实时感知消息的工具。如果要动态判断一个应用是否在白名单里，可以执行：

adb shell dumpsys deviceidle whitelist

输出里会列出所有被豁免的包名和时间戳。这个通道的存在，实际上就是把“和用户感知强相关”的应用单独拎出来，避免Doze一刀切带来的体验损失。白名单从PowerManagerService的角度看，也只是在判定是否强制挂起某个唤醒源时，多了一道查表逻辑。

3. 系统层调度里的关键路径：PowerManagerService内部到底做了什么

从Framework的角度看，Doze不是一个独立模块，而是PowerManagerService、AlarmManagerService、JobSchedulerService、BatteryStatsService、DeviceIdleController等多个组件协同的结果。

3.1 DeviceIdleController是真正的“大脑”

很多人容易把PowerManagerService和Doze绑定在一起，但其实Doze的核心决策逻辑在DeviceIdleController，它是PowerManagerService内部的一个独立Controller类。它负责维护状态机、解析设备闲置参数、监听传感器和屏幕状态，并向PowerManagerService汇报“当前该不该进入Doze”。

PowerManagerService的角色更像执行者：当DeviceIdleController判定进入IDLE，它会调用内部接口去更新电源策略，通知各个服务挂起对应的唤醒源；退出IDLE时，再做一轮全面释放。这中间牵扯到很重要的一个点：系统自动进入的Doze和应用手动申请的省电模式，是两套完全不同的流程。前者是状态机驱动的自动行为，后者直接由用户在设置页触发，强制压低CPU频率和限制后台，优先级比自动Doze高得多。

3.2 AlarmManager和JobScheduler在Doze下的配合策略

深层Doze下，AlarmManager会把普通应用的唤醒闹钟全部推迟到下一个维护窗口执行，但有两类例外：一是设置了setExactAndAllowWhileIdle的闹钟，系统允许它低频穿透（通常几分钟一次）；二是白名单内的应用闹钟，正常触发。这也回应了一个很常见的疑问：为什么有些闹钟App在Doze下不响？因为它用的是旧的setExact，没有加AllowWhileIdle标志，系统在闲置状态下直接把它顺延了。

JobScheduler在Doze下的行为更直接：联网型Job、延迟型Job全部暂停，等退出Doze或进入维护窗口再执行。所以你会发现，很多用WorkManager做的“定期上传日志”任务，在夜间经常积压到早晨手机拿起那一刻统一跑，这正是Doze的功劳。

PowerManagerService在这一层的主要工作，是协调所有关联服务的状态切换：通知BatteryStats记住当前状态用于统计、通知NetworkPolicy调整待机网络的可用性、通知JobScheduler冻结任务队列。整个调度链路里最核心的一次调用，对应到代码路径上，是从DeviceIdleController.exitIdleInternal到PowerManagerService.updatePowerPolicyLocked的逐级传递。

3.3 维护窗口为什么要“攒着一批任务再放行”

维护窗口的设计很值得玩味。它本质上是一个“吞吐窗口”，系统在IDLE状态下积累的所有网络请求、定时任务、闹钟回调，都集中在这个窗口内一起处理。默认窗口持续1到6分钟，具体长短取决于积压任务量。

为什么不能随时放行？因为每放行一次，CPU和无线模块都要从低功耗模式唤醒，唤醒本身有能量开销。与其为每个小任务反复唤醒几十次，不如攒起来一次唤醒、暴力处理，处理完了继续倒头大睡。这个思路跟“批量冲刷”很像：厕所水箱一次冲5升水很省事，如果你隔一分钟放一滴水，管道和泵反而一直在运转。

实际调参时，有人会去改min_idle_on_idle和idle_maintenance_min来缩短维护窗口，想省电。但这里有个坑：窗口太短，任务来不及跑完，会延迟到下一轮，反而导致更频繁地进入维护状态，整体功耗不降反升。我在某公司的模拟项目X里对比过两组参数，维护窗口设成60秒的版本，因为任务经常处理不完，每40分钟就要醒来一次；而设成2分钟窗口的版本，每90分钟才唤醒一轮，整夜功耗反而低了将近20%。

4. 应用侧优化：别跟系统对着干，也不要做“装死”的应用

Doze机制对应用开发者来说，最直接的感受就是“Alarm不灵了”“后台任务跑不动了”。抱怨没用，正确做法是顺着系统的规则改变自己的实现策略。

4.1 用JobScheduler/WorkManager替代裸奔的后台任务

如果你的应用需要定期做数据同步、日志上报、缩略图生成，现在最稳妥的方式是交给WorkManager去调度，而不是自己维护一个线程池加定时器。WorkManager内部会识别系统状态：设备空闲、充电状态、网络可用性都会作为约束条件参与调度。Doze时它不会强行执行，退出Doze或者进入维护窗口时又能立刻补跑。

我在一个实际案例里遇到过：某应用用自有方案每半小时上报一次位置，在Android 9之前勉强能跑，升级到Android 11之后晚上完全收不到数据。排查后确认就是Doze在起作用——那些Alarm全部被推迟到早晨集中上报。改成WorkManager加充电约束后，夜间数据改为“待机时不报、插电后补报、移动时即时报”，问题就解决了。

4.2 申请白名单要克制，更要说明理由

白名单是绕过Doze的入口，但它不等于“免死金牌”。申请白名单时，用户会在设置页看到明确的提示“允许该应用后台运行”，不同意的话白名单就是失效的。而且系统也有自己的保护逻辑——即使应用在白名单里，如果长时间被系统检测到频繁唤醒，BatteryStats会把这些记录标记出来，用户在电池详情页能看到“该应用后台活动频繁”，这在应用商店的体验评价里是很伤的口碑。

真正需要白名单的场景，应当限定在实时通讯、推送接收、语音通话这类用户可感知的功能。一个天气应用，真的没有必要为了“每十分钟刷新温度”申请后台豁免。把这个额度留给刚需功能，才是电池优化的清醒策略。

4.3 自行判断Doze状态，适时调整策略

应用可以主动查一下自己是不是在Doze的“待机环境”下。可以参考下面的代码片段：

PowerManager pm = (PowerManager) context.getSystemService(Context.POWER_SERVICE); if (pm != null && pm.isDeviceIdleMode()) { // 设备处于Doze状态，暂停非关键任务 }

运行时判断出当前处于Doze，就应该主动把“立即执行”的预期降级为“稍后执行”，而不是反复尝试唤醒自己。这一点看起来简单，很多团队却容易忽略：到了Doze里，还在不停创建Alarm、申请WakeLock，结果全部被系统拦截，代码里一堆逻辑都没跑，日志里却全是超时重试的记录。提前做状态感知，比事后容错要省钱得多。

5. 实测与排障：怎么用一条命令把Doze的每一步看得清清楚楚

纸上谈兵没意思，真刀真枪地验证Doze行为，才是Framework工程师和性能优化工程师的日常。

5.1 手动进入Doze的完整命令链

先打开开发者选项里的“Don‘t keep activities”这类干扰项，确保没有异常活动在后台干扰，然后按这条链路走：

# 设置设备为静止状态 adb shell dumpsys deviceidle enable adb shell dumpsys deviceidle step adb shell dumpsys deviceidle force-idle # 查看当前状态 adb shell dumpsys deviceidle | grep -E "mState|mDeepEnabled|mLightEnabled|mForceIdle"

step命令是手动推进状态机的关键，每执行一次会强制状态机往前跳一步。如果网络环境不合适，或者传感器误判，你可能要反复执行step才能到达IDLE。走到IDLE之后再用：

adb shell dumpsys alarm | grep "idle"

可以查看哪些Alarm被推迟了，哪些Alarm被白名单放行。再配合BatteryStats的时长统计：

adb shell dumpsys batterystats | grep "Device idle mode:"

能直接看到系统在Doze状态里待了多久，以及在Doze期间各应用唤醒CPU的次数。整个排查链路里，最关键的就是对比“进入Doze前”和“进入Doze后”的wakeup次数变化，如果某个应用在Doze期间仍然频繁唤醒，基本可以断定它申请了白名单或者故意绕过限制。

5.2 一个典型的误判案例：充电状态下的假Doze

之前处理过一个反馈：某设备插入充电器之后，待机掉电反而比不充电时更快。很多人第一反应是电池老化或者充电电路漏电，但用上面的命令跑了一遍才发现，问题根本不在硬件。

场景是这样的：充电状态下，用户可以正常操作手机，不需要进入Doze，所以系统的DeviceIdleController不会进入深层闲置；但问题出在应用侧——有些应用检测到“屏幕熄灭+插电”，会认为这是个执行繁重任务的好时机（备份、同步、更新），于是集中启动大量任务。这些任务插着电跑，功耗确实不计入电池，但它们的后台活动会频繁唤醒CPU。最讽刺的是，当设备插着电时，系统的Doze判定逻辑有一条“电源连接时不进入Doze”，于是这个“高速公路上的大货车”根本没人管，一直跑到充满为止。

所以说，排查功耗问题不能只看电池曲线，要同时看“设备状态”和“应用行为”两条线。我习惯的做法是先拉一份dumpsys deviceidle看系统状态，再拉一份dumpsys batterystats按包名聚合看唤醒源，双线对照通常能快速定位凶手。

5.3 版本差异：Android 9到14，Doze的“加码”体现在哪

从Android 9到Android 14，Doze在全局上并没有颠覆式改动，但有一个趋势：系统对后台限制越来越精细，同时对白名单的审计越来越严格。

Android 9加入了“应用待机分组”（App Standby Buckets），把应用按使用频率分成活跃、常用、罕见等几个桶。不同桶对应不同的后台任务执行频率和Alarm限制强度——这个机制和Doze是一个组合拳：Doze管“手机闲着的时候”，App Standby管“你不用的那些应用”。两个维度叠加之后，一个罕见的应用在夜间想偷偷跑任务，成功率几乎是零。

Android 11引入了“自动重置未使用的应用”，如果某个应用几个月没被打开，系统直接把它的后台权限重置回收，包括存储权限和后台定位权限。Android 12之后的“休眠应用”机制，则是直接把长时间未用的应用强制进入暂停状态，连通知都发不出来的那种。这套组合拳下来，做电池优化的同事应该意识到：单纯靠系统侧的Doze已经不够了，应用设计之初就得想清楚“我是高频刚需还是低频边缘应用”，对应的后台策略完全不同。

写在最后的个人体会

做电源优化这几年，我最大的感受是：所谓“电池优化”从来不是某一项技术的功劳，而是一套围绕“唤醒成本”设计的分层策略。Doze模式解决的是“手机闲置时的及时休眠”，App Standby解决的是“低频应用的后台限制”，再加上用户对白名单的主动管理、应用开发者对后台任务的合理调度，电池才能越用越耐用。每次看到那种“奇奇怪怪的待机掉电”问题，我都会先跑一遍设备闲置状态机链路，把State Graph里每一步的日志拉出来看一遍，绝大多数问题都能从状态机的哪一步没有真正迈进、或者迈进后又被谁强行拉出来，找到答案。这套方法论在系统研发、应用开发、性能评测三类人身上，都是可以复用的核心功夫。