性能管理

对 Android 设备的电量和性能进行管理，有助于确保应用能够在各类硬件上稳定、顺畅地运行。在 Android 7.0 及更高版本中，OEM 可支持提供持续性能提示以便应用能够维持稳定的设备性能，并可指定专属核心以便提高 CPU 密集型前台应用的性能。

持续性能

对于长时间运行的应用（例如，游戏、相机、RenderScript 和音频处理应用）来说，当设备达到极限温度且系统芯片 (SoC) 引擎受到限制时，性能便可能会出现急剧变化。当设备开始升温时，底层平台的功能会变得飘忽不定，这会限制应用开发者打造可长时间运行的高性能应用。

为解决此类限制，Android 7.0 引入了对持续性能的支持，让 OEM 能够为长时间运行的应用提供设备性能提示。应用开发者可以使用这些提示来根据可预测的一致设备性能水平调整长期应用。

架构

Android 应用可以请求平台进入持续性能模式，使 Android 设备能在长时间内保持稳定的性能水平。

图 1. 持续性能模式架构

实现

为支持 Android 7.0 及更高版本实现持续性能，OEM 必须：

  • 针对具体设备更改 HAL 的电量文件，以锁定最大 CPU/GPU 频率或执行其他优化来防止出现过热保护。
  • 在 HAL 的电量文件中实现新提示 POWER_HINT_SUSTAINED_PERFORMANCE。
  • 通过使用 isSustainedPerformanceModeSupported() API 返回 TRUE 来声明支持。
  • 实现 Window.setSustainedPerformanceMode。

在 Nexus 参考实现中，电量提示将 CPU 和 GPU 的最大频率设定为最高可持续水平的频率。请注意，降低 CPU/GPU 频率的上限会降低帧速率，但由于此种较低的速率具有可持续性，因此在该模式下它依然是首选。例如，某部使用正常最大时钟频率的设备或许能以 60 FPS 的速度渲染几分钟，但当该设备持续升温，则可能会在渲染 30 分钟后调节到 30 FPS。而当使用持续模式时，该设备就可能会以 45 FPS 的速度持续渲染整整 30 分钟。这样做的目的是：通过使用该模式，获得一个与不使用该模式时相同（或更高）的帧速率，而且该速率能在长时间内维持稳定水平，使开发者不必费心追逐一个飘忽不定的目标。

我们强烈建议您采用持续模式，使设备能够达到最高可持续性能，而非仅仅达到为通过测试而需采用的最小值（例如，选择不会导致设备长时间运行后进入过热保护的最高频率上限）。

注意：实现持续模式不需要设定时钟频率的最大速率上限。

验证

OEM 可以使用 CTS 测试（适用于 Android 7.0 及更高版本）来验证持续性能 API 的实现情况。这项测试会运行工作负载大约 30 分钟，并会分别在启用和不启用持续模式的情况下对性能进行基准测试：

  • 启用持续模式后，帧速率必须保持相对恒定（这项测试会测量帧速率在一段时间内的变化幅度百分比，且会要求该比例 <5%）。
  • 启用持续模式后，帧速率不得低于在不启用持续模式的情况下 30 分钟结束时的帧速率。

此外，您可以对 CPU 和 GPU 进行多个高负荷工作来手动测试设备的实现情况，确保设备在使用 30 分钟后不会进入过热保护。在内部测试中，我们会使用游戏和基准测试应用（例如 gfxbench）等示例工作负载。

专属核心

对于 CPU 密集型、时间敏感型工作负载，被另一个线程抢占可能会影响到能否按各个帧的预定截止时间完成渲染。对于具有严格的延迟时间要求和帧速率要求的应用（如音频应用或虚拟现实应用），具有专属 CPU 核心能够保证实现可接受的性能水平。

运行 Android 7.0 或更高版本的设备现可为最主要前台应用明确保留一个核心，这不仅能提高所有前台应用的性能，还能让运行高强度工作负载的应用更好地控制其任务在各 CPU 核心上的分配方式。

如需支持在设备上使用专属核心，请执行以下操作：

  • 启用 cpusets 并配置仅包含最主要前台应用的 cpuset。
  • 确保为来自此 cpuset 的线程保留一个核心（即专属核心）。
  • 实现 getExclusiveCores API 以返回这个专属核心的核心编号。

如需确定哪些进程被安排在哪些核心上，请在运行任意工作负载时使用 systrace，并验证是否只有来自最主要前台应用的用户空间线程被安排在专属核心上。

如需查看 Nexus 6P 的参考实现，请参阅 android//device/huawei/angler/power/power.c。