評估成效

使用 Simpleperf 評估裝置的效能。Simpleperf 是 Android 應用程式和原生程序的原生剖析工具。使用 CPU 分析器即時檢查應用程式的 CPU 使用情形和執行緒活動。

有兩個使用者可見的效能指標：

  • 可預測且可察覺的效能。使用者介面 (UI) 是否會掉格，或是否能以 60 FPS 的速度持續算繪？音訊播放時是否沒有雜訊或爆音？使用者輕觸螢幕到效果顯示在螢幕上之間的延遲時間為何？
  • 長時間作業所需的時間長度 (例如開啟應用程式)。

第一項比第二項更明顯。使用者通常會注意到卡頓情形，但除非並排比較兩部裝置，否則無法分辨 500 毫秒與 600 毫秒的應用程式啟動時間。觸控延遲時間會立即顯現，並對使用者對裝置的感受造成重大影響。

因此，在速度快的裝置中，除了維持 UI 管道運作所需的功能外，UI 管道是系統中最重要的部分。這表示 UI 管道應搶先處理任何不必要的作業，以便提供流暢的 UI。為維持流暢的 UI，如果可以執行 UI 工作，則必須延遲背景同步處理、通知傳送和類似工作。為了維持流暢的使用者介面，可以犧牲較長作業 (HDR+ 執行時間、應用程式啟動等) 的效能。

容量與抖動

在考量裝置效能時，容量和抖動是兩個有意義的指標。

容量

容量是指裝置在一段時間內擁有的某些資源總量。這可以是 CPU 資源、GPU 資源、I/O 資源、網路資源、記憶體頻寬或任何類似指標。在檢查整個系統效能時，抽象化個別元件並假設單一指標可決定效能，可能會很有幫助 (尤其是在調整新裝置時，因為在該裝置上執行的工作負載可能會固定)。

系統的容量會因線上運算資源而異。變更 CPU/GPU 頻率是變更容量的主要方式，但還有其他方式，例如變更線上 CPU 核心數量。因此，系統的容量會對應到電力消耗量；變更容量一律會導致電力消耗量出現類似變化。

在特定時間點所需的容量，大多由執行中的應用程式決定。因此，平台只能稍微調整特定工作負載所需的容量，而且只能透過執行階段改善方式 (Android 架構、ART、Bionic、GPU 編譯器/驅動程式、核心) 調整容量。

時基誤差

雖然工作負載所需的容量很容易看出，但 jitter 則是較模糊的概念。如要深入瞭解抖動對快速系統的影響，建議您閱讀「The Case of the Missing Supercomputer Performance: Achieving Optimal Performance on the 8,192 processors of ASCI Q」。(這是一項調查，探討 ASCI Q 超級電腦未達到預期效能的緣由，也是最佳化大型系統的絕佳入門指南)。

本頁面使用「抖動」一詞來描述 ASCI Q 論文中所稱的「雜訊」。抖動是隨機系統行為，會導致可感知的工作無法執行。這類工作通常是必須執行的工作，但可能沒有嚴格的時間限制，因此不會在任何特定時間執行。由於 jitter 是隨機發生，因此很難證明特定工作負載沒有 jitter。而且，要證明特定抖動來源是特定效能問題的原因也非常困難。最常用於診斷抖動原因的工具 (例如追蹤或記錄) 可能會產生抖動。

在實際實作 Android 時，造成抖動的來源包括：

  • 排程器延遲
  • 中斷處理常式
  • 在先占或中斷功能停用的情況下，驅動程式碼執行時間過長
  • 長時間執行的軟中斷
  • 鎖定爭用 (應用程式、架構、核心驅動程式、Binder 鎖定、mmap 鎖定)
  • 檔案描述元爭用情形，其中低優先順序執行緒會保留檔案的鎖定，導致高優先順序執行緒無法運作
  • 在可能延遲的 workqueue 中執行 UI 重要程式碼
  • CPU 閒置轉換
  • 記錄
  • I/O 延遲
  • 不必要的程序建立作業 (例如 CONNECTIVITY_CHANGE 廣播)
  • 由於可用記憶體不足，導致分頁快取發生衝突

在特定抖動期間，所需的時間可能會隨著容量增加而減少，也可能不會減少。舉例來說，如果驅動程式在等待透過 i2c 匯流排讀取資料時，將中斷功能停用，則無論 CPU 頻率是 384 MHz 還是 2 GHz，都會耗費固定時間。在 jitter 發生時，增加容量並非改善效能的可行解決方案。因此，在抖動受限的情況下，較快的處理器通常不會改善效能。

最後，與容量不同，時基誤差幾乎完全在系統供應商的領域內。

記憶體用量

記憶體用量通常是造成效能不佳的罪魁禍首。雖然耗用量本身並非效能問題，但可能會透過低記憶體殺手額外負擔、服務重新啟動和頁面快取耗盡造成抖動。減少記憶體用量可避免效能不佳的直接原因，但也可能有其他有針對性的改善方式可避免這些原因 (例如將架構釘選，以免在即將被頁面化時，該架構無法被頁面化)。

