Google is committed to advancing racial equity for Black communities. See how.
本頁面由 Cloud Translation API 翻譯而成。
Switch to English

績效評估

使用Simpleperf評估設備的性能。 Simpleperf是適用於Android上的應用程序和本機進程的本機性能分析工具。使用CPU Profiler實時檢查應用程序CPU使用率和線程活動。

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

  • 可預測的性能 。用戶界面(UI)是否丟幀或始終以60FPS渲染?音頻播放時沒有偽影或爆裂嗎?用戶觸摸屏幕與顯示器上顯示的效果之間的延遲有多長時間?
  • 更長的操作 (例如打開應用程序) 所需的時間長度

第一個比第二個更引人注目。用戶通常會注意到jank,但是除非並排查看兩個設備,否則他們將無法分辨500ms與600ms應用程序的啟動時間。觸摸等待時間立即引起注意,並極大地促進了設備的感知。

結果,在快速的設備中,UI管道是系統中最重要的事情,而不是保持UI管道正常運行所必需的。這意味著UI管道應優先於流暢的UI不需要的任何其他工作。為了保持流暢的UI,如果可以運行UI工作,則必須延遲後台同步,通知傳遞和類似工作。可以交換較長的操作(HDR +運行時,應用程序啟動等)來維持流暢的UI,這是可以接受的。

容量與抖動

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

容量

容量是設備在一段時間內擁有的某些資源的總量。這可以是CPU資源,GPU資源,I / O資源,網絡資源,內存帶寬或任何類似指標。在檢查整個系統的性能時,抽象各個組件並採用一個確定性能的度量標準很有用(尤其是在調整新設備時,因為在該設備上運行的工作負載可能是固定的)。

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

給定時間所需的容量絕大多數由正在運行的應用程序確定。結果,該平台幾乎無法調整給定工作負載所需的容量,並且這樣做的手段僅限於運行時改進(Android框架,ART,Bionic,GPU編譯器/驅動程序,內核)。

抖動

雖然很容易看到工作負載所需的容量,但抖動是一個更模糊的概念。有關抖動的快速入門知識,請參見超級計算機性能不佳的情況:在ASCl Q的8,192個處理器上獲得最佳性能 。 (這是對為何ASCI Q超級計算機未達到其預期性能的調查,它是優化大型系統的重要介紹。)

此頁面使用抖動一詞來描述ASCI Q論文所說的噪聲 。抖動是阻止可感知工作運行的隨機系統行為。通常是必須運行的工作,但是可能沒有嚴格的時間要求導致它在任何特定時間運行。由於它是隨機的,因此很難證明給定工作負載是否存在抖動。很難證明已知的抖動源是造成特定性能問題的原因。診斷抖動原因(例如跟踪或記錄)最常用的工具可以引入自己的抖動。

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

  • 調度程序延遲
  • 中斷處理程序
  • 驅動程序代碼在搶占或中斷禁用的情況下運行時間過長
  • 長時間運行的軟件
  • 鎖爭用(應用程序,框架,內核驅動程序,活頁夾鎖,mmap鎖)
  • 低優先級線程持有文件鎖的文件描述符爭用,阻止高優先級線程運行
  • 在可能會延遲的工作隊列中運行對用戶關鍵的代碼
  • CPU空閒轉換
  • 記錄中
  • I / O延遲
  • 不必要的過程創建(例如,CONNECTIVITY_CHANGE廣播)
  • 由於可用內存不足而導致的頁面緩存抖動

給定抖動週期所需的時間量可能會隨著容量的增加而減少,也可能不會減少。例如,如果驅動程序在等待通過i2c總線進行讀取時使中斷保持禁用狀態,則無論CPU是384MHz還是2GHz,這都將花費固定的時間。當涉及抖動時,增加容量不是提高性能的可行解決方案。結果, 在抖動受限的情況下速度更快的處理器通常不會提高性能。

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

內存消耗

