使用Simpleperf評估設備的性能。 Simpleperf 是適用於 Android 上的應用程序和本機進程的本機分析工具。使用CPU Profiler實時檢查應用程序 CPU 使用率和線程活動。
有兩個用戶可見的性能指標：
- 可預測、可感知的性能。用戶界面 (UI) 是否會丟幀或始終以 60FPS 的速度呈現？音頻播放時沒有偽影或爆音嗎？用戶觸摸屏幕和顯示效果之間的延遲是多長時間？
- 較長操作（例如打開應用程序）所需的時間長度。
第一個比第二個更明顯。用戶通常會注意到卡頓，但他們無法分辨 500 毫秒和 600 毫秒的應用程序啟動時間，除非他們並排查看兩個設備。觸摸延遲會立即引起注意，並顯著影響設備的感知。
因此，在快速設備中，UI 管道是系統中最重要的東西，而不是保持 UI 管道正常運行所必需的。這意味著 UI 管道應該搶占流體 UI 不需要的任何其他工作。為了保持流暢的 UI，如果 UI 工作可以運行，後台同步、通知傳遞和類似的工作都必須延遲。可以接受更長操作（HDR+ 運行時、應用程序啟動等）的性能來維持流暢的 UI。
容量與抖動
在考慮設備性能時，容量和抖動是兩個有意義的指標。
容量
容量是設備在一段時間內擁有的某些資源的總量。這可以是 CPU 資源、GPU 資源、I/O 資源、網絡資源、內存帶寬或任何類似的指標。在檢查整個系統的性能時，抽象各個組件並假設一個確定性能的指標可能很有用（尤其是在調整新設備時，因為在該設備上運行的工作負載可能是固定的）。
系統的容量因在線計算資源而異。更改 CPU/GPU 頻率是更改容量的主要手段，但還有其他方法，例如在線更改 CPU 內核數。因此，系統的容量與功耗相對應；容量的變化總是會導致功耗的類似變化。
給定時間所需的容量很大程度上取決於正在運行的應用程序。因此，該平台幾乎無法調整給定工作負載所需的容量，並且這樣做的手段僅限於運行時改進（Android 框架、ART、仿生、GPU 編譯器/驅動程序、內核）。
抖動
雖然很容易看出工作負載所需的容量，但抖動是一個更加模糊的概念。有關抖動作為快速系統障礙的良好介紹，請參閱丟失超級計算機性能的案例：在 ASCl Q 的 8,192 個處理器上實現最佳性能。 （這是對為什麼 ASCI Q 超級計算機沒有達到其預期性能的調查，是對優化大型系統的一個很好的介紹。）
本頁使用術語抖動來描述 ASCI Q 論文所稱的噪聲。抖動是阻止可感知工作運行的隨機系統行為。它通常是必須運行的工作，但它可能沒有嚴格的時序要求導致它在任何特定時間運行。因為它是隨機的，所以很難證明給定工作負載的抖動存在。證明一個已知的抖動源是特定性能問題的原因也是極其困難的。最常用於診斷抖動原因的工具（例如跟踪或日誌記錄）可能會引入它們自己的抖動。
在 Android 的實際實現中遇到的抖動來源包括：
- 調度程序延遲
- 中斷處理程序
- 驅動程序代碼運行時間過長且禁用搶占或中斷
- 長時間運行的軟中斷
- 鎖爭用（應用程序、框架、內核驅動程序、binder 鎖、mmap 鎖）
- 文件描述符爭用，其中低優先級線程持有文件鎖，阻止高優先級線程運行
- 在可能延遲的工作隊列中運行 UI 關鍵代碼
- CPU 空閒轉換
- 日誌記錄
- I/O 延遲
- 不必要的進程創建（例如，CONNECTIVITY_CHANGE 廣播）
- 可用內存不足導致的頁面緩存抖動
給定抖動週期所需的時間量可能會隨著容量的增加而減少，也可能不會減少。例如，如果驅動程序在等待從 i2c 總線讀取數據時禁用中斷，則無論 CPU 是在 384MHz 還是 2GHz 都將花費固定的時間。當涉及抖動時，增加容量並不是提高性能的可行解決方案。因此，更快的處理器通常不會在抖動受限的情況下提高性能。
最後，與容量不同，抖動幾乎完全在系統供應商的範圍內。
內存消耗
內存消耗傳統上被歸咎於性能不佳。雖然消耗本身不是性能問題，但它可能通過低內存殺手開銷、服務重啟和頁面緩存抖動導致抖動。減少內存消耗可以避免性能不佳的直接原因，但可能還有其他有針對性的改進來避免這些原因（例如，固定框架以防止它在不久之後被分頁時被分頁）。
分析初始設備性能
從一個功能正常但性能不佳的系統開始，並嘗試通過查看用戶可見的性能不佳的個別案例來修復系統的行為，這不是一個合理的策略。由於較差的性能通常不容易重現（即抖動）或應用程序問題，因此整個系統中的變量過多會阻止此策略有效。因此，很容易錯誤地識別原因並進行小幅改進，同時錯過修復整個系統性能的系統機會。
相反，在啟動新設備時使用以下通用方法：
- 在所有驅動程序運行和一些基本頻率調節器設置的情況下將系統引導至 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 ）。
您希望從這種顯示跟踪中獲得直接指示幀已傳送到顯示器的單個事件。從那裡，您可以確定您是否成功達到了幀時間；如果事件 X n發生在事件 X n-1之後不到 16.7 毫秒（假設顯示為 60Hz），那麼您就知道您沒有卡頓。如果您的 SOC 不提供此類信號，請與您的供應商合作以獲取它們。如果沒有確定的幀完成信號，調試抖動是極其困難的。
使用綜合基準
綜合基準有助於確保設備的基本功能存在。但是，將基準視為感知設備性能的代理是沒有用的。
根據 SOC 的經驗，SOC 之間的綜合基準性能差異與可感知的 UI 性能（丟幀數、第 99 個百分位幀時間等）的類似差異無關。綜合基準是僅容量基準；抖動僅通過從基準的批量操作中竊取時間來影響這些基準的測量性能。因此，綜合基準分數作為用戶感知性能的衡量標準幾乎是無關緊要的。
考慮兩個運行 Benchmark X 的 SOC，它們渲染 1000 幀 UI 並報告總渲染時間（分數越低越好）。
- SOC 1 在 10ms 內渲染 Benchmark X 的每一幀，得分為 10,000。
- SOC 2 在 1 毫秒內渲染了 99% 的幀，但在 100 毫秒內渲染了 1% 的幀，得分為 19,900，得分顯著提高。
如果基準表明實際 UI 性能，則 SOC 2 將無法使用。假設刷新率為 60Hz，SOC 2 每運行 1.5 秒就會有一個 janky 幀。同時，SOC 1（根據基準 X 較慢的 SOC）將是完全流動的。
使用錯誤報告
錯誤報告有時對性能分析很有用，但由於它們如此重量級，它們很少用於調試零星的卡頓問題。它們可能會提供一些關於系統在給定時間所做的事情的提示，尤其是當卡頓發生在應用程序轉換（記錄在錯誤報告中）時。錯誤報告還可以指示系統何時出現更廣泛的錯誤，可能會降低其有效容量（例如熱節流或內存碎片）。
使用 TouchLatency
一些不良行為示例來自 TouchLatency，它是用於 Pixel 和 Pixel XL 的首選週期性工作負載。它在frameworks/base/tests/TouchLatency中可用，有兩種模式：觸摸延遲和彈跳球（要切換模式，請單擊右上角的按鈕）。
彈跳球測試就像看起來一樣簡單：一個球永遠在屏幕上彈跳，無論用戶輸入如何。它通常也是迄今為止最難完美運行的測試，但越接近運行而沒有任何丟幀，您的設備就會越好。彈跳球測試很困難，因為它是一個微不足道但完全一致的工作負載，以非常低的時鐘運行（假設設備具有頻率調節器；如果設備改為以固定時鐘運行，則將 CPU/GPU 降頻到接近最低第一次運行彈跳球測試時）。隨著系統停頓和時鐘接近空閒，每幀所需的 CPU/GPU 時間增加。您可以觀看球並查看卡頓，您還可以在 systrace 中查看丟失的幀。
由於工作負載非常一致，因此您可以通過跟踪每個丟失幀期間系統上運行的確切內容而不是 UI 管道來比大多數用戶可見的工作負載更容易識別大多數抖動源。較低的時鐘通過使任何抖動更可能導致丟幀來放大抖動的影響。因此，TouchLatency 越接近 60FPS，在大型應用程序中出現導致零星、難以重現的卡頓的不良系統行為的可能性就越小。
由於抖動通常（但並非總是）時鐘速度不變，因此請使用以非常低的時鐘運行的測試來診斷抖動，原因如下：
- 並非所有抖動都是時鐘速度不變的；許多來源只是消耗CPU時間。
- 調速器應該通過計時使平均幀時間接近截止日期，因此花費在運行非 UI 工作上的時間可能會將其推到邊緣以丟棄幀。