Android App 反應卡頓解決方案

Android App 反應卡頓，從技術上將就是UI 渲染慢。

是從您的應用程序生成一個框架並將其顯示在屏幕上的行為。 為了確保用戶與您的應用程序的交互順利，您的應用程序應該在內渲染幀數達到。 如果您的應用程序因UI渲染速度緩慢而受到影響，那麼系統將被迫跳過幀，用戶將感覺到您的應用程序中出現口吃。 我們把這個叫做。

本篇文章主要介紹 開發中的部分知識點，通過閱讀本篇文章，您將收穫以下內容:

1.UI 渲染簡介

2.識別Jank

3.Fix Jank

4.引起Jank 通用問題舉例

我們不是牛逼的程序員，我們只是程序開發中的墊腳石。

我們不發送紅包，我們只是紅包的搬運工。

1.UI 渲染簡介

為了幫助您提高應用程序質量，會自動監視您的應用程序是否有空，並在生命危險儀錶板中顯示信息。 有關如何收集數據的信息，請參閱文檔。

如果您的應用程序出現問題，本頁提供診斷和解決問題的指導。

生命危險儀錶板和系統會跟蹤使用的應用程序的渲染時間統計信息（應用程序的用戶可見部分是從或繪製的）。

如果您的應用程序不使用，就像使用，，或構建的應用程序一樣，則在儀錶板中不提供時間統計信息。

您可以通過運行

來確定您的設備是否正在記錄您的應用的渲染時間指標。

2.識別Jank

在您的應用程序中定位引起的代碼可能很困難。 本部分介紹了三種識別的方法：

• 1.Visual inspection

通過視覺檢查，您可以在幾分鐘內快速瀏覽應用程序中的所有用例，但不能提供與Systrace相同的詳細信息。

• 2.Systrace

提供了更多的細節，但是如果你運行來處理應用程序中的所有用例，那麼就會被大量的數據淹沒，難以分析。

• 3.Custom performance monitoring

和都會在你的本地設備上檢測到。

如果不能在本地設備上重現，則可以構建自定義性能監視器，以測量在現場運行的設備上應用的特定部分。

1. Visual inspection

目視檢查可以幫助您識別正在生產結果的使用案例。 要執行視覺檢查，請打開您的應用程序並手動檢查應用程序的不同部分，然後查看非常粗糙的UI。 以下是進行目視檢查時的一些提示：

• 1.運行release 版本

運行您應用程序的版本（或至少不可調試）的版本。運行時為了支持調試功能而禁用了一些重要的優化，所以確保你正在尋找類似於用戶將看到的東西。

開啟步驟：

開啟配置文件GPU渲染，會在屏幕上顯示條形圖，可以快速直觀地顯示相對於每幀毫秒基準測試渲染窗口幀所花費的時間。

每個條都有著色的組件映射到渲染管道中的一個舞台，所以你可以看到哪個部分花費的時間最長。

例如，如果框架花費大量時間處理輸入，則應該查看處理用戶輸入的應用程序代碼。

開啟 GPU 渲染效果圖

有一些組件，如，是普遍的來源。 如果您的應用程序使用這些組件，那麼運行應用程序的這些部分是一個好。

有時候，只有當應用程序從冷啟動啟動時，才能複製。

• 5.低內存情況下jank 比較容易出現

一旦你發現產生的用例，你可能會有一個很好的想法是什麼導致你的應用程序的結果。 但是，如果您需要更多信息，則可以使用進一步深入研究。

2. Systrace

是一個顯示整個設備在做什麼的工具，並且它可以用於識別應用程序中的。 的系統開銷很小，所以在儀器使用過程中你會感受到卡頓的存在。

用記錄跟蹤，同時在設備上執行用例。 有關如何使用的說明，請參閱演練。 被進程和線程分解。 在查找應用程序的過程，應該如圖所示。

Systrace分析應用程序

上面3個標註點解釋

顯示何時繪製每個框架，並對每個框架進行顏色編碼以突出顯示較慢的渲染時間。 這可以幫助您查找比視覺檢查更準確的單個框架。 有關更多信息，請參閱Inspecting Frames.

框架和庫的一部分包含跟蹤標記。 因此，時間線會顯示何時在UI線程上執行這些方法，以及執行多長時間。

如果沒有向您顯示有關長時間使用UI線程工作的詳細信息，則需要使用來記錄採樣或檢測的方法跟蹤。 一般來說，方法痕迹不適合用於識別排隊，因為由於開銷太大而產生假，並且無法看到線程何時被阻塞。 但是，方法跟蹤可以幫助您識別應用中花費最多時間的方法。 在識別這些方法後，add Trace markers a

