評估成效

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

成效有兩種指標可供使用者查看：

  • 可預測且可察覺的效能。使用者是否 介面 (UI) 捨棄影格或持續以 60 FPS 顯示？音訊是否會播放 偵測系統是否遭到阻斷或填充使用者觸碰前的延遲時間 以及螢幕上顯示的效果？
  • 長時間作業所需的時間長度 (例如 開啟應用程式)。

第一個圖片比第二行容易注意到。使用者通常會注意到資源浪費情形 但無法得知應用程式啟動時間是 500 毫秒 (相較於 600 毫秒) 他們看著兩部裝置。立即發生觸控延遲 明顯影響裝置的觀感。

因此，在速度飛快的裝置上，UI 管道是 讓系統保持 UI 管道正常運作所需的一切。這個 這表示 UI 管道應先佔任何其他不必要的工作 快速調整 UI為維持流暢的 UI、背景同步、通知傳送、 如果可以執行 UI 工作，則所有類似作業都必須延遲。是 以便換取長時間執行 (HDR+ 執行階段、 應用程式啟動等) 操作，以便維持流暢的 UI。

容量與時基誤差

考量裝置效能、容量和時基誤差 是兩個有意義的指標

容量

容量是指裝置擁有的某些資源總量 一些時間。可以是 CPU 資源、GPU 資源、I/O 資源 網路資源、記憶體頻寬或任何類似指標檢查時 整體系統效能，可將個別元件 並假設只有一個指標會影響成效 (尤其是在調整 因為在該裝置上執行的工作負載可能已修復)。

系統的容量會因線上的運算資源而異。 變更 CPU/GPU 頻率是變更容量的主要方式 例如變更線上 CPU 核心數量因此， 系統容量與耗電量；變更中 ，耗電量隨時都會有類似的變化。

在特定時間內所需的容量 過度由低音管判斷 執行中的應用程式因此，這個平台可以稍微調整 特定工作負載所需的容量 而且建立機制也受限於 執行階段改善項目 (Android 架構、ART、Bionic、GPU 編譯器/驅動程式， 核心)。

時基誤差

雖然工作負載所需的容量相當易於查看，但抖動器較能清楚顯示 雜亂的概念這份簡介有助於你順利介紹抖動功能，但對於快速 類神經網路 缺少成功要素的案例：全力追求最佳成效 8,192 屆 ASCl 會議課程，(我們對 ASCI 的 Q 超級電腦未能達到預期效能，因此能 概略介紹最佳化大型系統)。

本頁以「抖動」一詞說明 ASCI Q 論文呼叫的內容。 雜訊。時基誤差是無法察覺的隨機系統行為 執行訓練通常必須執行的工作，但可能不會嚴格 以及導致實驗在任何特定時間執行的時間要求。因為 因此很難看出時基誤差的存在 工作負載要證明自己已知的來源 時基誤差造成某個效能問題。最常見的工具 用於診斷時基誤差的原因 (例如追蹤或記錄) 可能會引發 他們的動態抖動

在 Android 實際實作中經歷的抖動來源 包括：

  • 排程器延遲
  • 中斷處理常式
  • 在先佔或中斷的情況下，驅動程式程式碼的執行時間過長
  • 長時間執行軟質
  • 鎖定爭用 (應用程式、架構、核心驅動程式、繫結器鎖定、mmap 鎖定)
  • 低優先順序執行緒保留鎖定在 檔案，防止高優先順序的執行緒執行
  • 在可能會延遲的工作佇列中執行重要的 UI 程式碼
  • CPU 閒置轉場效果
  • 記錄
  • I/O 延遲
  • 建立不必要的程序，例如 CONNECTIVITY_CHANGE 廣播
  • 因可用記憶體不足導致網頁快取遭到輾轉

一段時基誤差所需的時間長度，不一定 且會隨著容量增加而減少舉例來說，如果駕駛人退出通話 因為在等待 i2c 匯流排讀取時停用時，它就能解決 也就是說，無論 CPU 速度為 384 MHz 或 2 GHz。增加 在時抖動時，容量並非改善效能的解決方案 相關知識因此，加速處理器通常不會改善 效能。

最後，與容量不同 系統供應商

記憶體消耗量

傳統上，記憶體消耗量會導致效能不佳。雖然 但使用量本身不是效能問題，但都不構成影響 Lowmemorykiller 負荷、服務重新啟動和頁面快取輾轉。下降 避免造成效能不佳的直接原因 可以是其他目標改善措施，同時避開這些原因 (例如 固定架構，以免架構在分頁時遭到分頁 。

分析初始裝置效能

從功能正常但效能不佳的系統著手，嘗試修正問題 藉由檢視使用者可見性的個別情況，瞭解系統行為 表演不是有效的策略。因為成效不佳 通常無法重現 (也就是抖動) 或應用程式問題 整個系統中許多變數都讓這項策略無法發揮作用。阿斯 因此很容易辨識原因 缺少修正整個系統效能的系統性機會。

啟動全新廣告活動時，請採用以下一般做法 裝置：

  1. 在執行所有驅動程式及一些基本操作的情況下，讓系統啟動至 UI 展示頻率管理設定 (如果您變更展示頻率管理設定 重複執行下方所有步驟)。
  2. 確保核心支援 sched_blocked_reason 追蹤點 以及顯示管道中其他代表影格 會傳送到螢幕上
  3. 擷取整個 UI 管道的長時間追蹤記錄 (透過 IRQ 接收輸入內容) 到最後掃描)，同時執行輕量且一致的工作負載 (例如 UiBench 或在 TouchLatency) 進行球測試。
  4. 修正在輕量且一致情況下偵測到的影格遺失問題 工作負載。
  5. 重複執行步驟 3 到 4，直到 20 秒以上的影格都沒有捨棄任何影格為止。 逐步完成任務。
  6. 繼續前往其他使用者可見的卡頓來源。

