使用 Android Vitals 監控應用程式的技術品質

如需特定指標的詳細資料，請選取指標旁的「查看詳細資料」圖示 ()。系統將在下個畫面顯示下列資訊：

• 不良行為門檻
• 類別基準
• 基準比較的詳細結果
  • 在頁面頂端附近的同類應用程式比較資訊卡中，選取「編輯同類群組」即可編輯自訂同類群組。建立自訂同類群組之後，就能查看您的應用程式與 Google Play 平台上其他所選應用程式的比較數據。
• 指標變化趨勢

ANR 發生率指標可讓您大致瞭解應用程式的品質。這類指標的計算方式為統計遇到 ANR 情形的使用者人數，並根據應用程式使用情況進行正規化。指標表示方式為每日活躍使用人數百分比，每日活躍使用人數的定義是一天中在單一裝置上使用應用程式的使用者數量。如果使用者在一天內透過多部裝置使用應用程式，系統會依裝置數量計算當天的活躍使用者。如果多位使用者當天使用同一部裝置，系統只會計為一位活躍使用者。

ANR 發生率指標分為以下三種：

• 使用者感知 ANR 事件的發生率：感知到發生至少一次 ANR 的每日活躍使用人數百分比。使用者感知 ANR 事件是指使用者可能已注意到的 ANR 情形。目前只有「input dispatching timed out」的 ANR 事件會列入採計。這個指標會按每日使用情況正規化，而非計入所有 ANR 情形，因此一定會低於整體 ANR 發生率。
  使用者感知 ANR 事件的發生率屬於核心指標，會影響應用程式在 Google Play 上的曝光度。這項指標非常重要，因為計入指標的 ANR 情形皆是在使用者與應用程式互動時發生，嚴重影響了使用者體驗。
• ANR 發生率：遇到至少一次 ANR 的每日使用者人數百分比。這項指標涵蓋使用者未感知到的 ANR，但我們無法保證這類情形未對使用者造成影響。
• 多次 ANR 發生率：遇到至少兩次 ANR 的每日使用者人數百分比。這項指標有助凸顯反覆發生的問題。

修正問題

「當機與 ANR」頁面會顯示計入 ANR 發生率指標的 ANR 情形。您可以在這個頁面上篩選使用者感知的 ANR 情形。

Android 開發人員網站提供診斷及修正 ANR 問題的相關指引。

當機率指標可讓您大致瞭解應用程式的品質。這類指標的計算方式為統計遇到當機情形的使用者人數，並根據應用程式使用情況進行正規化。指標表示方式為每日使用人數百分比，每日使用人數的定義是一天中在單一裝置上使用應用程式的使用者數量。如果使用者透過多個裝置使用應用程式，系統會重複計算使用者。舉例來說，如果兩個使用者各透過一部裝置使用應用程式兩天，就會產生四個每日工作階段。

當機率指標分為以下三種：

• 使用者感知當機率：感知到發生至少一次當機的每日使用者人數百分比。使用者感知的當機是指使用者可能已注意到的當機情形，例如在應用程式顯示過程中，或執行前景服務時發生的當機情形。這個指標會按每日使用情況正規化，而非計入所有當機情形，因此一定會低於整體當機發生率。
  使用者感知當機率屬於核心指標，會影響應用程式在 Google Play 上的能見度。這項指標非常重要，因為計入指標的當機情形皆是在使用者與應用程式互動時發生，且嚴重破壞了使用者體驗。因此，您應確保應用程式不會超過這項指標的不良行為門檻。

• 當機率：遇到至少一次當機的每日使用者人數百分比。這項指標涵蓋使用者未感知到的當機情形，但我們無法保證這類情形未對使用者造成影響。

• 多次當機率：遇到至少兩次當機的每日使用者人數百分比。這項指標有助凸顯反覆發生的問題。

修正問題

Android 開發人員網站提供診斷及修正當機問題的相關指引。

「啟動時間」頁面會顯示應用程式從冷、暖和熱這三種系統狀態下緩慢啟動的詳細資訊。啟動時間是指從使用者啟動應用程式到畫面顯示第一個影格所需要的時間，又稱為「顯示啟動畫面所需時間」。

即使經過這段時間，應用程式仍可能還沒準備好與使用者開始互動，例如應用程式還有其他載入畫面時，就可能發生這樣的情況。

關於資料收集作業的詳細說明

