評估績效

使用Simpleperf評估設備的效能。 Simpleperf 是適用於 Android 上的應用程式和本機進程的本機分析工具。使用CPU Profiler即時檢查應用程式 CPU 使用情況和執行緒活動。

有兩個用戶可見的效能指標:

  • 可預測、可感知的性能。使用者介面 (UI) 是否丟幀或始終以 60FPS 渲染?音訊播放時是否沒有雜音或爆音?使用者觸控螢幕和顯示器上顯示效果之間的延遲有多長?
  • 較長操作(例如開啟應用程式)所需的時間長度

第一個比第二個更引人注目。使用者通常會注意到卡頓,但他們無法區分應用程式啟動時間是 500 毫秒還是 600 毫秒,除非他們並排查看兩個裝置。觸摸延遲非常明顯,並且對設備的感知有很大影響。

因此,在快速設備中,除了保持 UI 管道正常運作所需的內容之外,UI 管道是系統中最重要的事情。這意味著 UI 管道應該搶佔流暢 UI 不必要的任何其他工作。為了保持流暢的 UI,如果可以執行 UI 工作,則必須延遲後台同步、通知傳遞和類似的工作。為了保持流暢的 UI,犧牲較長操作(HDR+ 運行時間、應用程式啟動等)的效能是可以接受的。

容量與抖動

在考慮設備性能時,容量抖動是兩個有意義的指標。

容量

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

系統的容量會根據線上計算資源的不同而變化。更改CPU/GPU頻率是更改容量的主要手段,但還有其他方式,例如在線更改CPU核心數。因此,系統的容量與功耗相對應;改變容量總是會導致類似的功耗變化。

給定時間所需的容量很大程度上取決於正在運行的應用程式。因此,該平台幾乎無法調整給定工作負載所需的容量,且這樣做的方法僅限於運行時改進(Android 框架、ART、Bionic、GPU 編譯器/驅動程式、核心)。

抖動

雖然工作負載所需的容量很容易看出,但抖動是一個更模糊的概念。有關抖動作為快速系統障礙的詳細介紹,請參閱超級電腦效能缺失的案例:在 ASCl Q 的 8,192 個處理器上達到最佳效能。 (這是對 ASCI Q 超級電腦為何沒有達到預期效能的調查,也是對大型系統最佳化的一個很好的介紹。)

本頁使用術語「抖動」來描述 ASCI Q 論文中所說的「噪音」 。抖動是一種隨機系統行為,會阻止可感知的工作運作。它通常是必須運行的工作,但它可能沒有嚴格的時間要求導致它在任何特定時間運行。因為它是隨機的,所以要反駁給定工作負載的抖動的存在是極其困難的。證明已知的抖動源是特定效能問題的原因也是極為困難的。最常用於診斷抖動原因的工具(例如追蹤或日誌記錄)可能會引入自己的抖動。

Android 實際實作中遇到的抖動來源包括:

  • 調度程序延遲
  • 中斷處理程序
  • 驅動程式程式碼運行時間過長且禁用搶佔或中斷
  • 長時間運作的軟中斷
  • 鎖爭用(應用程式、框架、核心驅動程式、binder 鎖、mmap 鎖)
  • 檔案描述符爭用,低優先權執行緒持有檔案鎖,從而阻止高優先權執行緒運行
  • 在可能會延遲的工作佇列中執行 UI 關鍵程式碼
  • CPU 閒置轉換
  • 記錄
  • I/O 延遲
  • 不必要的進程創建(例如,CONNECTIVITY_CHANGE 廣播)
  • 可用記憶體不足導致頁面快取抖動

給定抖動週期所需的時間量可能會也可能不會隨著容量的增加而減少。例如,如果驅動程式在等待 i2c 總線上的讀取時停用中斷,則無論 CPU 的頻率是 384MHz 還是 2GHz,都將花費固定的時間。當涉及抖動時,增加容量並不是提高效能的可行解決方案。因此,更快的處理器通常不會提高抖動受限情況下的效能。

最後,與容量不同,抖動幾乎完全在系統供應商的範圍內。

記憶體消耗

傳統上,記憶體消耗被認為是效能不佳的原因。雖然消耗本身不是效能問題,但它可能會透過低記憶體殺手開銷、服務重新啟動和頁面快取抖動而導致抖動。減少記憶體消耗可以避免導致效能不佳的直接原因,但可能還有其他有針對性的改進可以避免這些原因(例如,固定框架以防止其在不久後被調入時被調出)。

分析初始設備性能

從功能正常但效能不佳的系統開始,並嘗試透過查看使用者可見的效能不佳的個別案例來修復系統的行為,這並不是一個明智的策略。由於較差的效能通常不易重現(即抖動)或應用程式問題,因此整個系統中的太多變數會阻止該策略發揮作用。因此,很容易錯誤地識別原因並進行微小的改進,同時錯過修復整個系統效能的系統機會。

