全新應用程式品質問題深入分析和建議
目前會顯示應用程式相容性問題、不良行為和一些使用者體驗建議。我們會持續偵測及找出更多品質問題，並在來年提供更多最佳化建議。
Android Vitals 可協助您瞭解並改進應用程式在穩定性、效能、電池用量等方面的表現。
選擇應用程式資料的存取方式
Android Vitals 有兩種使用途徑，分別是透過 Play 管理中心和 Play Developer Reporting API。
如果開發人員想將 Android Vitals 資料與其他資料集整合，或是納入到自己的工作流程，可以使用 Play Developer Reporting API，以程式輔助方式存取 Android Vitals。如要進一步瞭解如何使用 API 存取 Android Vitals，請前往 Google Play Developer Reporting API 頁面。
如要在 Play 管理中心尋找及查看應用程式的 Android Vitals 資料，請按照下列步驟操作：
- 開啟 Play 管理中心，然後前往「Android Vitals 總覽」頁面 (依序點選「品質」>「Android Vitals」>「總覽」)。
- 使用右上角的日期範圍選取器，選擇要查看資料的時間範圍。
重要事項：如果沒有可用資料，會導致您的應用程式在特定篩選條件下的資料點不足，無法辨識任何問題。
監控應用程式的核心指標
應用程式核心指標會顯示在「Android Vitals 總覽」頁面的頂端。這些資料不僅是最重要的技術指標，也會影響應用程式在 Google Play 上的曝光度。核心指標包括：
Google Play 會針對這些指標定義不良行為門檻。如果應用程式超過不良行為門檻，在 Google Play 上的能見度可能會下降。在某些情況下，應用程式的商店資訊可能會顯示警告訊息，提醒使用者注意。
在「重大問題」部分，您可以快速找出應用程式有待改進之處。重大問題分為以下兩種：
- 不良行為：超過不良行為門檻的指標
- 異常狀況：資料發生重大變化，例如使用者感知 ANR 事件的發生率急遽提高
如要接收電子郵件通知，請依序點選「設定」>「通知」，或按一下「核心指標」部分 (依序點選「品質」>「Android Vitals」>「總覽」) 角落的「管理通知」。請注意，通知功能目前僅適用於異常狀況。
瀏覽所有 Android Vitals 指標您可以在靠近「Android Vitals 總覽」頁面中間的位置，依照品質來查看所有 Android Vitals 指標資料。
表格中會顯示目前和過往時間範圍的資料。您也可以查看您的應用程式與其他 Google Play 應用程式的比較數據。
如需特定指標的詳細資料，請選取指標旁的「查看詳細資料」圖示 ()。系統將在下個畫面顯示下列資訊：
- 不良行為門檻
- 類別基準
- 基準比較的詳細結果
- 在頁面頂端附近的同類應用程式比較資訊卡中，選取「編輯同類群組」即可編輯自訂同類群組。建立自訂同類群組之後，就能查看您的應用程式與 Google Play 平台上其他所選應用程式的比較數據。
- 指標變化趨勢
為協助您整理、區隔及分析資料，系統會依據多種維度細分指標。所有指標都包含以下分析項目：
- 構件：發生問題的應用程式版本
- Android 版本 (SDK)：使用者裝置回報的 Android 作業系統版本
- 板型規格：執行應用程式的裝置類型 (例如手機、平板電腦、電視、穿戴式裝置)
- 裝置型號：裝置的概略說明，包含獨一無二的品牌名稱和裝置 ID，例如「Google oriole」。單一裝置型號可能會有多種規格，分別搭載不同的 Android 版本、RAM、儲存空間或晶片系統 (SoC)。
- 國家/地區：使用者裝置在發生問題時回報的地點
提示：如要查看裝置硬體或軟體方面 (例如裝置型號或 Android 版本) 的特定分析項目，可以在表格中點選該項目旁的符號 ()。
部分指標另包含其他分析項目：
- Wake Lock 名稱：使用應用程式中的 PowerManager API 時，透過程式輔助方式設定的標記
- 喚醒名稱：使用應用程式中的 AlarmManager API 時，透過程式輔助方式設定的標記
- ANR 活動名稱：發生 ANR 的活動類別完整名稱 (如果有的話)
- ANR 類型：發生 ANR 的時間點，例如執行服務時 (如果有的話)
如要查看更多詳細資料 (例如與分析項目相關的當機或 ANR 叢集)，您可以選取項目旁的「查看詳細資料」圖示 ()。
提示：您可以使用畫面頂端的切換鈕來查看同一類別中的各個指標，也可以篩選頁面。
資料類型和指標
Play 管理中心提供過去 90 天的 Android Vitals 資料，Play Developer Reporting API 則可提供過去三年的資料。
這些資料擷取自使用者已同意自動分享的使用狀況與診斷資料，資料收錄範圍涵蓋部分 Android 裝置與某些 OS 版本。如要進一步瞭解 Android 使用者選擇分享資料的方式，請造訪帳戶說明中心。
Android Vitals 會每天更新。Android 10 以上版本裝置傳送資料的時間，有時候可能會早於 Android 10 以下版本裝置。發生這種情況時，系統只會顯示 Android 10 以上版本裝置已提供的資料。
注意：如果是未經認證的裝置型號或非透過 Google Play 安裝的應用程式版本發生技術問題，系統不會將該問題計入 Android Vitals 指標。
穩定性
ANR 發生率指標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 開發人員網站查看建議的解決方案。
轉譯
所有轉譯程序
緩慢工作階段比率 (30 或 20 FPS) [僅限遊戲]重要性
緩慢工作階段資料可以協助您掌握遊戲的影格速率效能，從而得知使用者是否獲得流暢的遊戲體驗。
瞭解應用程式資料
「緩慢工作階段」頁面會針對使用者遇到超過 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 開發人員網站查看建議的解決方案。
Android UI 工具包轉譯
緩慢影格的數量過多 [僅限應用程式]瞭解應用程式資料
「緩慢影格的數量過多」頁面會針對使用者遇到超過 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 停滯 (背景)「部分 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 針對應用程式的核心指標定義了不良行為門檻。
如果應用程式超過不良行為門檻，在 Google Play 上的能見度可能會下降。如果您的應用程式會在特定裝置型號上出現不良行為，Google Play 就會將採用該裝置型號的使用者導向其他更合適的應用程式。在某些情況下，為協助使用者做好心理準備，應用程式的商店資訊可能會顯示警告，並供使用者選擇其他技術品質較高的應用程式。
一般來說，Google Play 評估應用程式品質時，通常會考量過去 28 天的資料，但如果不良行為暴增，系統可能會提早採取相應措施。
穩定性
使用者感知的 ANR 發生率門檻Google Play 針對使用者感知的 ANR 發生率定義了不良行為門檻：
-
整體裝置不良行為：在所有裝置型號上，至少有 0.47% 的每日活躍使用者感知到 ANR 情形。
-
每部裝置不良行為：在單一裝置型號上，至少有 8% 的每日活躍使用者感知到 ANR 情形。
如要降低 ANR 發生率，請修正「當機與 ANR」頁面上已回報的基本 ANR 叢集。當受影響的使用者人數越多，系統回報發生 ANR 情形的叢集就越多。
如果裝置硬體或軟體的特定因素可能會使 ANR 發生率上升，Android Vitals 會提供通知。此外，您也可以前往「觸及率和裝置總覽」頁面 (依序點選「發布」>「觸及率和裝置」>「總覽」)，自行探索關聯項目。
Google Play 針對使用者感知的當機率定義了不良行為門檻：
-
整體裝置不良行為：在所有裝置型號上，至少有 1.09% 的每日使用者感知到當機情形。
-
每部裝置不良行為：在單一裝置型號上，至少有 8% 的每日使用者感知到當機情形。
如要降低當機率，請修正「當機與 ANR」頁面上已回報的基本當機叢集。當受影響的使用者人數越多，系統回報發生當機情形的叢集就越多。
如果裝置硬體或軟體的特定因素可能使當機率上升，Android Vitals 會提供通知。此外，您也可以前往「觸及率和裝置總覽」頁面 (依序點選「發布」>「觸及率和裝置」>「總覽」)，自行瀏覽關聯項目。
相關內容
請參閱這篇文章，探索運用 Android Vitals 來提升應用程式效能和穩定性的最佳做法。