管理 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 频率的 MAX 值会降低帧速率，但由于其可持续性，在此模式下，较低的速率是首选的。例如，使用正常最大时钟频率的设备可能能够在几分钟内以 60 FPS 渲染，但在设备升温后，在 30 分钟结束时可能会节流至 30 FPS。当使用持续模式时，例如，设备可以在整个 30 分钟内始终如一地以 45 FPS 渲染。目标是在使用该模式时的帧速率高于（或等于）不使用该模式时的帧速率，并且随时间推移保持一致，以便开发者不必追逐移动的目标。
我们强烈建议实施持续模式，以便设备实现尽可能高的持续性能，而不仅仅是满足测试所需的最低值（例如，选择不会导致设备随时间推移发生热节流的尽可能高的 MAX 频率上限）。
注意：实施持续模式不需要限制 MAX 时钟频率。
验证
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。