傳統上將內存消耗歸咎於性能不佳。儘管消耗量本身不是性能問題,但它可能由於低內存殺手開銷,服務重啟和頁面緩存抖動而引起抖動。減少內存消耗可以避免性能不佳的直接原因,但是可能還有其他針對性的改進也可以避免這些原因(例如,固定框架以防止在不久之後將其分頁時將其分頁)。

分析初始設備性能

從功能正常但性能不佳的系統開始,並嘗試通過查看用戶可見的性能不佳的個別情況來修復系統的行為,這不是一個明智的策略。由於性能不佳通常不易重現(即抖動)或應用程序問題,因此整個系統中的變量過多會阻止該策略生效。結果,很容易錯誤地找出原因並進行較小的改進,同時又缺少在整個系統中修復性能的系統性機會。

而是在啟動新設備時使用以下一般方法:

  1. 在所有驅動程序都在運行並且有一些基本的頻率調節器設置的情況下,將系統引導到UI(如果您更改頻率調節器設置,請重複以下所有步驟)。
  2. 確保內核支持sched_blocked_reason跟踪點以及顯示流水線中的其他跟踪點,這些跟踪點指示何時將幀交付給顯示。
  3. 取整個UI管道的長的痕跡(從經由IRQ到最後掃描輸出接收輸入),而運行的輕質和一致的工作量(例如, UiBench或在球試驗TouchLatency) 。
  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 )。

    您希望從這種顯示跟踪中獲得的是一個事件,該事件直接表明幀已交付給顯示器。從那裡,您可以確定是否成功達到了幀時間。如果事件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.5s操作中產生一個不穩定的幀。同時,SOC 1(根據基準X的SOC較慢)將非常流暢。

使用錯誤報告

錯誤報告有時對於性能分析很有用,但是由於它們非常重,因此很少用於調試零散的垃圾問題。他們可能會提供有關給定時間系統運行情況的一些提示,尤其是如果問題圍繞應用程序轉換(記錄在錯誤報告中)時尤其如此。錯誤報告還可以指示系統何時出現更廣泛的問題而可能降低其有效容量(例如,熱調節或內存碎片)。

使用TouchLatency

不良行為的幾個示例來自TouchLatency,它是Pixel和Pixel XL首選的定期工作負載。它可以在frameworks/base/tests/TouchLatency並具有兩種模式:觸摸延遲和彈跳球(要切換模式,請單擊右上角的按鈕)。

彈跳球測試就像它看起來一樣簡單:無論用戶輸入什麼,球都會在屏幕上永久彈跳。 到目前為止 ,它通常也是最難於完美運行的測試,但是越接近無丟幀運行,您的設備就會越好。彈跳球測試很困難,因為它是一個瑣碎但完全一致的工作負載,它以非常低的時鐘頻率運行(這假設設備具有頻率調節器;如果設備以固定的時鐘頻率運行,則將CPU / GPU降頻至最小頻率首次運行彈跳球測試時)。隨著系統的停頓和時鐘的下降接近空閒狀態,每幀所需的CPU / GPU時間增加。您可以觀看球並看到垃圾,並且還可以在systrace中看到丟失的幀。

因為工作負載是如此一致,所以通過跟踪每個丟失幀(而不是UI管道)在系統上確切運行的內容,您可以比大多數用戶可見的工作負載更容易地識別大多數抖​​動源。 較低的時鐘通過使任何抖動都導致丟幀的可能性更大,從而放大了抖動的影響。因此,TouchLatency越接近60FPS,就越不會出現不良的系統行為,這些行為會在較大的應用程序中引起零星的,難以再現的問題。

由於抖動通常(但並非始終)是時鐘速度不變的,因此出於以下原因,請使用運行在非常低的時鐘上的測試來診斷抖動:

  • 並非所有的抖動都是時鐘速度不變的。許多資源只是消耗CPU時間。
  • 調速器應通過降低時鐘來使平均幀時間接近截止日期,因此花在運行非UI工作上的時間會將其推到邊緣以丟幀。