分析初始裝置效能

從功能正常但效能不佳的系統著手，並嘗試透過查看使用者可見的個別效能不佳情況，修正系統行為，這不是可行策略。由於效能不佳的情況通常不容易重現 (也就是抖動)，或許是應用程式問題，因此整個系統中變數太多，導致這項策略無法發揮效用。因此，很容易誤判原因並進行小幅改善，卻錯失了改善整個系統效能的系統性機會。

請改為在啟動新裝置時使用下列一般方法：

  1. 讓系統啟動至 UI，並執行所有驅動程式和一些基本頻率節流器設定 (如果變更頻率節流器設定，請重複執行下列所有步驟)。
  2. 請確認核心支援 sched_blocked_reason 追蹤點，以及顯示管線中的其他追蹤點，這些追蹤點會標示影格傳送至顯示器的時間。
  3. 在執行輕量且一致的工作負載 (例如 UiBench 或 TouchLatency 中的球測試) 時，取得整個 UI 管道的長追蹤記錄 (從透過 IRQ 接收輸入內容到最終掃描)。
  4. 修正輕量且一致的工作負載中偵測到的影格掉落問題。
  5. 重複執行步驟 3 和 4，直到每次執行時，影格遺失率為零，且持續 20 秒以上。
  6. 接著找出其他導致使用者感知的 jank 來源。

在裝置啟動初期，您還可以執行其他簡單的操作，包括：

  • 請確認核心具有 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 百分位數影格時間等) 的類似差異無關。合成基準是僅限容量的基準，抖動只會影響這些基準的測量效能，因為它會從基準的大量作業中竊取時間。因此，合成基準分數大多與使用者感知的效能無關。

請考慮執行基準測試 X 的兩個 SOC，該測試會轉譯 1000 個 UI 影格，並回報總轉譯時間 (分數越低越好)。

  • SOC 1 可在 10 毫秒內轉譯基準測試 X 的每個影格，並獲得 10,000 分。
  • SOC 2 在 1 毫秒內算繪 99% 的影格，但在 100 毫秒內算繪 1% 的影格，分數為 19,900，分數大幅提升。

如果基準測試代表實際的 UI 效能，SOC 2 就無法使用。假設刷新率為 60 Hz，SOC 2 每 1.5 秒的運作時間就會出現卡頓影格。同時，SOC 1 (根據基準 X 的速度較慢) 會流暢運作。

使用錯誤報告

錯誤報告有時可用於效能分析，但由於報告內容過於龐大，因此很少用於偵測不規則的卡頓問題。這些資訊可能會提供系統在特定時間的運作情形，尤其是當應用程式轉換 (已記錄在錯誤報告中) 導致卡頓時。錯誤報告也可以指出系統發生較廣泛的錯誤，導致有效容量降低 (例如熱能限制或記憶體碎裂)。

使用 TouchLatency

幾個不良行為的例子來自 TouchLatency，這是 Pixel 和 Pixel XL 偏好的週期性工作負載。這項功能可在 frameworks/base/tests/TouchLatency 中使用，並提供兩種模式：觸控延遲和彈跳球 (如要切換模式，請按一下右上角的按鈕)。

彈跳球測試的操作方式就如其名稱所示：無論使用者輸入什麼內容，球都會在螢幕上彈跳。這通常也是最難執行完美測試的測試，但如果裝置能越接近不遺漏任何影格，就越好。彈跳球測試很難執行，因為它是一種簡單但完全一致的工作負載，以非常低的時脈執行 (這假設裝置具有頻率節流器；如果裝置以固定時脈執行，請在第一次執行彈跳球測試時，將 CPU/GPU 降時脈至接近最低值)。隨著系統進入休眠狀態，時脈會降至接近閒置狀態，每個影格所需的 CPU/GPU 時間也會增加。您可以觀看球，並查看畫面中是否有異常情形，也可以在 systrace 中查看遺漏的畫面。

由於工作負載非常一致，您可以追蹤在每個遺漏影格期間系統上執行的確切項目，而非 UI 管道，因此比起在大多數使用者可見的工作負載中，更容易找出大多數抖動的來源。較低的時脈會放大抖動效應，因為任何抖動都更有可能導致影格遺失。因此，TouchLatency 越接近 60 FPS，越不容易出現導致大型應用程式出現不規則、難以重現的卡頓情形的系統異常行為。

由於抖動通常 (但不一定) 是時脈速度不變的，請使用以極低時脈運行的測試，藉此診斷抖動的原因：

  • 並非所有抖動都與時脈速度無關；許多來源只會消耗 CPU 時間。
  • 節流器應透過計時來讓平均影格時間接近截止時間，這樣執行非 UI 工作所需的時間就能將其推到邊緣，以便捨棄影格。