国产白浆喷水在线视频免费看 ,高级会所深喉吞精69式视频

Android 的用戶界面渲染是從應用中 "生成" 一幀然后顯示在屏幕上，為了確保用戶能夠獲得順暢的交互體驗，您的應用需要根據(jù)設備的刷新率完成每一幀的 "生成"。例如，Pixel 6 設備支持每秒最多渲染 90 幀，這就意味著應用的每一幀任務都要在 1000/90 = 11ms 內完成，如果沒有，Android 框架就會將這一幀的渲染跳過，用戶就會從視覺上感受到界面運行緩慢，我們稱這種情況為 "卡頓"。

出現(xiàn)卡頓的原因有很多種，例如，由應用導致的卡頓或由 Surf aceFlinger 導致的卡頓。本文重點關注由應用導致的卡頓，以及 Android Studio 提供的用于發(fā)現(xiàn)和消除這些卡頓的工具，方法是在應用交互的過程中檢查記錄的軌跡來解決應用的性能問題。

注意:本文所展示的是Android Studio Chipmunk 更新后的卡頓檢測界面，使用 Android 12 (API 級別 31) 或更高版本的真機或模擬器。

從實時交互記錄軌跡

以下示例使用 GitHub 性能示例倉庫中的 JankStatsSample 應用來展示如何使用 CPU 性能分析器鎖定卡頓的原因:

https://github.com/android/performance-samples/tree/main/JankStatsSample 1. 打開 JankStatsSample 并運行應用。 2. 打開 Android Studio 底部的 Profiler 標簽頁。

3. 點擊 Profiler 左側窗格中的 + 圖標啟動新的性能分析會話，然后選擇要運行性能分析器的設備名稱和應用進程。

注意: 雖然可以分析 "可調試應用" (debuggable app)，但推薦做法是分析 "可分析應用" (profileable app)，因為分析 "可調試應用" 會導致性能開銷顯著增加。更多詳細信息，請參閱關于可分析應用的文檔:

https://developer.android.google.cn/studio/profile#profileable-apps

4. 點擊 CPU 行。

5. 選擇 System Trace Recording，點擊 Record。

6. 與應用互動以收集數(shù)據(jù)，然后點擊 Stop 按鈕。Android Studio 將顯示 Display 窗格，其中可見卡頓幀，也可以選中 All Frames 復選框，讓軌跡記錄也顯示非卡頓幀。

將鼠標指針懸停在幀上或點擊幀，即可查看詳細的幀信息。如果選中 All Frames 復選框，將有三種類型的幀。

綠色幀不卡頓的正常幀

紅色幀由于應用進程運行時間超出預期并且錯過了預期幀時長的截止時間，被視為卡頓的幀。從應用開發(fā)者的角度來看，可操作幀通常是紅色幀。

黃色幀被視為緩沖區(qū)填充的幀，這表示應用會在呈現(xiàn)前一幀之前不斷將幀發(fā)送到系統(tǒng)。這通常是前一幀卡頓所致，應用開發(fā)者面對黃幀無能為力。

選中 Lifecycle 復選框，可以切換顯示/隱藏四個附加軌跡。

四個軌跡:

Application

Wait for GPU

Composition

Frames on display

Android Studio Bumblebee (2021.1.1) 穩(wěn)定版中已經加入了這些軌跡信息的顯示。您可以在文檔中查看每個軌跡的詳細說明:

https://developer.android.google.cn/studio/profile/jank-detection#jank-detection-android-11

檢查卡頓幀

接下來，我們來找出卡頓幀出現(xiàn)的原因。

1.在 Janky frames 軌跡中選擇一個卡頓幀，Display 窗格將突出顯示相應的生命周期數(shù)據(jù)，Threads 窗格將突出顯示相應的線程數(shù)據(jù)。

虛線 Deadline 代表截止時間。當幀的時長超過該截止時間時，該幀即被視為卡頓。

您還可以在 Android Studio 的右側窗格中查看詳細分析。

2. 如果您看一下應用主線程相應的軌跡窗格，可以看到大量的時間花費在 "View#draw" 中。

此外，如詳細分析窗格中的主線程狀態(tài)所示，大量線程所處的狀態(tài)是正在休眠。

3. 我們看一下調用 View#draw 的代碼。View#onDraw 在 JankyView 類中被復寫:

https://github.com/android/performance-samples/blob/main/JankStatsSample/app/src/main/java/com/example/jankstats/JankyView.kt#L36

override fun onDraw(canvas: Canvas) {  simulateJank()  super.onDraw(canvas)}

從 onDraw 調用的 simulateJank 方法定義如下: https://github.com/android/performance-samples/blob/main/JankStatsSample/app/src/main/java/com/example/jankstats/tools/simulateJank.kt#L29

fun simulateJank(    jankProbability: Double = 0.3,    extremeJankProbability: Double = 0.02) {    val probability = nextFloat()
    if (probability > 1 - jankProbability) {        val delay = if (probability > 1 - extremeJankProbability) {            nextLong(500, 700)        } else {            nextLong(32, 82)        }
        try {            // 在分析器中通過軌跡使卡頓更易被鎖定            trace("Jank Simulation") {                Thread.sleep(delay)            }        } catch (e: Exception) {        }    }}

然后，您可以發(fā)現(xiàn)在 simulateJank 方法中調用了 Thread.sleep。顯然，這是因為 JankStatsSample 應用是為了模擬卡頓而特別創(chuàng)建的。但值得注意的是，從卡頓幀的概覽再到更詳細的分析，可以找出實際代碼。注意:雖然在這個示例中調用 Thread.sleep 明顯有問題，但實際上，在優(yōu)化實際應用代碼時，您將面臨更困難的決定。Microbenchmark 開發(fā)庫有助于衡量所做的更改能否達成預期效果: https://developer.android.google.cn/topic/performance/benchmarking/microbenchmark-overview 注意: 系統(tǒng)軌跡顯示的是由平臺代碼和屬于應用的庫捕獲的多個部分，通常沒有足夠的信息。添加自定義軌跡能夠改善這樣的情況，添加的方法之一是使用 AndroidX Tracing 庫中的 trace(“MySection”) { /* this will be in the trace */ }。

AndroidX Tracing
https://developer.android.google.cn/reference/androidx/tracing/Trace

例如，此示例中的 trace(“Jank Simulation”) { … } 顯示在相應線程的軌跡部分中。

如需了解關于讀取軌跡和添加自定義軌跡的更多信息，請參閱系統(tǒng)軌跡概述:

https://developer.android.google.cn/topic/performance/tracing

4. 將代碼更改為在 onDraw 中不去調用 simulateJank 方法，然后查看是否仍然存在卡頓幀。

override fun onDraw(canvas: Canvas) {  // simulateJank()   super.onDraw(canvas)}

這一次，重新運行系統(tǒng)軌跡錄制時，您會發(fā)現(xiàn)與應用的交互不再有卡頓幀啦。

加載保存的軌跡

您也可以遵循以下步驟，保存軌跡并后續(xù)再加載。保存并加載軌跡后，您可以比較不同版本的跟蹤記錄或者與他人共享。注意:您還可以使用 Macrobenchmark 庫獲取系統(tǒng)軌跡: https://developer.android.google.cn/topic/performance/benchmarking/macrobenchmark-overview 1. 按照從第 1 步至第 6 步的相同步驟，通過實時交互操作錄制軌跡。 2. 點擊保存圖標導出記錄。