自 2025 年 3 月 27 日起，我們建議您使用 android-latest-release 而非 aosp-main 建構及貢獻 AOSP。詳情請參閱「Android 開放原始碼計畫變更」。
找出容量相關卡頓問題
透過集合功能整理內容
你可以依據偏好儲存及分類內容。
容量是指裝置在一段時間內擁有的某些資源 (CPU、GPU 等) 總量。本頁說明如何找出並解決容量相關的卡頓問題。
控制器回應速度緩慢
為避免卡頓，CPU 頻率節流器必須能夠快速回應突發的工作負載。大部分的 UI 應用程式都遵循相同的基本模式：
- 使用者正在閱讀畫面。
- 使用者觸碰螢幕：輕觸按鈕、捲動畫面等。
- 螢幕會在回應輸入時捲動、變更活動或以某種方式顯示動畫。
- 系統會在顯示新內容時進入休眠狀態。
- 使用者返回閱讀畫面。
Pixel 和 Nexus 裝置會實作觸控提升功能，藉此修改觸控時的 CPU 頻率節流器 (和排程器) 行為。為避免時脈頻率緩慢升高 (可能導致裝置在觸控時掉幀)，觸控加速功能通常會在 CPU 上設定頻率下限，確保在觸控時有充足的 CPU 容量。觸碰後，地板會持續一段時間 (通常約兩秒)。
Pixel 也會使用由能源感知排程 (EAS) 提供的 schedtune cgroup，做為額外的觸控提升信號：熱門應用程式會透過 schedtune 獲得額外權重，確保有足夠的 CPU 容量可快速執行。相較於搭載 Kryo CPU 的 Pixel，Nexus 5X 和 6P 在小 CPU 叢集 (分別為 A53 和 A57) 和大 CPU 叢集之間的效能差距更大。我們發現，小 CPU 叢集不一定能順利轉譯 UI，特別是考量到裝置上其他造成抖動的來源。
因此，在 Nexus 5X 和 6P 上，觸控加速功能會修改排程器行為，讓前景應用程式更有可能移至大核心 (這在概念上類似於 CPU 頻率的下限)。如果未變更排程器，讓前景應用程式更有可能移至大型 CPU 叢集，前景應用程式可能會因 CPU 容量不足而無法轉譯，直到排程器決定將執行緒負載平衡至大型 CPU 核心為止。在觸控加速期間變更排程器行為，可讓 UI 執行緒立即在大型核心上執行，並避免發生卡頓情形，但不會強制執行緒一律在大型核心上執行，這可能會嚴重影響耗電量。
熱控
當裝置必須降低整體熱輸出時，就會發生溫度調節，通常會透過降低 CPU、GPU 和 DRAM 時脈來執行。毫不意外，這通常會導致卡頓，因為系統可能無法再提供足夠的效能，無法在指定的時間片中算繪。避免熱降速的唯一方法是減少電力消耗。這類情況的解決方法不多，但根據我們過去的 SOC 經驗，我們有幾項建議提供給系統供應商。
首先，在使用異質 CPU 架構建構新的 SOC 時，請確保 CPU 叢集的效能/W 曲線重疊。整個處理器的整體效能/W 曲線應為連續線。效能/W 曲線中的不連續性會迫使調度器和頻率節流器猜測工作負載的需求；為了避免卡頓，調度器和頻率節流器會將工作負載的容量設為高於所需容量。這會導致耗電量過高，進而導致熱節流。
假設有一個 SOC 包含兩個 CPU 叢集：
- 叢集 1 (小叢集) 的耗電量介於 100 至 300 毫瓦之間，在處理量基準測試中獲得的得分則介於 100 至 300 之間，具體取決於時脈。
- 叢集 2 (大型叢集) 的耗電量介於 1000 和 1600 毫瓦之間，在相同的總處理量基準測試中，分數介於 800 和 1200 之間，具體取決於時脈。
在這個基準測試中，分數越高表示速度越快。雖然速度越快不如速度較慢，但耗電量也越高。
如果排程器認為 UI 工作負載需要在該吞吐量基準測試中獲得 310 分的分數，為了避免卡頓，最佳做法就是以最低頻率執行大型叢集，但這會造成大量電力浪費。(這取決於 CPU 閒置行為和競爭閒置；具有連續效能/瓦特曲線的 SOC 較容易進行最佳化)。
其次，請使用 cpuset。請確認您已在核心和 BoardConfig.mk 中啟用 cpuset。您還必須在裝置專屬的 init.rc 中設定實際的 cpuset 指派。部分供應商會在 BSP 中停用這項功能，希望能使用其他提示來影響排程器行為；我們認為這不合理。cpuset 可用於確保 CPU 之間的負載平衡方式，反映使用者在裝置上實際執行的操作。
ActivityManager 會根據應用程式的相對重要性 (頂層、前景、背景)，將應用程式指派至不同的 CPU 集合，重要性較高的應用程式可獲得更多 CPU 核心存取權。這有助於確保前景和熱門應用程式的服務品質。
cpuset 可用於同質 CPU 設定，但如果裝置採用異質 CPU 設定，則不應啟用 cpuset。Nexus 6P 是使用 CPU 集合來處理不同 CPU 設定的理想模型，可做為您自身裝置設定的基礎。
cpuset 還可提供省電優勢，確保非效能關鍵的背景執行緒不會將負載平衡至大 CPU 核心，因為大 CPU 核心會耗費大量電力，但使用者不會因此獲得任何好處。這也有助於避免熱節流。雖然溫度調節是容量問題，但在溫度調節期間，抖動改善作業會對 UI 效能造成極大影響。由於系統會以更接近 60FPS 的渲染能力運作，因此需要的抖動較少，才會導致影格遺失。
這個頁面中的內容和程式碼範例均受《內容授權》中的授權所規範。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,["# Identify capacity-related jank\n\nCapacity is the total amount of some resource (CPU, GPU, etc.) a device\npossesses over some amount of time. This page describes how to identify and\naddress capacity-related jank issues.\n\nGovernor slow to react\n----------------------\n\nTo avoid jank, the CPU frequency governor needs to be able to respond quickly\nto bursty workloads. Most UI apps follow the same basic pattern:\n\n1. User is reading the screen.\n2. User touches the screen: taps a button, scrolls, etc.\n3. Screen scrolls, changes activity, or animates in some way in response to input.\n4. System quiesces as new content is displayed.\n5. User goes back to reading the screen.\n\nPixel and Nexus devices implement touch boost to modify CPU frequency\ngovernor (and scheduler) behavior on touch. To avoid a slow ramp to a high clock\nfrequency (which could cause the device to drop frames on touch), touch boost\nusually sets a frequency floor on the CPU to ensure plenty of CPU capacity is\navailable on touch. A floor lasts for some amount of time after touch (usually\naround two seconds).\n\nPixel also uses the schedtune cgroup provided by Energy Aware Scheduling\n(EAS) as an additional touch boost signal: Top apps get additional\nweight via schedtune to ensure they get enough CPU capacity to run quickly. The\nNexus 5X and 6P have a much bigger performance gap between the little and big\nCPU clusters (A53 and A57, respectively) than the Pixel with the Kryo CPU. We\nfound that the little CPU cluster was not always adequate for smooth UI\nrendering, especially given other sources of jitter on the device.\n\nAccordingly, on the Nexus 5X and 6P, touch boost modifies the scheduler\nbehavior to make it more likely for foreground apps to move to the big\ncores (this is conceptually similar to the floor on CPU frequency). Without the\nscheduler change to make foreground apps more likely to move to the big\nCPU cluster, foreground apps may have insufficient CPU capacity to\nrender until the scheduler decided to load balance the thread to a big CPU core.\nBy changing the scheduler behavior during touch boost, it is more likely for a\nUI thread to immediately run on a big core and avoid jank while not forcing it\nto always run on a big core, which could have severe impacts on power\nconsumption.\n\nThermal throttling\n------------------\n\nThermal throttling occurs when the device must reduce its overall thermal\noutput, usually performed by reducing CPU, GPU, and DRAM clocks. Unsurprisingly,\nthis often results in jank as the system may no longer be able to provide enough\ncapacity to render within a given timeslice. The only way to avoid thermal\nthrottling is to use less power. There are not a lot of ways to do this, but\nbased on our experiences with past SOCs, we have a few recommendations for\nsystem vendors.\n\nFirst, when building a new SOC with heterogeneous CPU architectures, ensure\nthe performance/W curves of the CPU clusters overlap. The overall performance/W\ncurve for the entire processor should be a continuous line. Discontinuities in\nthe perf/W curve force the scheduler and frequency governor to guess what a\nworkload needs; to prevent jank, the scheduler and frequency governor err on\nthe side of giving the workload more capacity than it requires. This results in\nspending too much power, which contributes to thermal throttling.\n\nImagine a hypothetical SOC with two CPU clusters:\n\n- Cluster 1, the little cluster, can spend between 100-300mW and scores 100-300 in a throughput benchmark depending on clocks.\n- Cluster 2, the big cluster, can spend between 1000 and 1600mW and scores between 800 and 1200 in the same throughput benchmark depending on clocks.\n\nIn this benchmark, a higher score is faster. While not more desirable than\nslower, faster == greater power consumption.\n\nIf the scheduler believes a UI workload would require the equivalent of a\nscore of 310 on that throughput benchmark, its best option to avoid jank is to\nrun the big cluster at the lowest frequency, wasting significant power. (This\ndepends on cpuidle behavior and race to idle; SOCs with continuous perf/W curves\nare easier to optimize for.)\n\nSecond, use cpusets. Ensure you have enabled cpusets in your kernel and in\nyour `BoardConfig.mk`. You must also set up the actual cpuset\nassignments in your device-specific `init.rc`. Some vendors leave\nthis disabled in their BSPs in the hopes they can use other hints to influence\nscheduler behavior; we feel this doesn't make sense. cpusets are useful for\nensuring load balancing between CPUs is done in a way that reflects what the\nuser is actually doing on the device.\n\nActivityManager assigns apps to different cpusets based on the relative\nimportance of those apps (top, foreground, background), with more important\napps getting more access to CPU cores. This helps ensure quality of\nservice for foreground and top apps.\n\ncpusets are useful on homogeneous CPU configurations, but you should not ship\na device with a heterogeneous CPU configuration without cpusets enabled. Nexus\n6P is a good model for how to use cpusets on heterogeneous CPU configurations;\nuse that as a basis for your own device's configuration.\n\ncpusets also offer power advantages by ensuring background threads that are\nnot performance-critical never get load balanced to big CPU cores, where they\ncould spend significantly more power without any user-perceived benefit. This\ncan help to avoid thermal throttling as well. While thermal throttling is a\ncapacity issue, jitter improvements have an outsize impact on UI performance\nwhen thermal throttling. Because the system will be running closer to its\nability to render 60FPS, it takes less jitter to cause a dropped frame."]]
