在效能方面，有兩項使用者可見的指標：

• 可預測、可察覺的效能。介面是否掉幀或始終以 60FPS的速率渲染？是否出現音訊在沒有軟體工件或彈出的情況下會播放？使用者在觸控式螢幕幕後要多久顯示屏上才會顯示相應結果？
• 耗時操作所需的時間長短（如開啟應用）。
  前者比後者更顯而易見。使用者通常會注意到卡頓情況，但分辨不出 500 毫秒和 600 毫秒應用啟動時間的差別，除非將兩臺裝置並排進行對比。觸控延遲立刻就能被發現，且嚴重影響使用者對裝置的印象。

因此，在速度較快的裝置中，相較於其他使 UI通道保持正常運轉所必需的要素，UI通道是最重要的。這意味著，如果不是保持介面流暢運轉所必需的任務，都應為 UI通道讓路。要讓介面保持流暢運轉，後臺同步、通知傳送及類似的任務都必須延遲（如果介面任務可以執行的話）。可以犧牲耗時操作（HDR+ 執行時、應用啟動等）的效能來保持介面的流暢性。

Capacity和抖動

在評價裝置效能時，容量和抖動是兩項重要指標。

Capacity

Capacity是裝置在一段時間內擁有的某種資源的總量。這種資源可以是 CPU 資源、GPU 資源、I/O 資源、網路資源、儲存裝置頻寬或其他類似指標。在檢測整個系統的效能時，抽取各個元件並假設某單項指標決定著效能將很有幫助（尤其是除錯新裝置時，因為在新裝置上執行的工作負載可能是固定的）。

系統容量因線上計算資源而異。更改 CPU/GPU 頻率是改變容量的主要方式，但也有其他方式，如更改線上 CPU 核心數。相應地，系統的容量與耗電量相對應，** 更改容量一定會導致耗電量出現類似的變化**。

特定時間內所需的容量在絕大多數情況下取決於正在執行的應用。因此，平臺幾乎不能調整特定工作負載所需的容量，調整所用的方式也僅限於執行時改進（Android 框架、ART、Bionic、GPU 編譯器/驅動程式、核心）。

抖動

本頁使用“抖動”這一術語來介紹 ASCI Q 論文中提到的噪點。抖動是一種隨機的系統行為，會阻止可察覺任務的執行。通常是必須執行的任務，但可能對在任一特定時間執行沒有嚴格的定時要求。因為抖動具有隨機性，所以很難證明某一特定工作負載不存在抖動，也很難證明某已知抖動源是導致某個特定效能問題的原因。診斷抖動原因最常用的工具（如跟蹤或日誌記錄）可能會引入它們自己的抖動。

在實際的 Android 實現中遇到的抖動源包括：

• 排程程式延遲
• 中斷處理程式
• 驅動程式程式碼在搶佔或中斷被停用的情況下執行時間過長
• 執行時間較長的軟中斷
• 鎖爭用（應用、框架、核心驅動程式、Binder 鎖、mmap 鎖）
• 檔案描述符爭用，低優先順序的執行緒持有某個檔案的鎖，以防止高優先順序執行緒執行
• 在可能會延遲的工作佇列中執行介面關鍵型程式碼
• CPU 空閒轉換
• 記錄
• I/O 延遲
• 建立不必要的程序（如 CONNECTIVITY_CHANGE 廣播）
• 釋放記憶體不足所導致的頁面快取顛簸

特定時段內的抖動所需的時間不一定會隨著容量的增加而減少。例如，如果驅動程式在等待來自 i2c 匯流排的讀取時使中斷處於停用狀態，那麼無論 CPU 是 384MHz 還是 2GHz，所需要的時間都是固定的。涉及抖動時，增加容量並非提升效能的可行解決方案。因此，更快的處理器在抖動受限的情況下通常不會提升效能。

最後，與容量不同的是，抖動幾乎完全存在於系統產商的領域中。

記憶體消耗

一直以來，人們都將效能不佳歸因於記憶體消耗。雖然消耗本身不是效能問題，但是它可能會通過 lowmemorykiller 開銷、服務重啟和頁面快取顛簸引起抖動。減少記憶體消耗可以避免導致效能不佳的直接原因，但是還有其他可避免這些原因的具有針對性的改進（如把framework固定住，當其接下來很快就會page in的時候將其page out）。

分析初始裝置效能

從執行正常但效能不佳的系統開始，並嘗試通過檢視使用者可見的糟糕效能的每個個案來修復系統的行為，這種做法並非良策。因為效能不佳通常不易重現（如抖動）或者由應用問題導致，整個系統中可阻止此策略發揮作用的變數非常多。因此，很容易錯誤地識別原因並做出微小的改進，而錯失修復整個系統性能的系統性機會。