標記並重新運行，以查看這些方法是否引起混亂。

當記錄時，每個跟蹤標記（執行的開始 和結束對）會增加大約的開銷。 為了避免假結局，不要將追蹤標記添加到在一幀中被稱為幾十次的方法中，或者短於左右。

如需獲取更多內容，請查看詳解

3. Custom performance monitoring

如果您無法在本地設備上再現突發事件，則可以在您的應用中構建自定義性能監控，以幫助識別現場設備上的突發源。

為此，請使用從應用程序的特定部分收集幀渲染時間，並使用性能監控記錄和分析數據。

要了解更多信息，請參閱使用Use Firebase Performance Monitoring with Android Vitals.

3.Fix Jank

為了解決這個問題，請檢查哪些幀在內沒有完成，並尋找出錯的地方。在一些幀中抽取異常長度，或者可能是？ 查看下面這些問題的常見來源，以及其他問題。

為了避免亂碼，長時間運行的任務應該在之外非同步運行。 一定要注意你的代碼正在運行在哪個線程上，並且在向主線程發布不重要的任務時要小心。

如果您的應用程序有一個複雜而重要的主UI（可能是中央滾動列表），請考慮編寫可自動檢測緩慢渲染時間的測試測試，並經常運行測試以防止出現回歸。 有關更多信息，請參閱自動化性能測試代碼實驗室。

4.引起Jank 通用問題舉例

以下部分解釋了應用程序中常見問題 的來源，以及解決這些問題的最佳方案。

滑動 List

和特別是通常用於複雜的滾動列表，這些列表最容易被忽略。 他們都包含標記，所以你可以使用來弄清楚他們是否有助於在你的應用程序。 一定要傳遞命令行參數來獲取中的跟蹤部分（以及添加的任何跟蹤標記）以顯示出來。 如果可用，請遵循輸出中生成的警報的指導。 在裡面，你可以點擊部分查看正在做的工作的解釋。

RecyclerView: notifyDataSetChanged

如果您看到中的每個項目在一個框架中被反彈（並因此重新布局和重新繪製），請確保您沒有調用，或為小更新。 這些方法表示整個列表內容已經改變，並且將在中顯示為。 而是在內容更改或添加時使用或生成最小更新。

例如，考慮從伺服器接收新聞內容列表的新版本的應用程序。 當您將該信息發布到適配器時，可以調用，如下所示：

RecyclerView: notifyDataSetChanged

但是這帶來了一個很大的缺點 - 如果它是一個微不足道的變化（也許單個項目添加到頂部），不知道 - 它被告知放棄所有的緩存項目狀態，因此需要重新綁定一切。

最好使用，它將為您計算和分配最小的更新。

DiffUtil 使用

只需將您的定義為實現，以通知如何檢查您的列表。

RecyclerView: Nested RecyclerViews

嵌套是很常見的，特別是水平滾動列表的垂直列表（如主頁上的應用程序的網格）。 這可以很好的工作，但也有很多意外四處移動。 如果在第一次向下滾動頁面時看到很多內部項目膨脹，則可能需要檢查是否在內部（水平）之間共享。

默認情況下，每個將擁有自己的物品池。 如果在屏幕上同時顯示一打，那麼當不能被不同的水平列表共享的時候，如果所有的行都顯示了相似類型的視圖，那麼這是有問題的。

RecyclerView: Nested RecyclerViews

如果要進一步優化，還可以在內部的上調用。

例如，如果您總是在一行中可見，請調用. 這將告訴，當一個水平行即將出現在屏幕上時，如果上有空閑時間，它應該嘗試預取內部的項目

RecyclerView: Too much inflation / Create taking too long

則處於閑置狀態下，中的預取功能應該有助於在大多數情況下通過提前完成工作來解決的成本問題。

如果您在一幀中看到（而不是標記為的部分），請確保您正在測試最近的設備（目前僅在及更高版本上支持），並使用最近版本的Support Library.

。

如果經常看到導致屏幕上出現新的，驗證出問題，請移除多餘的。 內容中的視圖類型越少，當新的項目類型出現在屏幕上時，需要完成的就越少。

如果可能的話，將視圖類型合併到合理的位置 - 如果只有圖標，顏色或文本塊在類型之間改變，則可以在綁定時間進行更改，並避免（同時減少應用程序的內存佔用）。

