本指南說明如何使用 Android 動態效能架構 (ADPF)，根據 Android 上的動態熱溫、CPU 和 GPU 管理功能對遊戲進行最佳化調整。本文說明重點在於遊戲，但您也可以將這些功能用於其他耗用大量效能的應用程式。
ADPF 是一組 API，可讓遊戲和需要耗用大量效能執行的應用程式直接與 Android 裝置的電力和熱溫系統互動。這些 API 可讓您監控 Android 系統的動態行為，並且在不會使裝置過熱的永續等級最佳化遊戲效能。
相較於電腦和控制台，行動 SoC 和 Android 的動態效能行為更靈活。這些行為包括熱力狀態管理、不同的 CPU 與 GPU 時脈，以及不同的 CPU 核心類型，再加上日益多元的 SoC 核心拓撲，我們要在不影響裝置效能的情況下，致力確保遊戲能夠善用這類行為，這確實帶給我們相當多的挑戰。ADPF 提供了部分這類資訊，藉此提高效能的可預測性。
以下是 ADPF 的主要功能：
熱力狀態監控：監控裝置的熱力狀態，並且在無法維持永續等級前主動調整效能。
CPU 效能提示：提供效能提示，讓 Android 據以選擇正確的 CPU 時脈和核心類型，而非依據先前的工作負載選擇。
固定效能模式：在基準化期間為裝置啟用固定效能模式，以取得非由動態 CPU 時脈變更的測量數據。
熱力狀態監控
發布版本：Android 11 (API 級別 30)
所有裝置必須使用：Android 13 (API 級別 33) 以上版本
應用程式的潛在效能會受限於裝置的熱力狀態，這可能會因天氣、最近使用情況和裝置的熱力設計等特性而異。裝置只能暫時維持一定時段的高效能，之後就會為了防止過熱而進行節流。實作作業的一大目標，是要在不超出熱溫限制的情況下達成效能目標。此外，在針對效能問題進行偵錯時，知道裝置熱力狀態對效能產生限制的時間十分重要。
遊戲引擎通常會提供執行階段效能參數，可調整引擎加諸於裝置的工作負載。舉例來說，這些參數可以設定工作站執行緒數量、大型與小型核心的工作站執行緒相依性、GPU 擬真度選項，以及 framebuffer 解析度。
當裝置接近不安全的熱力狀態時，遊戲可以透過這些參數來減少工作負載，藉此避免發生過熱保護情形。如要避免發生過熱保護情形，您應監控裝置的熱力狀態，並主動調整遊戲引擎工作負載。裝置一旦過熱，工作負載就必須降低至永續效能等級以下才能散熱。
PowerManager
ADPF 提供 PowerManager 類別，用於監控裝置的熱力狀態。這個類別的主要元素如下：
如果裝置未處於過熱保護狀態：
已有小幅度的過熱保護情形，但對效能沒有太大影響：
發生會影響效能的大幅度過熱保護情形：
Thermal API (NDK) 的原生繫結：
您可以藉由輪詢 getThermalHeadroom 方法來監控裝置的熱力狀態。這個方法可判斷裝置在不過熱的情況下，可維持目前效能等級的時間長度。如果這段時間比執行工作負載所需時間還短，則遊戲應將工作負載降低至永續等級。舉例來說，遊戲可以改用小型核心、降低影格速率或擬真度。
CPU 效能提示
發布版本：Android 12 (API 級別 31)
所有裝置必須使用：尚非必要
透過 CPU 效能提示，遊戲可以影響動態 CPU 效能行為，而不會讓裝置過熱和浪費電力。在大多數裝置上，Android 會依據先前的需求，以動態方式調整工作負載的 CPU 時脈速度和核心類型。如果工作負載使用更多 CPU 資源，時脈速度就會提高，且工作負載最終會移至大型核心。如果工作負載使用的資源較少，則 Android 會減少資源分配。
時脈速度
當 Android 裝置動態調整 CPU 時脈速度時，頻率可能會變更程式碼的效能影響。設計可處理動態時脈速度的程式碼，對於盡可能提高效能、維護安全的熱力狀態以及有效使用電力至關重要。您可透過以最高時脈速度執行遊戲暫時降低資源浪費及提高回應速度，但同時會浪費電力，最終導致時脈發生過熱保護情形。CPU 或 GPU 時脈在溫度調節期間的效能會低於永續等級。
您無法在應用程式程式碼中直接指定 CPU 頻率。因此，如果應用程式要嘗試以較高的 CPU 時脈速度執行，常見的方法就是在背景執行緒中執行忙碌迴圈，讓工作負載看似需要更多的資源。這麼做會浪費電力，並在應用程式未耗用額外資源時增加裝置的熱能負載。
核心類型
執行遊戲的 CPU 核心類型是另一項重要效能因素。Android 裝置通常會依據近期的工作負載行為，動態變更指派給執行緒的 CPU 核心。CPU 核心指派作業在含有多種核心類型的 SoC 上更為複雜。在部分這類裝置上，系統可能只會短暫使用大型核心，以避免進入因過熱而無法維持永續等級的狀態。
您不應該嘗試對遊戲設定 CPU 核心相依性，原因如下：
特定工作負載的最佳核心類型會因裝置型號而異。
執行大型核心的永續做法會因 SoC 和每個裝置型號提供的各種熱能解決方案而異。
環境對熱力狀態的影響可能會使核心選擇更加複雜。舉例來說，天氣或手機保護殼可能會改變裝置的熱力狀態。
核心選擇無法因應具備額外效能和溫度調整功能的新裝置。因此，裝置通常會忽略遊戲的處理器相依性。
PeformanceHintManager
ADPF 提供 PerformanceHintManager 類別，讓遊戲可以向 Android 提供 CPU 時脈速度和核心類型的效能提示。這樣一來，OS 就可以根據裝置的 SoC 和熱能解決方案，決定如何以最佳方式因應這項提示。如果應用程式搭配熱力狀態監控使用這個 API，就能為 OS 提供更多資訊提示，而不必使用可能引發過熱保護的忙碌迴圈和其他程式設計技巧。
以下說明遊戲使用效能提示的方式：
為行為相似的主要執行緒建立提示工作階段。例如：
- 為轉譯執行緒取得一個工作階段
- 為 IO 執行緒取得另一個工作階段
- 為音訊執行緒取得第三個工作階段
遊戲應在工作階段需要增加系統資源至少 2 毫秒，且最好超過 4 毫秒之前，及早執行這項作業。
在每個提示工作階段中，預測每個工作階段執行所需的時間。這個時間長度一般相當於影格間隔，但如果工作負載沒有明顯的跨影格差異，應用程式可使用較短的間隔。
固定效能模式
發布版本：Android 11 (API 級別 30)
所有裝置必須使用：尚非必要
Android 裝置可以根據系統負載動態變更時脈。在使用裝置時，這個行為有助於節省電力，但也可能導致難以取得可靠的效能資料。如果要嘗試判斷程式碼片段在防止迴歸時可執行的最快速度，或者可以重複執行最佳化作業，則不是在固定時脈速度下進行測試的結果就不一定可靠。使用固定時脈時，您可以準確執行效能的 A/B 測試，而不會受到 CPU 頻率變更的因素影響。
固定效能模式會設定 CPU 和 GPU 時脈的上限和下限。這個模式不會停用其他動態效能行為，例如核心選擇。
您可以使用下列 adb 指令啟用固定效能模式：
adb shell cmd power set-fixed-performance-mode-enabled [true|false]
在固定效能模式下運作的裝置仍可能發生過熱情形，因為該模式不會讓裝置進入熱力永續狀態。因此，我們為基準執行作業提供下列建議：
等待裝置返回熱力永續狀態，再開始執行。
在測試期間監控裝置的熱力狀態，以區分基準程式碼和過熱事件產生的影響。
範例應用程式
ADPF 範例應用程式會示範 ADPF API 的基本用法。這個範例使用 ADPF getThermalHeadroom API 和熱力狀態 API 顯示裝置的熱力狀態。應用程式也會根據 API 的提示和 PerformanceHintManager API，以動態方式變更工作負載，藉此控制轉譯執行緒的效能。