裝置啟動後，您也可以進行以下其他簡單操作：

  • 確認核心具有 sched_blocked_reason 追蹤記錄點修補程式。這個追蹤點已啟用排程追蹤記錄類別 所提供的功能，並提供在 執行緒進入不可中斷的休眠狀態。成效分析至關重要 因為無法中斷的睡眠是很常見的時基誤差指標。
  • 確保您對 GPU 和顯示管道有足夠的追蹤記錄。啟用 近期的 Qualcomm SOC，使用以下方式啟用追蹤點：
    • adb shell "echo 1 > /d/tracing/events/kgsl/enable"
adb shell "echo 1 > /d/tracing/events/mdss/enable"

    執行 systrace 時，這些事件會維持啟用狀態，方便查看 安裝管道 (MDSS) 的追蹤記錄中， 「mdss_fb0」專區。在 Qualcomm SOC 中，系統不會在 標準 systrace 檢視畫面中的 GPU 相關資訊，但結果會 都出現在追蹤記錄中 (詳情請參閱 瞭解 systrace)。

    您希望透過這類顯示追蹤達成單一事件 表示影格已傳送至螢幕。接下來 來判斷是否已達到影格時間如果事件 Xn 在事件 Xn-1 (假設使用 60 Hz 螢幕) 後發生不到 16.7 毫秒， 你知道你沒有卡頓了如果您的 SOC 沒有提供這類訊號，請努力 以取得對方如果沒有 影格完成的確切信號

使用綜合基準

綜合基準測試有助於確保裝置的基本功能 。但將基準視為感知裝置的代理 沒有用處。

根據 SOC 的經驗，合成基準的差異 SOC 之間的績效與 正常的 UI 效能 (捨棄的影格數，第 99 個百分位數的影格) 時間等)。綜合基準是純容量的基準。時基誤差 這些基準的測量效能，但僅從大量 基準測試的執行因此，合成基準分數主要會 這並不是使用者感知效能指標。

假設有兩個執行基準測試 X 的 SOC，兩個影格轉譯了 1000 個 UI 影格 表示轉譯時間總計 (分數越低越好)。

  • SOC 1 在 10 毫秒內轉譯基準 X 的每個影格，分數為 10,000。
  • SOC 2 在 1 毫秒內顯示 99% 的影格，但 1% 的影格在 100 毫秒內，且分數為 1% 19,900 分，成績更勝以往。

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

使用錯誤報告

錯誤報告有時也很實用，有助於分析成效，但因為 但因為資料較重，幾乎不適合用來偵錯偶爾卡頓的問題。 他們可能會提供一些提示，指出系統在特定時間執行的操作 尤其是卡頓是應用程式轉換 (透過 錯誤報告)。錯誤報告也能指出項目範圍較廣的 系統故障時 (例如熱力) 節流或記憶體分割)。

使用 Touch Latency

TouchLatency 提供了幾個不良行為的例子， 優先用於 Pixel 和 Pixel XL 的定期工作負載。服務網址： frameworks/base/tests/TouchLatency，並且提供兩種模式：觸控延遲 和彈跳球 (如要切換模式，請點選右上角的按鈕) 角落)。

彈跳的球考試就像看起來一樣簡單：一顆球彈 就會永久停留在畫面上一般來說， 到目前為止，最困難的測試能完美執行，但越接近結果 當一個執行緒完全停止執行時，裝置的效能會更好。 彈跳球考試很小，但完全一致 極低時執行的工作負載 (假設裝置設有頻率) 州長；如果裝置是透過固定時鐘執行，請 首次執行彈跳球測試時， CPU/GPU 最低至最低值)。 隨著系統逐漸停止，而時鐘越來越接近閒置狀態，所需 CPU/GPU 每影格時間就會增加可以看到球球並發現卡頓情形 也會顯示在 Systrace 中遺漏的影格

由於工作負載相當一致 比起大多數使用者可見的工作負載， 而是在每個未偵測到的影格期間 (而非使用者介面) 於系統上執行 這種模型通常已開放原始碼 可以透過自訂筆記本或管線微調較低的時鐘可以放大抖動的影響 因此發生抖動問題的機率會隨之下降因此， TouchLatency 縮短了 60 FPS，系統越不容易出錯 造成大規模、難以重現卡頓的行為 應用程式。

由於時基誤差通常 (但不一定) 與時俱進，因此請使用測試 會在極低時運行，以便診斷時基誤差，原因如下：

  • 並非所有時基誤差都與時脈速度無關；許多來源只會耗用 CPU 讓應用程式從可以最快做出回應的位置 回應使用者要求
  • 州長應在接近期限前取得平均影格時間 所以花費時間執行非 UI 工作 會將時間推向邊緣 因此不會有捨棄畫面