• 系統只會在使用者觸發活動時記錄啟動時間。
  • 範例：鍵盤應用程式的啟動時間等於隨附應用程式的啟動時間。
• 如果應用程式在一天內多次從同一種系統狀態下啟動，系統會記錄當天最長的啟動時間。
• 當應用程式的第一個影格完全載入時，無論使用者是否與該畫面互動，系統都會記錄應用程式的啟動時間。
  • 範例：如果應用程式開啟時會顯示啟動畫面，啟動時間就等於顯示啟動畫面所用的時間。

Vital 詳細資料

• 受影響的工作階段數：使用者在個別系統狀態下遇到啟動時間緩慢問題的工作階段百分比：
  • 冷啟動時間緩慢：5 秒以上
  • 暖啟動時間緩慢：2 秒以上
  • 熱啟動時間緩慢：1 秒以上
• 工作階段數：大致記錄的工作階段數。
• 第 90 個/第 99 個百分位數：10%/1% 的每日工作階段中，使用者在您的應用程式內遇到啟動時間緩慢問題。

修正問題

如果您應用程式的啟動時間緩慢次數過多，請造訪 Android 開發人員網站查看建議的解決方案。

重要性

緩慢工作階段資料可以協助您掌握遊戲的影格速率效能，從而得知使用者是否獲得流暢的遊戲體驗。

瞭解應用程式資料

「緩慢工作階段」頁面會針對使用者遇到超過 25% 影格的執行速度低於 30 或 20 FPS 的情形，顯示這類工作階段在每日工作階段中的詳細占比資料，具體取決於選取的基準。該頁面也會根據遊戲的影格速率顯示各工作階段的分布情形 (系統是在第 75 個百分位數計算工作階段影格速率，這代表至少有 75% 的影格達到這個影格速率)。

Google Play 上的大多數遊戲都應至少達到 30 FPS。無論使用者玩的遊戲類型為何，這個速度都能為使用者提供合理的體驗 (但有些使用者偏好 60 FPS 以上的遊戲，尤其是在高階裝置上)。監控緩慢工作階段比率 (30 FPS) 指標，可確保您達到這個標準。請注意，這項指標只會納入超過 25% 影格低於 30 FPS 的工作階段，因此可容許一定程度的影格速率變異性。

雖然 30 FPS 可提供合理的體驗，但在某些時候或某些類型的遊戲中，低於這個影格速率也可以接受，或者使用者可能想在無法支援 30 FPS 的手機上玩您的遊戲。在這類情況下，工作階段中至少應有 75% 影格仍達到 20 FPS 以上。監控緩慢工作階段比率 (20 FPS) 指標，可確保您達到這個標準。

Android Vitals 會回報每部裝置以及所有裝置和工作階段的緩慢工作階段 (30 FPS 和 20 FPS)。整體指標可用來瞭解整體使用者體驗，但別忘了注意各裝置的效能。Play 會在適當情況下，開始減少顯示無法達到 20 FPS 的遊戲。

遊戲執行 1 分鐘後，Vitals 才會開始監控影格速率。

關於資料收集作業的詳細說明

緩慢工作階段指標是根據 SurfaceFlinger 所收集的資料計算。更具體來說，工作階段的影格速率是根據應用程式介面上繪製每個影格的間隔時間所估算，資料採計範圍包含 OpenGL、Vulkan 和 Android UI 工具包轉譯的影格。目前只有遊戲有這項指標。

系統會鎖定搭載 Android 9 以上版本的裝置，收集緩慢工作階段的影格速率資料。

資訊主頁顯示的資料

• 典型影格速率：遊戲在 Android 9 以上版本裝置中的影格速率表現，依第 75 個百分位數計算。這代表工作階段中有 75% 時間達到或超過這個影格速率。
• 緩慢工作階段比率的變化趨勢：顯示緩慢工作階段占比的時間序列。
• 影格速率分布：顯示各工作階段第 75 個百分位影格速率的直方圖。這代表工作階段中有 75% 影格的影格速率高於用來儲存工作階段的影格速率。

修正問題

如果您應用程式的緩慢工作階段數量過多，請造訪 Android 開發人員網站查看建議的解決方案。

瞭解應用程式資料

「緩慢影格的數量過多」頁面會針對使用者遇到超過 50% 影格未在裝置繪圖期限前輸出的情形，顯示這類工作階段在每日工作階段中的詳細占比資料。使用者與應用程式互動的速度應保持在每秒 60 個影格，而且不應出現掉格或延遲的情況。

