自 2025 年 3 月 27 日起,我們建議您使用 android-latest-release
而非 aosp-main
建構及貢獻 AOSP。詳情請參閱「Android 開放原始碼計畫變更」。
績效管理
透過集合功能整理內容
你可以依據偏好儲存及分類內容。
管理 Android 裝置的電力和效能,有助於確保應用程式在各種硬體上執行時能維持一致性和流暢度。在 Android 7.0 以上版本中,原始設備製造商 (OEM) 可以實作持續效能提示的支援功能,讓應用程式維持一致的裝置效能,並指定專屬核心,以改善 CPU 密集式前景應用程式的效能。
對於長時間執行的應用程式 (遊戲、相機、RenderScript、音訊處理),效能可能會因達到裝置溫度限制而大幅變化,且晶片系統 (SoC) 引擎會受到限制。應用程式開發人員在打造高效能、長時間執行的應用程式時,會受到限制,因為當裝置開始升溫時,基礎平台的功能會變動。
為解決這些限制,Android 7.0 推出了持續效能支援功能,讓原始設備製造商 (OEM) 可針對長時間執行的應用程式提供裝置效能功能提示。應用程式開發人員可以利用這些提示,調整應用程式,讓裝置在長時間內維持可預測且一致的效能。
建築
Android 應用程式可以要求平台進入持續效能模式,讓 Android 裝置在長時間內維持一致的效能。

圖 1. 持續效能模式架構。
實作
如要在 Android 7.0 以上版本維持持續的效能,原始設備製造商必須:
- 針對電源 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 時脈率。
驗證
原始設備製造商 (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
。
這個頁面中的內容和程式碼範例均受《內容授權》中的授權所規範。Java 與 OpenJDK 是 Oracle 和/或其關係企業的商標或註冊商標。
上次更新時間:2025-07-27 (世界標準時間)。
[[["容易理解","easyToUnderstand","thumb-up"],["確實解決了我的問題","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["缺少我需要的資訊","missingTheInformationINeed","thumb-down"],["過於複雜/步驟過多","tooComplicatedTooManySteps","thumb-down"],["過時","outOfDate","thumb-down"],["翻譯問題","translationIssue","thumb-down"],["示例/程式碼問題","samplesCodeIssue","thumb-down"],["其他","otherDown","thumb-down"]],["上次更新時間:2025-07-27 (世界標準時間)。"],[],[],null,["# Performance management\n\nManaging the power and performance of Android devices can help ensure\napps run consistently and smoothly on a wide range of hardware. In\nAndroid 7.0 and later, OEMs can implement support for sustained performance hints that\nenable apps to maintain a consistent device performance and specify an exclusive\ncore to improve performance for CPU-intensive, foreground apps.\n\nSustained performance\n---------------------\n\nFor long-running apps (games, camera,\n[RenderScript](/docs/core/architecture/vndk/renderscript), audio\nprocessing), performance can vary dramatically as device temperature limits are\nreached and system on chip (SoC) engines are throttled. App developers creating\nhigh-performance, long-running apps are limited because the capabilities of the\nunderlying platform are a moving target when the device begins to heat up.\n\nTo address these limitations, Android 7.0 introduced support for sustained\nperformance, enabling OEMs to provide hints on device performance capabilities\nfor long-running apps. App developers can use these hints to tune\napps for a predictable, consistent level of device performance over long\nperiods of time.\n\n### Architecture\n\nAn Android app can request the platform to enter a sustained\nperformance mode where the Android device can keep a consistent level of\nperformance for prolonged periods of time.\n\n**Figure 1.** Sustained performance mode\narchitecture.\n\n### Implementation\n\nTo support sustained performance in Android 7.0 and later, OEMs must:\n\n- Make device-specific changes to the power HAL to either lock the maximum CPU/GPU frequencies **or** perform other optimizations to prevent thermal throttling.\n- Implement the new hint `POWER_HINT_SUSTAINED_PERFORMANCE` in power HAL.\n- Declare support by returning TRUE through the `isSustainedPerformanceModeSupported()` API.\n- Implement `Window.setSustainedPerformanceMode`.\n\nIn the Nexus reference implementation, the power hint caps the\nmaximum frequencies of the CPU and GPU at the highest sustainable levels. Keep\nin mind that lowering the MAX bar in CPU/GPU frequency will lower the frame\nrate, but this lower rate is preferred in this mode due to its sustainability.\nFor example, a device using normal max clocks might be able to render at 60\nFPS for a few minutes, but after the device heats up, it may throttle to 30 FPS\nby the end of 30 minutes. When using sustained mode, the device can, for\nexample, render consistently at 45 FPS for the entire 30 minutes. The goal is a\nframe rate when using the mode that is as high (or higher) than the frame rate\nwhen not using the mode, and consistent over time so that developers don't have\nto chase a moving target.\n\nWe strongly recommend implementing sustained mode such that the device\nachieves the highest possible sustained performance---not just the minimum values\nrequired to pass the test (e.g. choose the highest possible MAX frequency caps\nthat don't cause the device to thermally throttle over time).\n\n**Note**: Capping MAX clock rates isn't required\nto implement sustained mode.\n\n### Validation\n\nOEMs can use a CTS test (Android 7.0 and later) to verify their implementation of the\nsustained performance API. The test runs a workload for approximately 30 minutes\nand benchmarks the performance with and without sustained mode enabled:\n\n- With sustained mode enabled, the frame rate must remain relatively constant (test measures the percentage of change in frame rate over time and requires a \\\u003c5% change).\n- With sustained mode enabled, the frame rate must not be lower than the frame rate at the end of 30 minutes with the mode disabled.\n\nIn addition, you can manually test your implementation with several CPU- and\nGPU-intensive workloads to ensure the device doesn't thermally throttle after\n30 minutes of use. In internal testing, we used sample workloads including\ngames and benchmarking apps (e.g.\n[gfxbench](https://gfxbench.com/result.jsp)).\n\nExclusive cores\n---------------\n\nFor CPU-intensive, time-sensitive workloads, getting preempted by another\nthread can be the difference between making frame deadlines or not. For apps\nthat have strict latency and frame rate requirements (such as audio or virtual\nreality apps), having an exclusive CPU core can guarantee an acceptable level of\nperformance.\n\nDevices running Android 7.0 or later can now reserve one core explicitly for the top\nforeground app, improving performance for all foreground apps and giving\napps with high intensity workloads more control over how their work is allocated\nacross CPU cores.\n\nTo support an exclusive core on a device:\n\n- Enable `cpusets` and configure a `cpuset` that contains only the top foreground app.\n- Ensure one core (this is the exclusive core) is reserved for threads from this `cpuset`.\n- Implement the getExclusiveCores API to return the core number of the exclusive core.\n\nTo determine which processes are scheduled on which cores, use\n`systrace` while running any workload and verify no userspace threads\nfrom apps other than the top foreground app are scheduled on the\nexclusive core.\n\nTo view a reference implementation for the Nexus 6P, refer to\n`android//device/huawei/angler/power/power.c`."]]