如果您的視圖類型看起來還不錯，請考慮減少的成本。減少不必要的容器和結構視圖可以幫助 - 考慮使用構建，這可以很容易地減少結構視圖。如果你想真正優化性能，你的項目層次結構是簡單的，並且你不需要複雜的和的功能，請考慮自己調用構造函數 - 但請注意，它往往是不值得的損失的簡單性和功能的權衡XML。

RecyclerView: Bind taking too long

綁定（即）應該是非常簡單的，除了最複雜的項目之外的所有項目都要花費少於一毫秒的時間。 它只需從的內部項目數據中獲取項目，然後在中的視圖上調用。 如果需要很長時間，請確認您在綁定代碼中做了最少的工作。

如果您使用簡單的對象來保存適配器中的數據，則可以完全避免使用Data Binding l

庫來將綁定代碼寫入。

RecyclerView or ListView: layout / draw taking too long

有關繪製和布局的問題,請參閱 Layout and Rendering Performance.

ListView: Inflation

如果你不小心，ListView很容易會被意外回收。 如果每次屏幕顯示項目時都看到，請檢查的實現是否正在使用，重新綁定並返回參數。 如果你的實現總是，你的應用程序將無法從中獲得回收的好處。 你的的結構幾乎總是類似於下面的實現：

復用 convertView

Layout performance

如果顯示的布局部分工作太多，或者工作頻繁，這意味著您遇到了布局性能問題。 您的應用的布局性能取決於層次結構的哪個部分具有更改布局參數或輸入。

Layout performance: Cost

如果段長度超過幾毫秒，則可能是針對或weighted-LinearLayouts.

的最差嵌套性能。

這些布局中的每一個都可以觸發其子項的多個傳遞，因此嵌套它們會導致嵌套深度上的行為。 請嘗試避免使用或的特徵，除了層次結構的最低葉節點之外的所有特徵。 有幾種方法可以做到這一點：

• 優化View結構

• 使用自定義View