關於資料收集作業的詳細說明

Google 會在應用程式透過 UI 工具包架構轉譯影格時收集各個影格的轉譯時間，但不會收集直接利用 OpenGL 或 Vulkan 轉譯影格的時間。

資訊主頁顯示的資料

選取其中一列即可查看百分位數分析資料。

• 受影響的工作階段數：使用者遇到超過 50% 影格轉譯時間超出 16 毫秒的每日工作階段百分比。如果使用者在某一天使用過應用程式，該日即算一個每日工作階段。舉例來說，如果有兩個使用者各自使用應用程式兩天，就會產生四個每日工作階段。
• 工作階段數：大致記錄的工作階段數。
• 第 90 個/第 99 個百分位數：共有 90%/99% 影格的轉譯時間低於系統顯示的數字。這些數字是根據系統收集到的所有頁框而得出。

一旦您點選表格中的項目，系統就會顯示「UI 轉譯時間分布圖」圖表。建議您在查看這個圖表時，確認應用程式中的大部分影格轉譯時間都不超過 16 毫秒。

您可以從圖表下方的資料判斷應用程式的顯示效能，並且找出造成轉譯時間問題的根本原因。舉例來說，如果「輸入延遲時間過長」的百分比偏高，建議您檢查應用程式中用來處理使用者輸入內容的程式碼。如要進一步瞭解這些指標，請參閱測試 UI 效能。

• 錯過的 Vsync 事件數：針對所有轉譯時間超過 16 毫秒的影格，將錯過的 Vsync 事件數除以影格數。
• 輸入延遲時間過長：針對所有轉譯時間超過 16 毫秒的影格，將超過 24 毫秒的輸入事件數除以影格數。
• UI 執行緒速度緩慢：針對所有轉譯時間超過 16 毫秒的影格，將 UI 執行緒超過 8 毫秒才完成的次數除以影格數。
• 繪圖指令速度緩慢：針對所有轉譯時間超過 16 毫秒的影格，將繪圖指令超過 12 毫秒才傳送到 GPU 的次數除以影格數。
• 點陣圖上傳速度緩慢：針對所有轉譯時間超過 16 毫秒的影格，將點陣圖超過 3.2 毫秒才上傳到 GPU 的次數除以影格數。

修正問題

如果您應用程式中轉譯時間超過 16 毫秒的影格數量過多，請造訪 Android 開發人員網站查看建議的解決方案。

瞭解應用程式資料

「緩慢影格的數量過多」頁面會針對使用者遇到超過 50% 影格未在裝置繪圖期限前輸出的情形，顯示這類工作階段在每日工作階段中的詳細占比資料。使用者與應用程式互動的速度應保持在每秒 60 個影格，而且不應出現掉格或延遲的情況。

關於資料收集作業的詳細說明

Google 會在應用程式透過 UI 工具包架構轉譯影格時收集各個影格的轉譯時間，但不會收集直接利用 OpenGL 或 Vulkan 轉譯影格的時間。

資訊主頁顯示的資料

選取其中一列即可查看百分位數分析資料。

• 受影響的工作階段數：使用者遇到超過 50% 影格轉譯時間超出 16 毫秒的每日工作階段百分比。如果使用者在某一天使用過應用程式，該日即算一個每日工作階段。舉例來說，如果有兩個使用者各自使用應用程式兩天，就會產生四個每日工作階段。
• 工作階段數：大致記錄的工作階段數。
• 第 90 個/第 99 個百分位數：共有 90%/99% 影格的轉譯時間低於系統顯示的數字。這些數字是根據系統收集到的所有頁框而得出。

一旦您點選表格中的項目，系統就會顯示「UI 轉譯時間分布圖」圖表。建議您在查看這個圖表時，確認應用程式中的大部分影格轉譯時間都不超過 16 毫秒。

您可以從圖表下方的資料判斷應用程式的顯示效能，並且找出造成轉譯時間問題的根本原因。舉例來說，如果「輸入延遲時間過長」的百分比偏高，建議您檢查應用程式中用來處理使用者輸入內容的程式碼。如要進一步瞭解這些指標，請參閱測試 UI 效能。

