Android Vitals 有助於 Google 提升 Google Play 上 Android 應用程式的品質。使用者允許後，Android 裝置就會追蹤應用程式品質指標，例如穩定性、效能、電池用量和權限問題。Google Play 會收集這項資料，您可以在 Play 管理中心的 Android Vitals 資訊主頁中存取，也可以透過 Google Play Developer Reporting API 存取。
開發人員應監控 Android Vitals，改善使用者體驗，尤其是核心指標：使用者感知當機率、使用者感知 ANR 事件的發生率、過多的部分喚醒鎖定、記憶體用量和點陣圖記憶體用量。
核心指標和不良行為
應用程式的核心指標會影響您應用程式在 Google Play 上的能見度。除了核心指標外，Android Vitals 也會提醒您需要注意的項目，例如 DEX 程式碼最佳化，這些項目也可能會影響應用程式在 Google Play 的曝光度。使用者感知當機率和使用者感知 ANR 事件的發生率有整體不良行為門檻和每部裝置不良行為門檻。
部分 Wake Lock 使用過度只有整體不良行為門檻，而 Wear OS 上的電池用量過高則有整體和每個手錶型號的門檻。
記憶體用量指標的門檻會因裝置 RAM 層級和應用程式狀態而異，應用程式和遊戲的門檻也不盡相同。點陣圖記憶體用量在各裝置 RAM 層級中相同，但每個應用程式狀態的門檻不同。
常見問題
什麼是核心指標？
核心指標是 Android Vitals 最重要的指標，會影響您應用程式在 Google Play 上的能見度。核心指標包括：
穩定性：所有應用程式的使用者感知當機率和使用者感知 ANR 事件的發生率。
電池：所有應用程式的部分 Wake Lock 過多，以及錶面應用程式的電池用量過高。
記憶體：所有行動應用程式的記憶體用量 (匿名 RSS + 交換空間) 和點陣圖記憶體用量。
什麼是不良行為門檻？
穩定性和電池健康狀態
|
不良行為門檻 為提高應用程式/遊戲在 Google Play 上的能見度，請注意不要超過這些門檻。 |
|||
|---|---|---|---|
| 整體 (所有裝置的平均值) | 個別手機型號 | 個別手錶型號 | |
| 使用者感知的當機率 | 1.09% | 8% | 4% |
| 使用者感知的 ANR 發生率 | 0.47% | 8% | 5% |
| 電池用量過高 | 1% | - | 1% |
| 部分 Wake Lock 使用過度 | 5% | - | - |
記憶體 Vitals
應用程式
|
不良行為門檻 為提高應用程式/遊戲在 Google Play 上的能見度，請注意不要超過這些門檻。 |
|||||
|---|---|---|---|---|---|
| 實體 RAM (記憶體總量範圍) |
應用程式狀態 | ||||
| 前景 | 使用者感知服務 | 背景 | 快取 | ||
| 記憶體用量 (匿名 RSS + 交換空間) | 0 到 4 GB (0 到 3200 MB) |
- | - | - | - |
| 4 GB (3200 - 4800 MB) |
2.00 GB | 1.00 GB | 1.00 GB | - | |
| 6 GB (4800 - 6800 MB) |
2.25 GB | 1.25 GB | 1.25 GB | - | |
| 8 GB (6800 - 9216 MB) |
2.25 GB | 1.50 GB | 1.50 GB | - | |
| 12 GB (9216 - 14336 MB) |
3.25 GB | 1.75 GB | 1.75 GB | - | |
| 16 GB (14336 - 18432 MB) |
4.25 GB | 2.00 GB | 2.00 GB | - | |
| 16 GB + (超過 18432 MB) |
- | - | - | - | |
| 點陣圖記憶體用量 | - | - | 200 MB | 200 MB | 400 MB |
遊戲
|
不良行為門檻 為提高應用程式/遊戲在 Google Play 上的能見度，請注意不要超過這些門檻。 |
|||||
|---|---|---|---|---|---|
| 實體 RAM (記憶體總量範圍) |
應用程式狀態 | ||||
| 前景 | 使用者感知服務 | 背景 | 快取 | ||
| 記憶體用量 (匿名 RSS + 交換空間) | 0 到 4 GB (0 到 3200 MB) |
- | - | - | - |
| 4 GB (3200 - 4800 MB) |
2.25 GB | 2.00 GB | 2.00 GB | - | |
| 6 GB (4800 - 6800 MB) |
2.75 GB | 2.50 GB | 2.50 GB | - | |
| 8 GB (6800 - 9216 MB) |
3.50 GB | 2.75 GB | 2.75 GB | - | |
| 12 GB (9216 - 14336 MB) |
4.00 GB | 3.20 GB | 3.20 GB | - | |
| 16 GB (14336 - 18432 MB) |
5.00 GB | 3.50 GB | 3.50 GB | - | |
| 16 GB + (超過 18432 MB) |
- | - | - | - | |
| 點陣圖記憶體用量 | - | - | 200 MB | 200 MB | 400 MB |
DEX 程式碼最佳化
|
不良行為門檻
為提高應用程式/遊戲在 Google Play 上的能見度，請注意不要超過這些門檻。 |
||
|---|---|---|
| 條件 | 規定 | 最低門檻 |
| DEX 程式碼超過 10 MB 的應用程式 | 最佳化、模糊處理和縮減 | 25% |
| DEX 程式碼大於 50 MB 的遊戲 | 最佳化、模糊處理和縮減 | 25% |
核心指標對應用程式/遊戲在 Google Play 上的能見度有何影響？
如果應用程式或遊戲超出不良行為門檻，Play 可能就會減少顯示該應用程式/遊戲。Play 也可能會在商店資訊中向使用者顯示警告訊息。
每部裝置的不良行為和整體不良行為可能同時出現嗎？還是兩者只會擇一出現？如果同時出現該怎麼辦？
是的，上述情況都有可能發生。如要提升應用程式品質，請修正影響最多使用者的當機和 ANR 問題。如要提升特定裝置的品質，請修正這些裝置上最大的當機和 ANR 群組。如果兩者都有，請先著重於整體上最大的當機和 ANR 叢集。
我在修正技術問題方面需要協助，該從何著手？
我們提供下列資源，協助您診斷及修正應用程式或遊戲中的技術問題。
核心指標：
使用者感知 ANR 事件的發生率
使用者感知當機率
電池用量過高
部分 Wake Lock 過多
記憶體用量 (匿名 RSS + 交換空間)
點陣圖記憶體用量
所有其他指標：
喚醒次數過多
部分 Wake Lock 停滯
背景 Wi-Fi 掃描次數過多
背景網路用量過大
應用程式啟動時間
轉譯速度緩慢
我不希望因發生惡意行為或收到商店資訊警告而感到不知所措，該如何避免遇到此情況？
Play 會根據過去 28 天的資料評估應用程式品質。 Android Vitals 會針對這段期間發生的所有問題向您發出警告。
- 請定期檢查使用者介面，或是使用報表 API 將資料整合進工作流程中。
- 在 Play 管理中心設定問題電子郵件快訊。
- Android Vitals 會標示「新出現的問題」，也就是當機和 ANR 問題影響裝置超過 7 天。您有 21 天的時間解決問題。
我有許多裝置出現不良行為，該如何解讀這份清單？
有時，裝置硬體或軟體問題會導致錯誤率偏高。Android 系統健康狀態會提醒您，高錯誤率可能與 RAM、Android 版本和處理器類型等因素有關。您也可以在 Play 管理中心的「觸及率和裝置」中自行調查這些連結。
Android Vitals 也提供主要裝置資訊的快速存取權，例如使用者人數、收益、評分和評論。這項資訊會顯示在側邊面板中，因此您不必離開目前瀏覽的頁面。
修正裝置問題後，要等多久才不會再看到警告？
Google Play 每天會檢查應用程式的主要成效指標，並使用 28 天的平均值。 這個平均值改善後，Android Vitals 警告就會消失。如果 Play 系統偵測到改善情況，商店資訊警告可能會提前移除。
如果無法修正問題或不想修正問題，會怎麼樣？
請務必考量持續提供不佳的使用者體驗，會對成本和商機造成哪些影響。不良行為會傷害現有使用者，並讓您更難吸引新使用者。如果無法修正特定裝置的問題，請重新考慮指定裝置和排除規則。
為什麼 Android Vitals 中的問題數和發生率，與我或其他第三方解決方案中的相應項目不符？
Android Vitals 是 Play 評估應用程式技術品質的主要來源。問題數和發生率在 Android Vitals 和其他來源中可能會有落差，原因包括以下幾點：
- Android Vitals 資料來自 Android 系統，包含 SDK 無法查看的事件，例如：
- SDK 初始化前發生當機
- Android 12 之前的 ANR 錯誤
- Android Vitals 只會採計認證裝置回報的問題，以及從 Google Play 安裝的應用程式所發生的問題。
- Android Vitals 只會使用同意分享資料的使用者資料。
- 為保護使用者隱私，只有在資料量足以產生匿名報表時，我們才會顯示資料。
- 問題發生率的計算方式可能不同。Android Vitals 會顯示每位每日活躍使用者的問題。
- 舉例來說，Crashlytics 會計算每個應用程式工作階段的問題數量。假設使用者在一天內玩了遊戲三次，並遇到一次當機事件，Android Vitals 顯示的當機率將是 100%，而 Crashlytics 顯示的當機率則會是 33%。
如要進一步瞭解資料收集方式，請參閱 Play 管理中心說明中心。
我可以在 IDE 中查看 ANR 和當機深入分析嗎？
可以。在 Android Studio Meerkat 中查看 App Quality Insights 報表時，按一下「洞察」分頁標籤即可。Gemini 會提供當機摘要、生成洞察資訊，並連結至實用說明文件。如果同時允許 Gemini 存取本機程式碼背景資訊，Gemini 就能提供更準確的結果、相關後續步驟和程式碼建議。這有助於縮短診斷及解決問題的時間。 詳情請參閱 Android Studio 說明文件。
什麼是使用者工作階段？工作階段何時開始和結束？
使用者工作階段是指 24 小時內發生的使用活動總和。所有收集到的 Android Vitals 指標，都是以太平洋時間 (PT) 午夜為 24 小時週期的起點。如果當天沒有記錄到應用程式的使用活動，系統就不會記錄工作階段。