• 嘗試轉換到ConstraintLayout，它提供了類似的功能，並且沒有性能上的缺陷。

  Layout performance: Frequency

  當新內容出現在屏幕上時，將會發生新的，例如，當一個新項目在中滾動查看時。 如果在每個框架上都發生重要的布局，則可能是在布局上進行動畫處理，這很可能導致丟幀。 通常，動畫應該在的繪圖屬性（例如，等）上運行。 這些都可以比屬性（如填充或邊距）更好地更改。 通常通過調用觸發的，然後在下一幀中繪製（），來更改視圖的繪製屬性。 這將重新記錄無效的視圖的繪圖操作，並且通常也比布局好得多。

  Rendering performance渲染性能

  在兩個階段工作 - 在上，在上繪製。 第一次運行在每個無效的上繪製，並可能調用自定義視圖或代碼。 第二個在本地上運行，但是將根據階段生成的工作進行操作。

  Rendering performance: UI Thread

  如果需要很長時間，則通常是在上繪製點陣圖的情況。 繪製點陣圖需要使用渲染，一般應該避免在主線程中繪製。 您可以使用的方法跟蹤來查看這是否是問題。

  繪製點陣圖通常是在應用程序想要在顯示點陣圖之前修飾點陣圖的時候完成的。 有時候像裝飾圓角的裝飾：

  繪製圓角圖片

  如果這是您在UI線程上所做的工作，則可以在後台的解碼線程上執行此操作。 在這樣的一些情況下，你甚至可以在繪製時做這個工作，所以如果你的代碼看起來像這樣：

  性能差代碼

  可以將上面代碼優化為如下：

  優化性能的代碼

  請注意，這通常也可以用於後台保護（在點陣圖頂部繪製漸變）和圖像過濾（使用），以及修改點陣圖的其他兩種常見操作。

  如果由於其他原因（可能將其用作緩存）繪製到點陣圖，則嘗試繪製直接傳遞到或的硬體加速硬體，如有必要，可考慮使用調用來緩存複雜的渲染 輸出，並仍然利用渲染。

  Rendering performance: RenderThread

  一些操作是便小的消耗，但觸發昂貴的計算。 通常會通知這些。

  Canvas.saveLayer()

  避免 - 它可以觸發昂貴的，未緩存的，離屏渲染每一幀。 儘管的性能得到了提高（當進行優化以避免上的渲染目標切換時），但是如果可能的話，避免使用這個昂貴的仍然是好事，或者至少確保您通過（或者調用一個變體 不帶標誌）。

  Animating large Paths

  當硬體加速傳遞給時，被調用，首先在上繪製這些路徑，然後將它們上傳到。 如果路徑較大，請避免逐幀編輯，以便高速緩存和繪製。 更有效率 - 即使最終使用更多的繪製調用，最好使用它們。

  Canvas.clipPath

  觸發了昂貴的裁剪行為，通常應該避免。 如果可能，選擇繪製形狀，而不是剪裁到非矩形。 它性能更好，支持抗鋸齒。 例如，下面的調用：

  Canvas.clipPath

  Bitmap uploads

  將點陣圖顯示為紋理，並且首次在一幀中顯示點陣圖時，將其上傳到。您可以在中將此視為上傳紋理。這可能需要幾個毫秒（見下圖），但是有必要用GPU顯示圖像。

  點陣圖繪製

  如果這些花費很長時間，請首先檢查軌跡中的寬度和高度數字。確保正在顯示的點陣圖不比顯示的屏幕區域大得多。如果是，則浪費上傳時間和內存。通常點陣圖載入庫提供了簡單的方法來請求適當大小的點陣圖。

  在中，點陣圖載入代碼（通常由庫完成）可以在需要之前調用來及早觸發上傳。這樣上傳發生的早，而空閑。這可以在解碼之後完成，也可以在將點陣圖綁定到時進行，只要知道點陣圖即可。理想情況下，你的點陣圖載入庫會為你做這個，但是如果你正在管理你自己的，或者想確保你沒有在新設備上點擊上傳，你可以在你自己的代碼中調用。

  Thread scheduling delays

  線程調度程序是操作系統的一部分，負責決定系統中哪些線程應該運行，何時運行以及運行多長時間。 有時候，因為你的應用程序的被阻塞或者沒有運行，就會發生。 使用不同的顏色來指示線程正在，，或（紅色或橙色）Jank`問題非常有用。

  注意：

  舊版本的Android更頻繁地遇到不是應用程序故障的調度問題。 在這方面進行了不斷的改進，所以考慮在最近的操作系統版本上更多的調試線程調度問題，在這些版本中，被調度的線程更可能是應用程序的錯誤。

  

  線程渲染過程

  或預計不會運行時，有框架的一部分。 例如，在的正在運行並且上傳點陣圖時被阻塞 - 這是因為可以安全地複製UI線程所使用的數據。 另一個例子是，在使用時可以被阻塞：在幀的開始處獲取緩衝區，從中查詢信息，或者通過將緩衝區傳回給合成器。

  在您的應用程序的執行中經常會有很長時間的暫停，這些都是由上的機制進行的。 在最近的版本中，這是UI線程停止運行的最常見原因之一。 一般來說，修正是為了避免調用函數來調用 如果這是不可避免的，那麼應該緩存該值，或將工作移動到後台線程。 隨著代碼庫變得越來越大，如果不小心的話，通過調用一些低級別的方法，很容易意外地添加了一個調用，但是使用跟蹤來發現和修復它們也是很容易的。

  如果您有綁定事務，則可以使用以下命令來捕獲其調用堆棧：

  adb 命令捕獲堆棧信息

  有時像這樣的無害的表面調用可能會觸發綁定事務，並在頻繁調用時導致嚴重的問題。 定期跟蹤可以幫助您快速找到並解決這些問題。

  UI Thread sleeping due to binder transactions in a RV fling

  如果你沒有看到綁定，但仍然沒有看到你的UI線程運行，請確保你沒有等待來自另一個線程的鎖定或其他操作。 通常，UI線程不應該等待來自其他線程的結果 - 其他線程應該向其發布信息.

  Object allocation and garbage collection

  對象分配和已經成為一個問題，因為是中默認運行時引入的，但是仍然有可能通過這些額外的工作來減輕你的線程負擔。 對於每秒鐘不會發生多次的罕見事件（如用戶單擊按鈕）進行分配是很好的做法，但要記住，每次分配都需要付出一定的代價。 如果它處於一個頻繁調用的緊密循環中，請考慮避免分配來減輕上的負載。

  會告訴你GC是否頻繁運行，可以顯示你的分配來自哪裡。 如果你可以避免分配，特別是在緊密的循環中，你應該沒有問題。

  shows a 94ms GC on the HeapTaskDaemon thread

  在最新版本的上，通常在名為的後台線程上運行。 請注意，大量的分配可能意味著更多的資源花費在上.

  至此，本篇已結束，如有不對的地方，歡迎您的建議與指正。期待您的關注，

  感謝您的閱讀，謝謝！

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！