• 錯過的 Vsync 事件數：針對所有轉譯時間超過 16 毫秒的影格，將錯過的 Vsync 事件數除以影格數。
• 輸入延遲時間過長：針對所有轉譯時間超過 16 毫秒的影格，將超過 24 毫秒的輸入事件數除以影格數。
• UI 執行緒速度緩慢：針對所有轉譯時間超過 16 毫秒的影格，將 UI 執行緒超過 8 毫秒才完成的次數除以影格數。
• 繪圖指令速度緩慢：針對所有轉譯時間超過 16 毫秒的影格，將繪圖指令超過 12 毫秒才傳送到 GPU 的次數除以影格數。
• 點陣圖上傳速度緩慢：針對所有轉譯時間超過 16 毫秒的影格，將點陣圖超過 3.2 毫秒才上傳到 GPU 的次數除以影格數。

修正問題

如果您應用程式中轉譯時間超過 16 毫秒的影格數量過多，請造訪 Android 開發人員網站查看建議的解決方案。

「部分 Wake Lock 停滯」和「部分 Wake Lock 停滯 (背景)」頁面會顯示應用程式透過 PowerManager 類別取得的部分 Wake Lock。部分 Wake Lock 可確保在能夠關閉螢幕和鍵盤背光的情況下，CPU 也仍會保持運作。

關於資料收集作業的詳細說明

• 為了維護隱私權，部分 Wake Lock 身分識別標記會經過匿名處理。
• 系統只會在裝置未處於充電狀態且關閉螢幕的情況下，收集部分 Wake Lock 的資料。
• 系統只會在應用程式於背景執行的情況下，收集部分 Wake Lock (背景) 的資料。
• Google 會計算每個電池工作階段中部分 Wake Lock 的最長持續時間，顯示受到長時間 Wake Lock 影響的工作階段數。舉例來說，如果使用者觸發兩次持續一小時的 Wake Lock，Google 使用的 Wake Lock 上限值就是一小時。
• 如果應用程式的資訊清單檔案已設定 sharedUserId：只有在已安裝一個 (且不得超過一個) 含有相同 sharedUserId 設定的應用程式時，您才會看到相關資料。

Vital 詳細資料

• 受影響的工作階段數：使用者遇到至少一次長達一小時以上 Wake Lock 的電池工作階段百分比。
• 工作階段數：大致記錄的工作階段數。
• 第 90 個/第 99 個百分位數：在 10%/1% 的每日工作階段中，使用者遇到的部分 Wake Lock 持續時間超過系統顯示的數字。
• 不良行為門檻：如果您應用程式的出現率等於或大於系統顯示的門檻，代表該應用程式位於 Google Play 前 1,000 個熱門應用程式的最低 25% (根據安裝次數計算)。

修正問題

如果您應用程式的部分 Wake Lock 停滯次數過多，請造訪 Android 開發人員網站查看建議的解決方案。

「喚醒次數過多」頁面會顯示應用程式觸發的 Alarm Manager 喚醒次數。您會看到 ELAPSED_REALTIME_WAKEUP 或 RTC_WAKEUP 類別的喚醒資料。

關於資料收集作業的詳細說明

• 為了維護隱私權，喚醒身分識別標記會經過匿名處理。
• 系統只會在裝置未充電時收集喚醒資料。
• 為了提供正規化指標，喚醒次數會與裝置未處於充電狀態的時間做比較。Google 會計算每個使用者每小時遇到的喚醒次數，顯示受到高喚醒發生率影響的使用者人數。
• 如果應用程式的資訊清單檔案已設定 sharedUserId：只有在已安裝一個 (且不得超過一個) 含有相同 sharedUserId 設定的應用程式時，您才會看到相關資料。

Vital 詳細資料

• 受影響的工作階段數：使用者每小時遇到 10 次以上喚醒的電池工作階段百分比。電池工作階段是指系統在指定的 24 小時內，根據收到的所有電池報告彙整而成的時間資料。對於 Android 10 來說，電池報告指的是電池兩次充電 (從低於 20% 充至 80% 以上，或是從任意電量值充至 100%) 之間的間隔時間。對於 Android 11 以上版本來說，電池報告固定為 24 小時。Google 只會在裝置未處於充電狀態時收集資料。
• 工作階段數：大致記錄的工作階段數。
• 第 90 個/第 99 個百分位數：在 10%/1% 的每日工作階段中，使用者每小時遇到喚醒次數超過系統顯示的值。
• 不良行為門檻：如果您應用程式的出現率等於或大於系統顯示的門檻，代表該應用程式位於 Google Play 前 1,000 個熱門應用程式的最低 25% (根據安裝次數計算)。