相反,在啟動新設備時請使用以下通用方法:

  1. 讓系統啟動到 UI,並運行所有驅動程式和一些基本頻率調節器設定(如果更改頻率調節器設置,請重複以下所有步驟)。
  2. 確保核心支援sched_blocked_reason追蹤點以及顯示管道中表示幀何時傳送到顯示器的其他追蹤點。
  3. 在執行輕量級且一致的工作負載(例如UiBenchTouchLatency 中的球測試)時,對整個 UI 管道(從透過 IRQ 接收輸入到最終掃描輸出)進行長時間追蹤。
  4. 修復在輕量級且一致的工作負載中偵測到的丟幀問題。
  5. 重複步驟 3-4,直到您可以一次零丟幀運行 20 秒以上。
  6. 繼續討論其他使用者可見的卡頓來源。

您可以在設備啟動初期執行的其他簡單操作包括:

  • 確保您的核心具有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 )。

    您希望從這種顯示追蹤中得到一個直接指示幀已傳送到顯示器的單一事件。從那裡,您可以確定是否成功達到了幀時間;如果事件 X n在事件 X n-1之後發生不到 16.7 毫秒(假設顯示器為 60Hz),那麼您就知道沒有卡頓。如果您的 SOC 不提供此類訊號,請與您的供應商合作以取得它們。如果沒有明確的幀完成訊號,調試抖動是極其困難的。

使用綜合基準

綜合基準對於確保設備的基本功能存在非常有用。然而,將基準視為感知設備性能的代理是沒有用的。

根據 SOC 的經驗,SOC 之間的綜合基準性能差異與可感知的 UI 性能(丟幀數、第 99 個百分位幀時間等)的類似差異並不相關。綜合基準僅是容量基準;抖動僅透過從基準的批次操作中竊取時間來影響這些基準的測量效能。因此,綜合基準分數作為使用者感知效能的指標基本上是無關緊要的。

考慮兩個運行 Benchmark X 的 SOC,渲染 1000 幀 UI 並報告總渲染時間(分數越低越好)。

  • SOC 1 在 10 毫秒內渲染 Benchmark X 的每一幀,得分為 10,000。
  • SOC 2 在 1 毫秒內渲染 99% 的幀,在 100 毫秒內渲染 1% 的幀,得分為 19,900,得分明顯提高。

如果基準測試顯示實際 UI 效能,則 SOC 2 將無法使用。假設刷新率為 60Hz,SOC 2 每運轉 1.5 秒就會出現一個卡頓幀。同時,SOC 1(根據 Benchmark X 的較慢 SOC)將是完全流暢的。

使用錯誤報告

錯誤報告有時對於效能分析很有用,但由於它們非常重量級,因此對於調試偶發的卡頓問題很少有用。它們可能會提供一些有關係統在給定時間正在執行的操作的提示,特別是當卡頓發生在應用程式轉換(記錄在錯誤報告中)時。錯誤報告還可以顯示系統何時出現更廣泛的錯誤,這可能會降低其有效容量(例如熱節流或記憶體碎片)。

使用觸控延遲

不良行為的幾個例子來自 TouchLatency,這是 Pixel 和 Pixel XL 使用的首選週期性工作負載。它位於frameworks/base/tests/TouchLatency中,有兩種​​模式:觸摸延遲和彈跳球(要切換模式,請點擊右上角的按鈕)。

彈跳球測試就像看起來一樣簡單:無論使用者輸入如何,球都會永遠在螢幕上彈跳。這通常也是迄今為止最難完美運行的測試,但越接近沒有任何丟幀的情況下運行,您的設備就越好。彈跳球測試很困難,因為它是一個微不足道但完全一致的工作負載,以非常低的時鐘運行(這假設設備具有調頻器;如果設備以固定時鐘運行,請將CPU/GPU 降頻到接近最低值)第一次執行彈跳球測試時)。隨著系統靜止且時脈接近空閒,每個畫面所需的 CPU/GPU 時間會增加。您可以觀看球並看到卡頓的情況,並且您還可以在 systrace 中看到丟失的幀。

由於工作負載非常一致,因此您可以透過追蹤每個遺失幀期間系統上到底運行的內容(而不是 UI 管道)來比大多數使用者可見的工作負載更輕鬆地識別大多數抖​​動來源。較低的時鐘會放大抖動的影響,因為任何抖動都更有可能導致丟幀。因此,TouchLatency 越接近 60FPS,出現不良系統行為的可能性就越小,導致大型應用程式中出現零星的、難以重現的卡頓。

由於抖動通常(但並非總是)與時脈速度無關,因此請使用在非常低的時脈下執行的測試來診斷抖動,原因如下:

  • 並非所有抖動都是時脈不變的;許多來源只消耗 CPU 時間。
  • 調控器應該透過降低時脈頻率來使平均幀時間接近截止時間,因此運行非 UI 工作所花費的時間可能會將其推向丟幀的邊緣。