Android Power HAL如何实现灵活的功耗管理策略？

在 Android 设备上，一次触摸滑动、应用冷启动或视频播放都可能引发 CPU 频率、GPU 电压和总线带宽的明显变化。上层应用只负责请求渲染或计算，真正决定硬件以多大功耗运行的环节在 HAL 层。Power HAL 作为电源管理的硬件抽象层，向上接收 PowerManager 和系统服务下发的提示，向下通过节点、驱动或固件接口调节设备状态。

一、Power HAL 在电源栈中的角色

Android 电源管理可以粗略分成四个层面。最上层是应用和框架 API，例如 JobScheduler、AlarmManager 的唤醒策略，以及 Activity 生命周期带来的可见性变化。第二层是 system_server 中的 PowerManagerService，它维护唤醒锁、用户活动计时器和 Doze 状态机。第三层是 HAL 接口定义，也就是 android.hardware.power。最底层是厂商实现，可能调用 devfreq、cpufreq、thermal、GPU sysfs 节点，或者通过更底层的硬件抽象与内核通信。

Power HAL 的关键价值在于把不依赖具体硬件的策略和依赖具体硬件的操作解耦。Google 提供接口规范和默认参考实现，芯片厂商则根据 SoC 的能效曲线、调度器行为、温控约束来填充具体逻辑。比如同样一个 INTERACTION hint，高端平台上可能只需要把 CPU 频率短暂拉升到中等水平，低端平台则可能需要同时提高内存带宽并唤醒输入 boost。框架层并不关心这些细节，它只发出意图。

这种分层还带来一个好处：系统升级或内核调度器更换时，不必改动 Java 层的策略代码。工程师可以在 Power HAL 内部调整 governor 参数、CPU 亲和性或设备状态切换条件，使同一套 Android 框架适配不同硬件平台。不过灵活性也意味着 vendor 实现质量直接影响整机续航，如果 HAL 对 hint 不做区分或延迟过高，上层策略就会失效。

二、核心接口与投票合并机制

当前 Power HAL 主要通过 AIDL 定义，核心方法包括 powerHintAsync、setMode 和 getFeature。powerHintAsync 是异步提示，调用方把 hint 和数据交给 HAL 后立即返回，HAL 在内部线程或工作队列中处理。常见的 hint 有 INTERACTION、LAUNCH、LOW_POWER、SUSTAINED_PERFORMANCE、VR_MODE 等。每个 hint 带有 32 位 data 参数，例如 LAUNCH 可以携带应用冷启动的阶段信息，INTERACTION 可以携带持续时间或输入来源。

setMode 用来切换持续时间较长的模式，而不是瞬时提示。典型模式包括 LOW_POWER、SUSTAINED_PERFORMANCE、VR_MODE、DOUBLE_TAP_TO_WAKE 等。与 hint 不同，mode 具有开关语义，框架层通过 enabled 参数要求进入或退出某个模式。多个客户端可能同时请求模式，HAL 需要维护引用计数或投票状态，只有当所有请求都释放后才真正关闭硬件状态。

下面是一段 AIDL 接口的简化示例，可以观察方法签名和参数类型。

// IPower.aidl 关键方法
interface IPower {
    void powerHintAsync(int hint, int data);
    void setMode(int mode, boolean enabled);
    int getFeature(String feature);
}

厂商实现中经常遇到多个 hint 并发到达的情况。比如前台 Activity 正在启动，同时用户还在连续触摸屏幕，LAUNCH 和 INTERACTION 会同时存在。实现者需要设计投票合并逻辑。一个常见做法是为每个硬件资源维护一个 boost 请求计数或最大值时间戳。CPU 投票聚合可以用一个数组记录每个客户端请求的最低频率或最高频率，然后取最保守或最激进的组合，结合温控限制后下发。下面给出一段简化的 CPU boost 投票逻辑。

#include <vector>
#include <mutex>
#include <algorithm>
#include <chrono>

class CpuBoostVoter {
 public:
    void requestBoost(int durationMs, int minFreq) {
        std::lock_guard<std::mutex> guard(mutex_);
        auto now = std::chrono::steady_clock::now();
        boostExpiry_.push_back(now + std::chrono::milliseconds(durationMs));
        int targetFreq = std::max(minFreq, currentBoostFreq_);
        if (targetFreq != currentBoostFreq_) {
            currentBoostFreq_ = targetFreq;
            applyMinFreq(targetFreq);
        }
    }