修正問題

如果您的應用程式經常發生喚醒情形，請造訪 Android 開發人員網站查看建議的解決方案。

「Wi-Fi 掃描次數過多 (背景)」頁面會顯示 Wi-Fi 掃描造成高耗電的時間。

關於資料收集作業的詳細說明

系統只會在裝置未處於充電狀態且應用程式在背景執行的情況下，收集 Wi-Fi 掃描相關資料。

Vital 詳細資料

• 受影響的工作階段數：使用者每小時遇到 4 次以上 Wi-Fi 掃描的電池工作階段百分比。
• 工作階段數：大致記錄的工作階段數。
• 第 90 個/第 99 個百分位數：在 10%/1% 的每日工作階段中，使用者每小時遇到的背景 Wi-Fi 掃描次數超過系統顯示的數字。

修正問題

如果您應用程式的背景 Wi-Fi 掃描次數過多，請造訪 Android 開發人員網站查看建議的解決方案。

「網路用量過大」頁面會顯示大量網路資料與背景服務建立關聯的時間。如果應用程式是在背景中傳輸或接收行動網路數據，使用者通常無法輕易找到可停止這類資料傳輸活動的控制介面。

關於資料收集作業的詳細說明

系統只會在裝置未處於充電狀態且應用程式在背景執行的情況下，收集行動網路用量的相關資料。

Vital 詳細資料

• 受影響的工作階段數：使用者每日遇到背景網路用量超過 50 MB 的電池工作階段百分比。
• 工作階段數：大致記錄的工作階段數。
• 第 90 個/第 99 個百分位數：在 10%/1% 的每日工作階段中，使用者每日遇到的背景網路用量超過系統顯示的數字。

修正問題

如果應用程式的背景網路用量過高，請造訪 Android 開發人員網站查看建議的解決方案。

「權限遭拒」頁面會針對使用者拒絕權限要求的情況，提供每日權限工作階段百分比的詳細資訊。如果應用程式在某一天向使用者要求過至少一項權限，該日即算一個每日權限工作階段。

關於資料收集作業的詳細說明

系統會在使用者針對應用程式內的權限要求做出回應時，收集權限遭拒的資料。

Vital 詳細資料

• 遭拒：使用者拒絕權限要求所佔的每日權限工作階段百分比。
• 不要再詢問我：使用者選取「不要再詢問我」選項來拒絕權限要求的每日權限工作階段百分比。
• 工作階段總數：大致記錄的工作階段數。

修正問題

如果應用程式的權限遭拒次數過多，請造訪 Android 開發人員網站查看建議的解決方案。

Google Play 針對使用者感知的 ANR 發生率定義了不良行為門檻：

• 整體裝置不良行為：在所有裝置型號上，至少有 0.47% 的每日活躍使用者感知到 ANR 情形。

• 每部裝置不良行為：在單一裝置型號上，至少有 8% 的每日活躍使用者感知到 ANR 情形。

如要降低 ANR 發生率，請修正「當機與 ANR」頁面上已回報的基本 ANR 叢集。當受影響的使用者人數越多，系統回報發生 ANR 情形的叢集就越多。

如果裝置硬體或軟體的特定部分可能導致 ANR 發生率上升，Android Vitals 會發出相關通知。此外，您也可以前往「觸及率和裝置總覽」頁面 (依序點選「監控及改善」>「觸及率和裝置」>「總覽」)，自行探究因果關係。

Google Play 針對使用者感知的當機率定義了不良行為門檻：

• 整體裝置不良行為：在所有裝置型號上，至少有 1.09% 的每日使用者感知到當機情形。

• 每部裝置不良行為：在單一裝置型號上，至少有 8% 的每日使用者感知到當機情形。

如要降低當機率，請修正「當機與 ANR」頁面上已回報的基本當機叢集。當受影響的使用者人數越多，系統回報發生當機情形的叢集就越多。

如果裝置硬體或軟體的特定部分可能導致當機率上升，Android Vitals 會發出相關通知。此外，您也可以前往「觸及率和裝置總覽」頁面 (依序點選「監控及改善」>「觸及率和裝置」>「總覽」)，自行探究因果關係。