相反，在啟動新裝置時，請使用以下常規方法：

1. 使系統啟動到所有驅動程式執行的介面和一些基本的頻率調節器設定（如果更改頻率調節器設定，請重複以下所有步驟）。
2. 確保核心支援 sched_blocked_reason 跟蹤點以及顯示通道中指示何時將幀傳送到顯示屏的其他跟蹤點。
3. 在執行輕量級的一致性工作負載（如 UiBench 或 TouchLatency 中的球測試）的同時，對整個介面通道（從通過 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 一文）。

你希望從這種顯示跟蹤中瞭解的是，直接指明某個幀已被髮送至顯示屏的單個事件。在這裡，您可以確定是否成功滿足幀時間；如果事件 Xn 的發生時間在事件 Xn-1 發生後的 16.7 毫秒內（假設為 60Hz 的顯示屏），您就會知道沒有卡頓。如果您的 SOC 不提供這種訊號，請與您的供應商聯絡以進行獲取。如果沒有明確的幀完成訊號，很難除錯抖動。

使用synthetic benchmarks

synthetic benchmark 有助於確保裝置的基本功能是存在的。不過，將基準視為感知裝置效能的代理毫無用處。

根據 SOC 使用體驗，SOC 之間的synthetic benchmarks效能的差異與可察覺的介面效能（丟失幀數、第 99 個百分位幀時間等）中的類似差異不相關。synthetic benchmarks屬於capacity-only的benchmark；抖動僅可以從benchmark的批量操作中竊取時間來影響這些基準衡量的效能。因此，合成基準得分在作為使用者可察覺的效能的指標時是最不相關的指標。

考慮兩種執行可渲染 1000 幀介面的基準 X 的 SOC，並報告總渲染時間（得分越低越好）。

• SOC 1 在 10 毫秒內渲染每幀基準 X，得分為 10000。
• SOC 2 在 1 毫秒內渲染 99% 的幀，但是在 100 毫秒內渲染 1% 的幀，得分為 19900，得分明顯較好。

如果benchmark結果代表實際的介面效能，則 SOC 2 將無法使用。假設重新整理率為 60Hz，SOC 2 在每 1.5 秒的操作內將出現一次卡頓幀。與此同時，SOC 1（根據基準 X 得出的較慢的 SOC）將會非常流暢。

使用 bug reports

Bug reports 有時對於效能分析非常有用，但是因為這類報告的內容全面而複雜，因此對除錯分散的卡頓問題用處不大。報告可能會提供一些有關係統在特定時間內所執行操作的線索，尤其是卡頓出現在應用轉換（會被記錄在缺陷報告中）時。bug reports還可以指出可能會減少其有效容量的系統大範圍出錯（如溫控調頻或記憶體碎片）的時間。

使用 TouchLatency

一些不良行為的示例來自於 TouchLatency（即用於 Pixel 和 Pixel XL 的首選週期性工作負載），可通過 frameworks/base/tests/TouchLatency 找到，具有兩種模式：觸控延遲和彈力球（要切換模式，請點選右上角的按鈕）。

彈力球測試就跟看上去的一樣簡單：無論使用者輸入什麼內容，球都會一直在螢幕上彈跳。這通常也是目前為止最難完美執行的測試，不過，越接近在沒有丟失幀的情況下執行，就說明您的裝置越好。彈力球測試很難執行，因為它是以很低的時鐘頻率執行的瑣碎但完全一致的工作負載（此時假設裝置配有頻率調節器；不過，如果裝置是以固定的時鐘頻率執行，則在首次執行彈力球測試時將 CPU/GPU 降頻到接近最小值）。當系統靜止且時鐘頻率降至接近空閒時，每幀所需的 CPU/GPU 時間增加。您可以檢視球以及卡頓的物件，還可以在 systrace 中檢視丟失的幀。

因為這樣的工作負載是非常一致性的，所以在大多數使用者可見的工作負載中，您可以在每個丟失的幀期間跟蹤系統上正在執行的工作負載（而非UI通道），從而更輕鬆地確定大多數抖動源。較低的時鐘頻率會使任何抖動都更有可能造成幀丟失，從而放大抖動的效果。 因此，TouchLatency 越接近 60 幀/秒，您在較大的應用中遇到導致分散、難以重現的卡頓的不良系統行為的可能性越小。

由於抖動通常（但不總是）是時鐘頻率不變化導致，請使用以非常低的時鐘速度執行的測試來診斷抖動，原因如下：

• 並非所有抖動都是由於時鐘頻率不變，很多抖動僅僅是源於消耗的 CPU 時間。
• 調頻的governor應通過降頻獲取接近截止時間的平均幀時間，這樣執行非介面任務所花費的時間可將其推至掉幀的邊緣。