    void expireBoosts() {
        std::lock_guard<std::mutex> guard(mutex_);
        auto now = std::chrono::steady_clock::now();
        boostExpiry_.erase(
            std::remove_if(boostExpiry_.begin(), boostExpiry_.end(),
                [now](std::chrono::steady_clock::time_point t) {
                    return t <= now;
                }),
            boostExpiry_.end());
        if (boostExpiry_.empty() && currentBoostFreq_ != 0) {
            currentBoostFreq_ = 0;
            applyMinFreq(0);
        }
    }

 private:
    void applyMinFreq(int freq) {
        // 写 cpufreq 节点或调用内核接口
        (void)freq;
    }

    std::mutex mutex_;
    std::vector<std::chrono::steady_clock::time_point> boostExpiry_;
    int currentBoostFreq_ = 0;
};

三、典型功耗策略与厂商实现差异

不同平台对同一 hint 的处理差异很大。以 INTERACTION 为例，它的语义是用户正在与设备交互，期望降低输入延迟。在部分高通平台上，Power HAL 会调用 perf 服务设置 CPU 最低频率，并把调度器迁移负载阈值调低；在部分联发科平台上，则可能通过 EARA 或内核接口进行资源预算分配。采用相同接口，不表示策略一致。

SUSTAINED_PERFORMANCE 是另一个容易产生理解偏差的模式。它并不意味着把所有核心拉到最高频率，而是要求在一个较长时间窗口内提供可预测的持续性能，同时避免触发强温控。若 HAL 实现时简单把 governor 切到 performance，设备可能在几分钟内撞上热墙，随后大幅降频，体验反而更差。合理的做法是限制最高频率或绑定性能核，使温度曲线平缓。

在 Android 的省电模式中，框架层会调用 setMode 开启 LOW_POWER，Power HAL 收到后通常不只是调低 CPU 最大频率，还会减少触摸 boost、降低 GPU 最高频率、限制内存带宽，并可能延后非关键任务的唤醒。部分厂商还会结合自己的游戏模式或视频增强模式叠加额外 hint，例如检测到视频播放时主动保持最低频率稳定，避免频繁升频造成功耗浪费。

下面展示一个简化的 XML 配置，用于说明某些厂商如何把 hint 映射为可调整参数。这种配置通常放在 vendor 分区，不同版本结构会有变化。

<power-hint-config>
    <hint name="INTERACTION">
        <cpu>
            <min-freq>800000</min-freq>
            <boost-ms>1500</boost-ms>
        </cpu>
        <gpu>
            <min-freq>300000000</min-freq>
        </gpu>
    </hint>
    <hint name="SUSTAINED_PERFORMANCE">
        <cpu>
            <max-freq>1900800</max-freq>
        </cpu>
    </hint>
</power-hint-config>

四、调试与验证功耗策略

排查功耗问题时，首先要确认框架层确实发出了预期的 hint 或 mode 请求。可以使用 dumpsys 查看 PowerManager 和 Power HAL 的状态。不同 Android 版本命令略有不同，较新版本可以通过以下命令查看 HAL 信息。

adb shell dumpsys android.hardware.power.IPower/default
adb shell dumpsys power | grep -i "mWakefulness\|mIsPowered\|hint"

如果 dumpsys 显示 hint 已下发但 CPU 频率没有变化，问题通常出在 HAL 内部或底层节点。此时可以抓取 systrace，打开 power 类别，观察 power_hint 的起始时间和持续时间，再对比 cpu_frequency 轨道。若 hint 在 trace 中存在，但频率在数十毫秒后才变化，说明 boost 延迟过高；若完全看不到频率变化，则要检查 vendor 库是否正确写入了 cpufreq 或 devfreq 节点。

另一个常见问题是 mode 没有正确退出。比如应用调用 setMode 开启 SUSTAINED_PERFORMANCE 后崩溃，没有执行关闭操作，如果 HAL 不做异常回收，设备会一直维持高性能状态。因此在实现 HAL 时，应当为耗时 mode 设置看门狗或与客户端 binder 死亡通知联动，及时清理无效投票。Framework 侧通常依赖 binder 生命周期，但 vendor 实现不能完全假设框架一定回调。

日常调优中，不能只看平均功耗，还要观察功耗抖动。有些策略频繁提升 CPU 最低频率，虽然平均电流增加不多，但会破坏调度器的深度休眠机会。可以通过统计 power hint 的触发次数和每次持续时间评估策略是否过于激进。把频率变化、任务迁移和 idle 状态结合分析，才能判断一个 hint 的收益是否大于额外功耗。

Android Power HAL功耗管理电源策略修改时间：2026-09-23 15:45:06