使用 Simpleperf 評估裝置效能。Simpleperf 是原生剖析工具，適用於 Android 上的應用程式和原生程序。使用 CPU 分析器即時檢查應用程式的 CPU 使用情形和執行緒活動。
使用者可看到兩種效能指標：
- 可預測的效能，且使用者能明顯感受到。使用者介面是否會掉格，或一律以 60 FPS 算繪？音訊播放時是否沒有殘影或爆音？使用者觸控螢幕後，顯示器要過多久才會顯示效果？
- 較長作業所需的時間長度 (例如開啟應用程式)。
第一個比第二個更明顯。使用者通常會注意到卡頓，但除非並排比較兩部裝置，否則無法分辨 500 毫秒和 600 毫秒的應用程式啟動時間。觸控延遲時間會立即顯現，並大幅影響裝置的感知效能。
因此，在快速裝置中，除了維持 UI 管道運作所需的項目外，UI 管道是系統中最重要的一環。也就是說，UI 管道應優先處理流暢 UI 所需的任何其他工作。為維持流暢的 UI，如果可以執行 UI 工作，就必須延遲背景同步、通知傳送和類似工作。為了維持流暢的 UI，可以犧牲較長作業的效能 (例如 HDR+ 執行階段、應用程式啟動等)。
容量與延遲抖動
考量裝置效能時，容量和延遲是兩項有意義的指標。
容量
容量是指裝置在一段時間內擁有的某項資源總量。這可以是 CPU 資源、GPU 資源、I/O 資源、網路資源、記憶體頻寬或任何類似指標。檢查全系統效能時，抽象化個別元件並假設單一指標決定效能，可能很有用 (特別是在調整新裝置時，因為該裝置上執行的工作負載可能固定)。
系統容量會因線上運算資源而異。變更 CPU/GPU 頻率是變更容量的主要方式，但也有其他方式，例如變更上線的 CPU 核心數量。因此，系統容量與耗電量成正比；變更容量時，耗電量也會隨之變更。
特定時間所需容量絕大部分取決於執行的應用程式。因此，平台幾乎無法調整特定工作負載所需的容量，且只能透過執行階段改善 (Android 架構、ART、Bionic、GPU 編譯器/驅動程式、核心) 達成此目的。
時基誤差
雖然工作負載的必要容量一目瞭然，但延遲抖動的概念較為模糊。如要瞭解抖動如何阻礙快速系統，建議閱讀「The Case of the Missing Supercomputer Performance: Achieving Optimal Performance on the 8,192 processors of ASCI Q」一文。(這項調查旨在瞭解 ASCI Q 超級電腦為何未達到預期效能，並介紹如何最佳化大型系統。)
本頁面使用「抖動」一詞，說明 ASCI Q 紙張所謂的「雜訊」。抖動是隨機的系統行為，會導致可察覺的工作無法執行。這類工作通常必須執行，但可能沒有嚴格的時間規定，因此會在任何特定時間執行。由於抖動是隨機發生，因此很難證明特定工作負載不存在抖動。此外，也很難證明已知抖動來源是導致特定效能問題的原因。最常使用的抖動原因診斷工具 (例如追蹤或記錄) 可能會產生自己的抖動。
在 Android 實際導入作業中，可能導致抖動的來源包括：
- 排程器延遲
- 中斷處理常式
- 驅動程式程式碼執行時間過長，且停用先占或中斷
- 長時間執行的軟中斷
- 鎖定爭用 (應用程式、架構、核心驅動程式、繫結器鎖定、mmap 鎖定)
- 檔案描述元爭用，其中優先順序較低的執行緒會保留檔案的鎖定，導致優先順序較高的執行緒無法執行
- 在工作佇列中執行 UI 重要程式碼，可能會導致延遲
- CPU 閒置轉換
- 記錄
- I/O 延遲
- 建立不必要的程序 (例如
CONNECTIVITY_CHANGE廣播) - 可用記憶體不足導致網頁快取抖動
在特定時間範圍內，隨著容量增加，所需時間可能會減少，也可能不會。舉例來說，如果驅動程式在等待從 i2c 匯流排讀取資料時停用中斷，無論 CPU 是 384 MHz 或 2 GHz，都會花費固定時間。如果涉及延遲，增加容量並非改善效能的可行解決方案。因此，在受到延遲限制的情況下，更快的處理器通常不會提升效能。
最後，與容量不同的是，時基誤差幾乎完全屬於系統供應商的領域。
記憶體消耗量
傳統上，記憶體用量是造成效能不佳的原因。雖然耗用本身不是效能問題，但可能會透過 lowmemorykiller 負荷、服務重新啟動和網頁快取抖動，導致延遲。減少記憶體用量可避免效能不佳的直接原因，但可能還有其他目標改善措施也能避免這些原因 (例如固定架構，防止架構在不久後分頁時分頁)。
分析初始裝置效能
從功能正常但效能不佳的系統著手，並嘗試透過個別使用者可見的效能不佳案例修正系統行為，並非明智之舉。由於效能不佳通常不容易重現 (即抖動) 或應用程式問題，完整系統中的變數太多，因此這項策略無法有效發揮作用。因此，您很容易誤判原因，並在錯失系統性機會的情況下，僅做出微小的改善。
請改用下列一般方法啟動新裝置：
- 讓系統啟動至 UI，並執行所有驅動程式和一些基本頻率調控器設定 (如果變更頻率調控器設定，請重複執行下列所有步驟)。
- 請確保核心支援
sched_blocked_reason追蹤點，以及顯示管道中的其他追蹤點，這些追蹤點會標示影格傳送到螢幕的時間。 - 執行輕量且一致的工作負載 (例如 UiBench 或 TouchLatency 中的球體測試) 時，請擷取整個 UI 管道的長時間追蹤記錄 (從透過 IRQ 接收輸入內容到最終掃描輸出)。
- 修正輕量且一致的工作負載中偵測到的掉格問題。
- 重複步驟 3 到 4，直到可以連續執行 20 秒以上，且沒有任何影格遭到捨棄為止。
- 繼續處理其他使用者可見的卡頓來源。
在裝置啟動初期，您還可以執行下列簡單操作：
- 確認核心具有 sched_blocked_reason 追蹤點修補程式。這個追蹤點會在 systrace 中啟用 sched 追蹤類別，並提供負責在該執行緒進入不可中斷的休眠狀態時休眠的函式。因為不間斷的睡眠是抖動的常見指標，因此對成效分析至關重要。
- 確認 GPU 和顯示管道的追蹤記錄充足。在近期的 Qualcomm SOC 上，可使用下列指令啟用追蹤點：
adb shell "echo 1 > /d/tracing/events/kgsl/enable"adb shell "echo 1 > /d/tracing/events/mdss/enable"
執行 systrace 時，這些事件會保持啟用狀態，因此您可以在 mdss_fb0 區段中，查看追蹤記錄中顯示管道 (MDSS) 的額外資訊。在 Qualcomm SOC 上，標準 systrace 檢視畫面不會顯示任何 GPU 的額外資訊，但結果會出現在追蹤記錄本身 (詳情請參閱「瞭解 systrace」)。
您希望這類顯示追蹤功能提供單一事件，直接指出影格已傳送至螢幕。您可以在這裡判斷是否成功達到影格時間；如果事件 Xn 在事件 Xn-1 之後不到 16.7 毫秒發生 (假設螢幕更新率為 60 Hz)，則表示您沒有發生卡頓。如果 SOC 未提供這類信號，請與供應商合作取得信號。如果沒有明確的影格完成信號，就極難偵錯抖動問題。
使用合成基準
合成基準有助於確保裝置具備基本功能。不過，將基準視為裝置效能的替代指標並無意義。
根據 SOC 的經驗，SOC 之間合成基準測試效能的差異，與可察覺的 UI 效能 (捨棄的影格數、第 99 個百分位數的影格時間等) 差異並無關聯。合成基準僅為容量基準；延遲只會從基準的大量作業中竊取時間，進而影響這些基準的測量效能。因此，合成基準分數大多與使用者感受到的效能無關。
假設有兩個 SOC 執行 Benchmark X，轉譯 1000 個 UI 影格，並回報總轉譯時間 (分數越低越好)。
- SOC 1 會以 10 毫秒轉譯 Benchmark X 的每個影格，並獲得 10,000 分。
- SOC 2 會在 1 毫秒內顯示 99% 的影格，但 1% 的影格則需要 100 毫秒，因此得分為 19,900 分，大幅優於 SOC 1。
如果基準代表實際 UI 效能，SOC 2 就無法使用。假設刷新率為 60 Hz，SOC 2 每運作 1.5 秒就會出現影格延遲。同時，SOC 1 (根據 Benchmark X 較慢的 SOC) 會完全流暢。
使用錯誤報告
錯誤報告有時可用於效能分析，但由於報告內容過於龐大，因此很少能用於偵錯偶發的延遲問題。這些記錄可能會提供系統在特定時間執行的作業相關提示，特別是如果卡頓發生在應用程式轉換期間 (這會記錄在錯誤報告中)。錯誤報告也能指出系統何時發生更廣泛的問題，導致有效容量減少 (例如熱能管理機制或記憶體片段化)。
使用 TouchLatency
TouchLatency 是 Pixel 和 Pixel XL 偏好的週期性工作負載，其中有幾個不良行為的例子。這項工具位於 frameworks/base/tests/TouchLatency，提供兩種模式：觸控延遲和彈跳球 (如要切換模式，請按一下右上角的按鈕)。
彈跳球測試就如您所見，非常簡單：無論使用者輸入什麼內容，球都會在畫面上不斷彈跳。這通常也是最難完美執行的測試，但越接近無掉格執行，裝置效能就越好。彈跳球測試很困難，因為這是微不足道但完全一致的工作負載，以非常低的時脈執行 (這假設裝置有頻率調控器；如果裝置改用固定時脈執行，請在第一次執行彈跳球測試時，將 CPU/GPU 時脈調降至接近最低值)。隨著系統進入閒置狀態，時脈也逐漸降低，每個影格所需的 CPU/GPU 時間就會增加。您可以觀看球體，並查看物件是否抖動，也可以在系統追蹤記錄中查看錯過的影格。
由於工作負載非常一致，因此與大多數使用者可見的工作負載相比，您更容易找出大部分的抖動來源，方法是追蹤每個遺失影格期間系統上執行的確切項目，而不是 UI 管道。時脈越低，就越可能因任何抖動而導致影格遺失，進而放大抖動的影響。因此，TouchLatency 越接近 60 FPS，就越不可能發生導致大型應用程式中出現間歇性、難以重現的抖動問題的系統行為。
由於時脈速度通常 (但並非一律) 不會影響抖動，因此請使用以極低時脈執行的測試來診斷抖動，原因如下：
- 並非所有抖動都與時脈速度無關，許多來源只會耗用 CPU 時間。
- 調控器應會降低時脈，讓平均影格時間接近期限，因此執行非 UI 工作所花的時間可能會超過期限，導致影格遭到捨棄。