搞ARM SoC的电源管理很多时候像在走钢丝。既要满足应用场景下的极致性能又要控制住功耗发热尤其到了ARMv9/v8时代系统级电源管理架构早已不是简单的“睡不睡、醒不醒”问题而是一整套从硬件到固件再到OS的协同设计。这篇文章我会把ARMv9/v8体系下的Power Management System Architecture拆开从PSCI、DVFS、CPUidle到设备树配置、SCMI协议、系统Suspend/Resume结合自己做过的项目和一些踩坑经历尽量讲得通俗、实操。基于标题“[A-41]ARMv9/v8-电源管理系统架构(Power Management System Architecture)”这确实是个系统性的工程话题适合嵌入式底层开发、BSP工程师、以及对SoC功耗调优感兴趣的读者。我会在这里把整体设计思路、关键节点、代码层面的配置方法以及常见的调试排障经验整理出来。1. 电源管理系统架构的整体设计与核心思路1.1 为什么要上升到“架构”层面很多人对电源管理的理解停留在“CPU空闲了就WFI”或者“跑个cpufreq调频”的层面。这些确实属于电源管理的一部分但在ARMv9/v8体系下电源管理的范围要宽得多。现代SoC里CPU只是消耗主体之一GPU、NPU、DDR、互连总线、外设的电源域和时钟域都需要在运行时动态管理。再加上多核异构、大小核拓扑、安全与非安全世界的切换电源管理必须有一套可以扩展、可管理、可迁移的架构而不是靠驱动里写死几个脚本。ARM的电源管理系统架构就是围绕“状态定义、状态迁移、资源划分、接口协议、系统集成”这几个维度搭建的体系。它在硬件上有电源域Power Domain、时钟域Clock Domain、电压轨Voltage Rail的概念在固件层有PSCI和SCMI在内核侧有CPUidle、Cpufreq、Devfreq、Perf Domain等框架形成一个完整的垂直栈。理解这套架构首先要建立两个视角一是分级视角也就是从电源状态到硬件动作之间要过多少层抽象二是角色视角也就是谁决定进入低功耗状态、谁执行这个动作、谁感知功耗变化。整个系统的优雅程度取决于这几层之间协作的严密性。1.2 从ARMv8到ARMv9电源架构演进了什么ARMv8时代电源管理的主要载体是PSCI它定义了一套标准的电源管理调用接口把CPU的开关、挂起、系统重启等操作从特权软件下沉到EL3固件。这样做的直接好处是操作系统不再需要知道具体的寄存器细节只需要通过SMC指令调用标准函数即可。到了ARMv9基础没变但在安全性、弹性和虚拟化支持上提出了更高要求。比如FF-AFirmware Framework for Armv8-A/Armv9-A统一了不同固件组件之间的通信方式电源管理相关的消息传递也可以跑在FF-A的框架之上。与此同时SCMISystem Control and Management Interface被更广泛地用于与平台管理处理器SCP通信管理DVFS、时钟和电源域。ARMv9还强调对RMERealm Management Extension支持下的资源隔离电源管理的状态机也需要为世界切换留出正确决策空间。1.3 架构中各方角色的分工简单来讲电源管理架构中有三个主要参与者。OS/内核负责策略层面的决策比如根据负载决定要不要调频、要不要进入idle、要进多深的idle。内核的Linux cpuidle和cpufreq框架是策略实现的核心。固件/EL3负责机制层面的执行包括PSCI调用的处理、CPU hotplug、挂起流程、系统重启等。TF-ATrusted Firmware-A是这一层最常见的实现。平台管理处理器SCP/MCU负责真正的硬件微操作包括电压调节、时钟切换、电源域门控甚至包括一些热管理策略。它通过SCMI与AP侧通信。这三者之间典型的通信路径是内核cstate决策-CPUidle调PSCI suspend-EL3固件处理-通过SCMI通知SCP-SCP操作寄存器完成下电/上电。任何一层出错、时序不对或者接口约定不匹配都会直接表现为功耗异常、卡死或者系统无法唤醒。2. PSCI与CPU低功耗状态机制的底层原理2.1 PSCI电源管理的“系统调用”PSCI的全称是Power State Coordination Interface。在ARMv7时代不同的SoC有各自的CPU_OFF、CPU_ON实现方式Linux kernel要适配各种平台特性很繁琐。ARMv8后整机统一规定使用PSCI作为电源管理接口从0.2到1.0、1.1功能范围逐步扩大。PSCI定义了几个核心调用最常见的是CPU_SUSPENDCPU_OFFCPU_ONAFFINITY_INFOSYSTEM_SUSPENDSYSTEM_OFFSYSTEM_RESET其中CPU_SUSPEND可以附带一个电源状态参数power_state描述要进入的层级别core级、cluster级、system级以及状态类型standby、retention、power down等。这里要特别注意PSCI协议规定当某个core调用CPU_SUSPEND进入断电状态后它自己不能主动恢复执行必须依赖其他在线core或者硬件中断唤醒机制。实际项目中我经常看到有人在移植新板卡时直接把其他平台的PSCI节点复制过来结果发现idle进不去或者唤醒后系统卡死。原因往往就是电源状态参数里的亲和层级Affinity Level和状态ID跟当前平台的硬件电源域拓扑不匹配。2.2 CPUidle框架与cstate状态等级Linux内核的CPUidle框架负责管理CPU的空闲状态也就是cstate。在ARM平台上每个cstate对应一个底层的PSCI power state。以常见的设计为例一个ARMv8/ARMv9四核CPU可能会定义这几个cstateC1WFI只执行等待中断指令实际上不会真正断电主要是省指令流功耗。C2core power down该CPU核心掉电但L2和cluster还保持供电。C3cluster power down整个cluster掉电L2可能保持或掉电具体看硬件设计。C6system power down整个系统挂起内存可能进入自刷新。CPUidle框架会根据内核的调度空闲情况、唤醒延迟容忍度以及目标状态的residency要求动态选择进入哪个cstate。这里有个关键参数叫target_residency意思是必须预估自己能空闲多久如果空闲时间小于这个阈值进入更深状态反而是亏本的因为唤醒开销比省下的功耗还大。2.3 WFI与WFET的细节不可忽视在ARMv8/v9体系里WFIWait For Interrupt是最基础的低功耗等待指令但不代表WFI就是不耗电。如果在cpu_ops和idle管理中出现问题比如把中断挂在了一个已断电的GIC redistributor上那么核心睡着之后就再也醒不过来了。ARMv8.2引入了WFETWait For Event with TimeoutARMv9也继续沿用类似机制。这类指令允许带一个超时时间在某些场景下比裸用WFI更安全。比如在CPU进入深度idle之前想要确保唤醒中断源有效用超时机制兜底会减少死等风险。我在项目里通常建议新平台刚开始适配时先保证C1正确再逐步尝试C2/C3不要一上来就追最深状态。2.4 唤醒源与电源域的一致性CPU要进入断电状态硬件上必须保证负责唤醒这个核的中断控制器GIC仍然能工作特别是GIC Redistributor的电源域不能跟着CPU core一起被关掉。这是ARM电源管理里非常容易踩坑的点。有些SoC的GIC redistributor供电属于core power domain有些属于separate always-on domain。如果设计不当可能出现系统深度idle时GIC redistributor掉电外部中断无法送达核心永远无法唤醒最终触发看门狗。排查这种问题要仔细核对SoC的电源域划分图同时配合trace工具观察进入idle前后的GIC寄存器访问是否正常。3. DVFS调频调压与OPP表的设计落地3.1 频率与电压的不解之缘动态电压频率调整DVFS几乎已经是所有ARM SoC的标配。DVFS的核心思想是性能需求低时降低CPU/GPU频率和电压功耗按电压的平方关系下降收益极其明显。但频率和电压不是独立变化的。频率提高供电电压也要相应提高以保证时序收敛。因此SoC厂商会提供一组“工作点”每个工作点包括频率、电压、可能还有额外的性能/泄漏补偿参数这组工作点就是OPPOperating Performance Point。在内核里OPP表通常定义在设备树中通过operating-points-v2节点描述。比如cpu0_opp_table: opp-table-0 { compatible operating-points-v2; opp-shared; opp-1000000000 { opp-hz /bits/ 64 1000000000; opp-microvolt 850000; opp-supported-hw 0x0f; }; opp-1800000000 { opp-hz /bits/ 64 1800000000; opp-microvolt 975000; opp-supported-hw 0x0f; }; };这里opp-supported-hw做硬件版本控制很重要。不同硅片版本revision的SoC可支持的频率点有差异这块表如果配错将会导致硅片在超出规格的电压/频率下运行轻则稳定性问题重则烧毁芯片。3.2 cpufreq框架中的驱动选择与调频策略Linux的cpufreq框架分两个方向一个是调整频率的平台相关部分cpufreq driver一个是指挥如何调的策略部分cpufreq governor。在ARM平台上cpufreq driver通常使用cpufreq-dt驱动它会从设备树解析CPU的OPP表并通过时钟框架和regulator框架去调节时钟频率与供电电压。另一个常见做法是通过SCMI接口让SCP执行调频这时使用scmi-cpufreq或者scmi-cpufreq的变种。governor方面从旧版的interactive、ondemand到现在主流的schedutil。schedutil与调度器直接集成可以根据每个CPU的利用率实时计算目标频率响应快能效表现通常更优也是目前在ARM大小核平台上比较推荐的默认governor。在调试DVFS问题时可以先写死一个频率点做稳定性验证比如echo userspace /sys/devices/system/cpu/cpufreq/policy0/scaling_governor echo 1800000 /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed如果固定频率下系统稳定但自动调频时出现死机或者任务卡顿就可以针对性查看OPP跳变频率、电压切换时序以及regulator的瞬态响应是否满足要求。3.3 CPU调频与DSU/互连频率的协同单独调CPU频率并不够还要考虑总线频率、DSUDynamIQ Shared Unit频率和内存频率。ARM大小核架构中DSU包含L3和互连逻辑它的电压域往往与CPU簇关联。有些平台的CPU频率提升到最高档时必须同步提高DSU频率否则跨核通信和L3访问会变成瓶颈反而削弱性能。此时内核的arm_dsu设备或者互连调频interconnect scaling需要配合起来。常见的做法是在cpufreq的target_index回调里同时设置CPU、DSU和总线频率形成“套餐式”调频方案。这块如果只调CPU而忽略DSU跑测试时会看到单核性能怪异的低很多时候并不是CPU核心不够强而是DSU/总线的频率拖了后腿。设备树里描述CPU频率和DSU频率关联的方式常见是给cluster对应的power domain或者使用dynamic-power-coefficient来辅助能耗模型。不过后者更多是给调度器算能耗用不能解决协同调频的根本问题。3.4 功耗测量与能效模型做DVFS调优一定要建立定量的功耗概念。市面上的开发板基本都有电流采样电阻可以通过板载ADC或外接功率分析仪抓取不同频率点下的电流数据。我通常的做法是固定频率关闭屏幕和外设让DDR自刷新跑idle基线。固定频率跑特定负载比如dhrystone或者glmark2测量满载电流。记录每个OPP下满载与idle的功率差画出一条“能效比曲线”。然后把这些数据反馈到设备树或者能耗模型中比如内核的EMEnergy Model框架。ARM的调度器EASEnergy-Aware Scheduling就是依赖EM数据来决策任务调度和大小核迁移的。如果EM数据不准EAS做出来的调度决策就是错误的可能频繁把任务搬到大核功耗不降反升。4. 系统级低功耗与SoC电源域软件实现4.1 Suspend to RAM与hibernate的区别CPUidle管的是CPU空闲状态系统级挂起则是把整个系统置入一种极低功耗状态通常叫Suspend to RAMS3在ARM平台上可能叫SYSTEM_SUSPEND。进入该状态前系统要冻结用户空间、暂停设备、关闭非唤醒外设然后把内存置为自刷新CPU集群和大部分外设掉电只保留唤醒源相关模块供电。相比S3hibernateS4则把内存镜像写入存储介质后整机断电恢复时再从镜像加载。由于ARM平台对内存映射和设备初始化的强依赖性hibernate在ARM上的恢复流程要更复杂必须保证恢复时所有设备重新初始化到位这块不建议刚接触ARM电源管理的人优先去碰先把S3跑稳定更重要。4.2 设备树中电源域Power Domain的控制在Linux设备树中power-domains属性用于描述设备和电源域之间的所属关系。例如mmc0: mmcfe000000 { compatible arm,pl180; power-domains pd_mmc0; };这里的pd_mmc0通常对应一个genpdGeneric Power Domain实例。在内核中genpd框架统一管理电源域通过pm_runtime接口控制设备的电源。对于需要保持唤醒能力的设备要确保其所属电源域不会被关闭。常见的坑是某个外设挂在一个“系统掉电时会关闭”的电源域但驱动没有实现runtime PM没有在进入suspend前正确配置唤醒源导致唤醒失败。我在调试过程中会重点排查设备树中每个power-domains节点到GIC唤醒通路之间的关系。4.3 SCMI协议与SCP协同SCMI是一个更上层的固件接口协议用于AP和SCPSystem Control Processor之间的通信。它把时钟管理、电源域管理、性能管理DVFS、传感器管理等抽象成一个个协议例如SCMI_BASESCMI_POWER_DOMAINSCMI_PERFORMANCESCMI_CLOCKSCMI_SENSOR在支持SCMI的平台上内核可以直接把dvfs的请求封装成SCMI消息发给SCP由SCP统一调度时钟、电压、电源域。这种设计的好处是SoC供应商可以把时序敏感的电源控制逻辑放在SCP固件中AP侧只做策略决定不用去操作具体寄存器。实现层面Linux内核的SCMI驱动来源于drivers/firmware/arm_scmi/设备树中要声明scmi节点以及对应的scmi_dvfs、scmi_power等协议通道。我在适配SCMI平台时遇到过因为SCMI通道中断号配置错误导致消息无响应的问题。排查方法是先用内核提供的scmi_debugfs或协议里面对应的get_version命令确认基础通信是否正常。4.4 热管理与电源管理的耦合为什么热管理要放进电源管理架构里来谈因为动态控制频率和电压结果会直接影响SoC温度。反过来温度传感器读到的数据也会通过cpufreq的热限制机制thermal throttle影响频率。两者是一个闭环。ARM平台上最常见的方案是板卡上放置多个温度传感器通过devicetree注册到thermal-zones节点然后配置thermal trip点例如60度开始降频、80度触发强劲降频、90度直接关机保护。用lm-sensors或thermal_zone0的sysfs节点能够实时监控温度cat /sys/class/thermal/thermal_zone0/temp cat /sys/class/thermal/cooling_device0/cur_state在功耗和性能调优时如果发现同一负载下温度偏高除了检查散热也要检查DVFS调频策略是否过于激进。有时候看似CPU频率不高但因为电压过高功耗依然很大这时调整regulator的电压标定值会有明显收益。5. 实操调试方法与常见问题排查5.1 用ftrace和tracefs追踪idle和频率变化排查电源管理问题时ftrace是最常用的工具。它可以跟踪CPU热插拔、cpuidle进入退出、cpufreq调频等事件。开启方法大致如下echo 0 /sys/kernel/debug/tracing/tracing_on echo function_graph /sys/kernel/debug/tracing/current_tracer echo cpuidle:cpuidle_enter cpufreq:cpufreq_target /sys/kernel/debug/tracing/set_event echo 1 /sys/kernel/debug/tracing/tracing_ontrace输出里可以看到每个CPU进入哪个cstate、停留时间、退出原因。配合trace-cmd和kernelshark可以直观看出CPUidle切换是否过于频繁以及是否有CPU长期卡在深状态导致中断延迟异常。调频事件的追踪则能看到目标频率与实际频率的差异。如果请求频率是一回事硬件实际运行频率是另一回事极度容易引发时序问题这时候要去查时钟驱动和SCP固件是否正确回应了调频请求。5.2 高负载场景下系统莫名重启怎么办这种问题通常要被严肃对待。先从以下几点排查供电瞬态CPU突然跳到最高频瞬间电流冲击可能导致电压跌落触发复位。查看PMIC的瞬态响应、PCB走线必要时在软件上限制调频步进分多步慢慢升频。温度保护确认是否触发了thermal shutdown读取/sys/class/thermal/thermal_zone*/temp以及在崩溃前的内核日志中搜索thermal相关消息。OPP表配置错误某个频点对应的电压低于硬件需求高负载时时序不稳定。可将该OPP的电压抬高再做长时间压力测试。缓存一致性问题在大小核平台如果CPU对某段内存的访问权限或缓存状态管理有问题高负载场景下死锁概率会增加。这会表现为随机死机而非固定频率死机排查时要开启CONFIG_DEBUG_SPINLOCK等内核调试选项。5.3 唤醒源配置常见遗漏在系统suspend后无法通过按键唤醒是最常被报告的问题之一。常见原因包括GPIO唤醒线没有在设备树中配置wakeup-source。外设的电源域没有被正确保持。GIC在系统挂起状态下被关闭。唤醒中断被嵌套在了禁用的普通中断中。调试时先在U-Boot或者最小化系统里测试同样的外设能否唤醒以区分是硬件还是软件问题。然后检查内核中使用irq_set_irq_wake的调用以及/proc/interrupts中被标记为唤醒的中断情况。5.4 CPUidle的target_residency参数调整经验我遇到过一些平台在默认参数下CPU总是倾向于进入过深的idle状态导致隔壁核唤醒它时需要几十微秒甚至上百微秒。这种延迟对网络游戏、音频处理这类对调度延迟敏感的应用是无法接受的。解决方案有两个方向调整cpuidle相关参数比如/sys/devices/system/cpu/cpuidle/下各状态节点的target_residency和exit_latency把它调大一些让CPU更“懒”一点不要轻易进入深状态。通过PM_QOS框架设置要求的唤醒延迟例如让音频驱动设置一个比较小的latency预算内核会自动屏蔽不满足条件的更深idle状态。这种基于QoS的自适应机制是现代SoC电源管理里很重要的一个环节做产品时一定不要忽略。5.5 固件层与内核层接口版本不一致的坑ARM平台上的固件和内核是独立开发的PSCI版本不匹配是常见坑。比如内核期望PSCI 1.0但固件只支持0.2或者反过来。在启动早期内核会通过psci_check_mode做兼容检查如果版本低于所需会直接拒绝相关功能或者限制深度idle的使用。调试时可以用以下命令查看当前PSCI版本cat /sys/firmware/devicetree/base/psci/version或者通过SMC直接调用PSCI_VERSION指令来看。如果发现固件版本过旧需要升级TF-A或者对应SoC的ATF BL31镜像。还有一点要注意PSCI调用使用的function_id在不同版本里可能有所差异尤其是CPU_SUSPEND和SYSTEM_SUSPEND这类复合功能的参数约定一定要以SoC手册为准。5.6 常见问题速查表下面整理一份我实际调试中常用的问题定位表格方便对照排查。现象可能原因初步处理CPU无法进入深度idlePSCI状态参数错误target_residency过大检查设备树idle状态配置临时调小target_residency测试深度idle后无法唤醒GIC电源域被错误关闭唤醒源未配置检查GIC/唤醒源供电启用wakeup-source高负载下意外重启OPP电压不足thermal保护触发供电瞬态跌落拉高对应OPP电压检查thermal日志限制瞬时调频速率调频后系统卡死时钟切换时序问题regulator反馈慢检查clk驱动调节regulator瞬态参数降低调频频率Suspend后功耗居高不下外设未正确挂起电源域未关闭逐个关闭外设测试利用功耗计定位耗电设备唤醒延迟过大deepidle进入过频繁GIC唤醒路径延长调整PM_QOS限制或修改cpuidle状态参数SCMI通信无响应中断号配置错误SCP固件crash检查设备树scmi节点打开SCMI日志确认SCP运行状态5.7 实际调试工具集推荐除了前面提到的ftrace手头常备的还有perf stat -e power/energy-*查看CPU能耗预估cpupower管理调频governor查看硬件频率dmesg重点过滤cpu_cooling、thermal、regulator等关键词crash或kdump死机后抓取内核转储分析最后进入的电源状态logic analyzer测量SWD或GPIO信号确认硬件时序工具的熟练度在排查复杂电源问题时非常关键。只有把内核层面的trace和硬件层面的波形结合起来才能快速定位“软件以为自己在调频但硬件根本没响应”的这类深层问题。6. 我的一些项目经验与调优心得6.1 一开始别贪深先保住稳定基线很多新人在拿到开发板后喜欢直接开启最深idle、最高频率进行“性能测试”结果一跑就死然后怀疑硬件有问题。实际上电源管理的每一步都是“一个状态一棵雷”。我的经验是分阶段验证先关闭所有自动调频和深度idle确保系统全速运行稳定。把DVFS打开固定voltage只测两三个低频点。逐步开放高频点和升降频节奏跑长时间压力测试。最后才开启深度idle和suspend/resume测试。这个过程看起来保守但能帮你在第一时间区分问题出在DVFS、idle还是suspend路径上避免所有变量搅在一起。6.2 记录“异常前的最后一次状态”调试电源管理问题最怕的是死机后无从下手。尤其是深度idle失败导致的挂起很多情况下连串口都没有输出因为唤醒源没有把CPU唤醒。所以从项目一开始就应该保留一个独立的调试串口并且开启earlyprintk或earlycon。这样即便内核在启动电源状态切换时发生问题也能看到最后一条日志。同时在死机前尽量让系统打印出当前CPU的频率、idle状态、regulator电压、温度等关键信息。可以写一个定期记录脚本或者内核sysrq工具帮助追溯异常前的状态。6.3 仔细看ERRATA和SoC手册ARM官方和各SoC厂商的芯片手册都会列出电源管理相关的ERRATA。很多平台的深度idle或者调频都有已知勘误比如某些版本在特定条件下不能进入cluster power down否则L2数据会丢失。这些ERRATA如果不看只靠做实验去踩坑效率极低也容易把正确的配置误判为软件bug。建议每个项目启动前梳理SoC的勘误表把涉及电源管理的条款单独摘出来做成一个“可用的idle状态/频率点/电压点”的检查清单。这样在配置设备树时就有了权威依据而不是靠猜。6.4 从功耗数据反推配置好坏做电源管理最终要回归到功耗数字。用功率分析仪在固定场景下记录整机功耗比如待机、播放视频、运行多核负载然后对比每次软件改动后的功耗曲线。如果某次改动后性能相同但功耗下降了5%这就是正向收益如果性能掉了10%但功耗只降了2%那就说明配置不合理。另外很多团队最容易忽略的是“不用时的功耗”也就是idle和suspend下的泄漏功耗。ARMv9 SoC因为晶体管密度大泄漏不可忽视这时候依赖DVFS降频可能还不够还需要结合retention、power gating以及AVSAdaptive Voltage Scaling等手段去压榨最后几个毫瓦。AVS技术在手机端很多SoC上已经是标配它根据芯片体质自动微调电压目的是在保证良率和可靠性前提下尽可能降低电压功耗。6.5 团队协作中要约定接口文档电源管理系统架构涉及硬件设计、固件、内核、BSP多个团队的协作如果没有明确的接口约定很容易各做各的。我建议项目在早期就建立如下约定设备树里idle状态命名规则。PSCI power_state参数含义的文档化。cpufreq governor默认选择。热限制策略阈值。唤醒源配置的标准模板。这些约定即使不形成复杂文档只写成一份简短的README也能在后续调试中节省大量沟通成本。6.6 从一个真实的“调优案例”说起之前有款双核A55的IoT产品电池供电待机功耗目标定在20mW以内。刚开始拿到板子时纯待机功耗是80mW。经过一系列排查发现主要问题有三个一是CPUidle的C1状态entry过于频繁导致CPU无法真正进入C2power gate一直不生效二是板上一颗USB Hub芯片没进入suspend三是DDR频率始终跑在满频没有根据负载降频。针对这三个问题我分别做了调整把C1的target_residency调大让系统尽早进入C2在USB驱动里加上runtime PM和suspend处理给DMC设备挂上devfreq并配置对应的调频策略。最终待机功耗稳定在了18mW。整个过程中没有碰到“玄学”问题都是配置粒度太粗、没把每个模块管到位造成的。6.7 对新手的三句话建议如果你刚开始接触ARMv9/v8电源管理架构我给你三句话先把PSCI和CPUidle跑通再看DVFS和SCMI顺序不能乱。所有idle状态和频率点都要能解释“为什么是这个参数”不能照抄。遇到死机不要慌先固化变量再逐层放开功能定位问题的边界。电源管理不是一个“打开某个开关”就能做完的事它需要持续的测量、对比和迭代。系统的稳定性和功耗收益是在一遍遍跑压力、一遍遍看trace、一遍遍调参数中打磨出来的。只要把架构理解了把工具链和排查路径跑顺再复杂的电源问题也能找到头绪。最后在做这套架构设计时一定要把低功耗的验证计划放到项目排期的最前面不要最后才烧主板测功耗。等到功能全部做完再回头优化电源那时候延迟、唤醒、稳定性的代价会让你非常头疼。