有关应用质量问题的新数据洞见和建议
目前，系统会显示应用兼容性问题、不良行为和一些用户体验建议。在未来一年里，我们将继续检测和显示更多质量问题，并提供更多建议。
Android Vitals 可帮助您了解和改善应用的稳定性、性能、电池用量等方面。
选择如何访问应用数据
使用 Android Vitals 的方式有以下两种：通过 Play 管理中心使用，以及通过 Play Developer Reporting API 使用。
如果开发者希望将 Android Vitals 数据与其他数据集集成，或将其内置到工作流中，可借助该 API 以编程方式访问 Android Vitals。如需详细了解如何使用 API 访问 Android Vitals，请前往 Google Play Developer Reporting API 页面。
如需在 Play 管理中心内查找和查看应用的 Android Vitals 数据，请按以下步骤操作：
- 打开 Play 管理中心，然后前往 Android Vitals 概览页面（质量 > Android Vitals > 概览）。
- 使用右上角的日期范围选择器选择您要查看的数据范围。
重要提示：如果没有可显示的数据，则表示应用在特定过滤条件下没有足够的数据点，无法找出任何问题。
监控应用的 Android Vitals 核心指标
在 Android Vitals 概览页面顶部，您可以看到应用的 Android Vitals 核心指标的相关数据。这些指标是最重要的技术指标，会影响应用在 Google Play 中的曝光度。Android Vitals 核心指标包括：
Google Play 针对这些指标设定了不良行为阈值。如果您的应用超出这些阈值，其在 Google Play 上的曝光度可能会较低。在某些情况下，您可以在应用的商品详情中显示一条警告，为用户设定恰当的预期。
您可以使用“重要问题”部分快速找出应用有待改进的方面。有两种类型的重要问题：
- 不良行为：超出不良行为阈值的指标
- 异常值：数据的显著变化（例如，用户感知的 ANR 发生率急剧上升）
如需接收电子邮件通知，请依次访问设置 > 通知，或点击位于“Android Vitals 核心指标”部分（质量 > Android Vitals > 概览）一角的管理通知。请注意，目前仅针对异常值问题发送通知。
浏览所有 Android Vitals 指标在 Android Vitals 概览页面中间附近，您可以按质量查看所有 Android Vitals 指标的数据。
在表格中，您可以查看当前时间段和之前时间段的指标。您还可以查看您的应用与 Google Play 上其他应用的对比情况。
如需了解有关某项指标的其他详细信息，请选择该指标旁边的查看详情 ()。您可以在下一界面中查看以下信息：
- 不良行为阈值
- 类别基准
- 与基准的详细对比情况
- 在页面顶部附近的类似应用对比情况卡片中，选择修改类似应用群组，以修改自定义类似应用群组。创建自定义类似应用群组后，您可以查看自己的应用与所选的其他 Google Play 应用的对比情况。
- 指标变化趋势
指标会按多种不同的维度进行细分，以便您整理、细分和分析数据。所有指标都具有以下细分维度：
- 制品：出现问题的应用版本
- Android 版本 (SDK)：通过用户设备报告的 Android 操作系统版本
- 设备规格：运行相应应用的设备所属的类型（例如手机、平板电脑、电视、穿戴式设备）
- 设备型号：设备的简要说明，包括唯一性的品牌和设备标识信息，例如“Google oriole”。单个设备型号可能会有多个搭载不同 Android 版本、RAM、存储空间或系统芯片 (SoC) 的规格。
- 国家/地区：问题发生时用户设备报告的位置
提示：如需按设备硬件或软件的特定方面（例如设备型号或 Android 版本）进行细分，您可以点击表格中相应项旁边的符号 ()。
部分指标具有其他细分维度：
- 唤醒锁定名称：在应用中使用 PowerManager API 时，以编程方式设置的标记
- 唤醒名称：在应用中使用 AlarmManager API 时，以编程方式设置的标记
- ANR activity 名称：发生 ANR 的 activity 类的完全限定名称（如有）
- ANR 类型：发生 ANR 的时间，例如在执行服务时（如有）
如果有更多详细信息（例如与相应细分维度相关联的崩溃或 ANR 集合），您可以进行查看，具体方法是选择相应项旁边的查看详情 ()。
提示：您可以使用屏幕顶部的切换开关在单个类别下的指标之间切换，然后过滤页面。
数据类型和指标
您可以在 Play 管理中心内查看过去 90 天的 Android Vitals 数据，以及通过 Play Developer Reporting API 查看过去 3 年的 Android Vitals 数据。
数据是从用户选择了自动分享使用情况和诊断数据的设备收集而来，它们只代表部分 Android 设备和操作系统版本上的数据。如需详细了解 Android 用户选择分享数据的方式，请转到账号帮助中心。
Android Vitals 每天更新一次。有时，搭载 Android 10 及以上版本的设备的数据会比搭载 Android 10 以下版本的设备的数据先送达。在这种情况下，您会看到 Android 10+ 数据仅在该数据可用的天数内显示。
注意：Android Vitals 指标不会统计未经认证的设备型号上发生的技术问题，以及未通过 Google Play 安装的应用版本中发生的技术问题。
稳定性
ANR 发生率指标ANR 发生率指标可让您大致了解应用的质量。这类指标的计算方式如下：统计遇到过 ANR 的用户数，然后根据应用的使用情况对其进行归一化处理。这类指标以日活跃用户所占百分比的形式报告，其中“日活跃用户”是指在一天中通过单台设备使用应用的用户。如果一位用户在一天中通过多台设备使用您的应用，则系统会针对每台设备统计这一天的活跃用户数。如果多位用户在一天中使用同一台设备，系统会将其统计为一位活跃用户。
有三种 ANR 发生率指标：
- 用户感知的 ANR 发生率：遇到过至少 1 次用户感知的 ANR 的日活跃用户所占的百分比。“用户感知的 ANR”是指可能已被用户注意到的 ANR。目前，系统仅会统计“输入调度超时”ANR。该指标会始终低于总体 ANR 发生率，因为它会按每日使用情况进行归一化处理，而不是统计所有 ANR。
“用户感知的 ANR 发生率”是 Android Vitals 核心指标，也就是说，它会影响您的应用在 Google Play 上的曝光度。此指标很重要，因为在用户与应用互动时，它统计的 ANR 错误总是会发生，造成最严重的中断。
- ANR 发生率：遇到过至少 1 次 ANR 的每日用户所占的百分比。此指标包括未归类为“用户感知”的 ANR，但我们无法保证这些 ANR 不会影响用户。
- 多次 ANR 发生率：遇到过至少 2 次 ANR 的每日用户所占的百分比。此指标有助于突出问题循环。
解决问题
计入 ANR 发生率指标中的 ANR 会在崩溃和 ANR 页面上报告。您可以在此页面上过滤出用户感知的 ANR。
Android 开发者网站提供了诊断和解决 ANR 错误的指南。
崩溃率指标可让您大致了解应用的质量。这类指标的计算方式如下：统计您拥有的遇到过崩溃的用户数，然后根据应用的使用情况对其进行归一化处理。这类指标以每日用户所占百分比的形式报告，其中“每日用户”是指在一天中通过单台设备使用应用的用户。如果某位用户拥有多台设备，系统将会多次统计该用户。例如，如果两位用户各自在一台设备上使用该应用两天，系统会记录四个活跃日。
有三种崩溃率指标：
- 用户感知崩溃率：遇到过至少 1 次用户感知的崩溃的每日用户所占的百分比。“用户感知的崩溃”是指可能已被用户注意到的崩溃。例如，当您的应用正在显示 activity 或作为前台服务运行时发生的崩溃。该指标会始终低于总体崩溃率，因为它会按每日使用情况进行归一化处理，但并未统计所有崩溃。
“用户感知崩溃率”是 Android Vitals 核心指标，也就是说，它会影响您的应用在 Google Play 上的曝光度。此指标很重要，因为在用户与应用互动时，它统计的崩溃问题总是会发生，造成最严重的中断。因此，您应确保您的应用不会超出此指标的不良行为阈值。
-
崩溃率：遇到过至少 1 次崩溃的每日用户所占的百分比。此指标包括未归类为“用户感知”的崩溃，但我们无法保证这些崩溃不会影响用户。
-
多次崩溃率：遇到过至少 2 次崩溃的每日用户所占的百分比。此指标有助于突出问题循环。
解决问题
Android 开发者网站提供了诊断和解决崩溃问题的指南。
启动时间和加载时间
启动时间（初步显示所用时间）如果您的应用从冷、温和热这三种系统状态下启动较慢，则您在启动时间页面上可以看到相关详细信息。“启动时间”衡量的是从用户启动您的应用，到起初的几帧画面显示在屏幕上所需的时间。这也称为“初步显示所用时间”。
此时间过后您的应用可能还未准备好与用户开始互动。例如，如果您的应用还有其他加载画面，就可能会出现这种情况。
数据收集详情
- 系统只会在用户触发 activity 时记录启动时间。
- 示例：键盘应用的启动时间等于配套应用的启动时间。
- 如果应用在同一天内多次从同一系统状态下启动，则系统会记录当天最长的启动时间。
- 当应用的第一帧完全加载，系统就会跟踪应用的启动时间，即使用户不会与该屏幕互动，也不例外。
- 示例：如果应用开启时会显示启动画面，则启动时间就等于显示启动画面所需的时间。
Vitals 单项详细信息
- 受影响的会话数：用户在各个系统状态下遇到启动时间过长问题的会话所占的百分比：
- 冷启动时间过长：5 秒或更长
- 温启动时间过长：2 秒或更长
- 热启动时间过长：1 秒或更长
- 会话数：系统已记录的会话的大概数量。
- 第 90/99 个百分位：10%/1% 的活跃日中，用户在您的应用中遇到启动时间过长的问题。
解决问题
如果您的应用经常出现启动时间过长的问题，请转到 Android 开发者网站，了解我们推荐的解决方案。
呈现
呈现的所有帧
慢会话比率（30 FPS 或 20 FPS）[仅限游戏]重要意义
通过慢会话，您可以了解游戏的帧速率性能，帧速率会影响游戏带给用户的流畅感。
了解应用的数据
在“慢会话”页面上，您可以查看存在以下情况的活跃日所占百分比的详细信息：用户遇到超过 25% 的帧运行速度低于 30 FPS 或 20 FPS（具体取决于您选择的基准）。您还可以按帧速率查看游戏的会话分布情况。（会话级帧速率是按第 75 个百分位测量的，即 75% 的帧至少达到此帧速率。）
Google Play 上的大多数游戏都应以 30 FPS 或更高帧速率为目标水平。这样无论用户玩什么类型的游戏，都能获得适当的体验（不过有些用户更希望帧速率能至少达到 60 FPS，尤其是使用高端设备的用户）。您应监控慢会话比率 (30 FPS) 指标，以确保应用能够达到此水准。请注意，该指标仅涵盖超过 25% 的帧达不到 30 FPS 的会话，因此可容许一定程度的帧速率不稳定性。
尽管 30 FPS 可以提供适当的体验，但对于某些情况或某些类型的游戏，适合将帧速率降至低于 30 FPS 的水平；还有一种情况，用户玩游戏所用的手机也可能不支持 30 FPS。在这些情况下，会话中至少 75% 的帧仍应达到 20 FPS 或更高的帧速率。您应监控慢会话比率 (20 FPS) 指标，以确保应用能够达到此水准。
Android Vitals 会报告每台设备以及所有设备和会话的慢会话（30 FPS 和 20 FPS）。您可以通过总体指标来了解应用的整体用户体验，但也要关注应用在每款设备上的表现。Play 会在适当情况下减少展示帧速率在用户手机上无法达到 20 FPS 的游戏。
只有在游戏运行时间达到 1 分钟后，Vitals 才会开始监控帧速率。
数据收集详情
“慢会话”指标是根据从 SurfaceFlinger 收集的数据算出的。更确切地说，会话的帧速率是根据应用所拥有的 Surface 上绘制的帧的间隔时间估算的，其中包括由 OpenGL、Vulkan 以及 Android UI 工具包呈现的帧。该指标目前仅适用于游戏。
“慢会话”的帧速率数据是针对搭载 Android 9 及更高版本的设备而收集的。
信息中心显示内容
- 典型帧速率：游戏在搭载 Android 9 或更高版本的设备中的帧速率性能，按第 75 个百分位计算得出。这表示 75% 的会话有 75% 的时间达到或超过这一帧速率。
- 慢会话比率随时间的变化趋势：显示被确定为慢会话的会话所占百分比的时间序列。
- 帧速率分布：显示各会话的第 75 个百分位帧速率的直方图。也就是说，会话中有 75% 的帧超过用于定义会话区间的帧速率。
解决问题
如果您的应用有大量慢会话，请前往 Android 开发者网站，了解我们推荐的解决方案。
Android UI 工具包呈现
慢帧数过多[仅限应用]了解应用的数据
在“呈现速度缓慢的帧数过多”页面上，您可以查看存在以下情况的活跃日所占百分比的详细信息：用户遇到超过 50% 的帧未在设备的呈现时限内呈现。用户与应用的互动速度应该保持在 60 帧/秒，并且不会出现帧丢失或帧延迟的情况。
数据收集详情
Google 会收集您的应用使用 UI 工具包框架呈现帧时各个帧的呈现时间，但不会收集直接使用 OpenGL 或 Vulkan 呈现的帧的相关数据。
信息中心显示内容
在您选择某行后，系统会显示细分为百分位的数据。
- 受影响的会话数：以下活跃日所占的百分比：用户遇到超过 50% 的帧的呈现时间超过 16 毫秒。如果用户在一天内使用过您的应用，当天即计为一个活跃日。例如，如果有两位用户使用该应用两天，系统会记录四个活跃日。
- 会话数：系统已记录的会话的大概数量。
- 第 90/99 个百分位：所有帧中有 90%/99% 的帧呈现时间低于显示的数字。这些数字是根据系统收集的所有帧计算得出的。
如果您点击表中的条目，将会看到“界面呈现时间分布图”图表。在查看该图表时，您需要确保应用的大多数帧的呈现时间都不超过 16 毫秒。
图表下方的数据展示了该应用的呈现效果，可能有助于您发现所有呈现时间问题的根本原因。例如，如果“输入延迟时间长”百分比较高，您可能需要查看处理用户输入的应用代码。如需详细了解这些指标，请参阅测试界面性能。
- 错过 Vsync 事件：对于所有呈现时间超过 16 毫秒的帧，以错过的 Vsync 事件数除以帧数。
- 输入延迟时间长：对于所有呈现时间超过 16 毫秒的帧，以超过 24 毫秒的输入事件数除以帧数。
- 界面线程速度缓慢：对于所有呈现时间超过 16 毫秒的帧，以界面线程执行时间超过 8 毫秒的次数除以帧数。
- 绘图命令速度缓慢：对于所有呈现时间超过 16 毫秒的帧，以向 GPU 发送绘图命令的时间超过 12 毫秒的次数除以帧数。
- 位图上传速度缓慢：对于所有呈现时间超过 16 毫秒的帧，以位图上传到 GPU 的时间超过 3.2 毫秒的次数除以帧数。
解决问题
如果您的应用有大量帧的呈现时间超过 16 毫秒，请前往 Android 开发者网站，了解我们推荐的解决方案。
了解应用的数据
在“呈现速度缓慢的帧数过多”页面上，您可以查看存在以下情况的活跃日所占百分比的详细信息：用户遇到超过 50% 的帧未在设备的呈现时限内呈现。用户与应用的互动速度应该保持在 60 帧/秒，并且不会出现帧丢失或帧延迟的情况。
数据收集详情
Google 会收集您的应用使用 UI 工具包框架呈现帧时各个帧的呈现时间，但不会收集直接使用 OpenGL 或 Vulkan 呈现的帧的相关数据。
信息中心显示内容
在您选择某行后，系统会显示细分为百分位的数据。
- 受影响的会话数：以下活跃日所占的百分比：用户遇到超过 50% 的帧的呈现时间超过 16 毫秒。如果用户在一天内使用过您的应用，当天即计为一个活跃日。例如，如果有两位用户使用该应用两天，系统会记录四个活跃日。
- 会话数：系统已记录的会话的大概数量。
- 第 90/99 个百分位：所有帧中有 90%/99% 的帧呈现时间低于显示的数字。这些数字是根据系统收集的所有帧计算得出的。
如果您点击表中的条目，将会看到“界面呈现时间分布图”图表。在查看该图表时，您需要确保应用的大多数帧的呈现时间都不超过 16 毫秒。
图表下方的数据展示了该应用的呈现效果，可能有助于您发现所有呈现时间问题的根本原因。例如，如果“输入延迟时间长”百分比较高，您可能需要查看处理用户输入的应用代码。如需详细了解这些指标，请参阅测试界面性能。
- 错过 Vsync 事件：对于所有呈现时间超过 16 毫秒的帧，以错过的 Vsync 事件数除以帧数。
- 输入延迟时间长：对于所有呈现时间超过 16 毫秒的帧，以超过 24 毫秒的输入事件数除以帧数。
- 界面线程速度缓慢：对于所有呈现时间超过 16 毫秒的帧，以界面线程执行时间超过 8 毫秒的次数除以帧数。
- 绘图命令速度缓慢：对于所有呈现时间超过 16 毫秒的帧，以向 GPU 发送绘图命令的时间超过 12 毫秒的次数除以帧数。
- 位图上传速度缓慢：对于所有呈现时间超过 16 毫秒的帧，以位图上传到 GPU 的时间超过 3.2 毫秒的次数除以帧数。
解决问题
如果您的应用有大量帧的呈现时间超过 16 毫秒，请前往 Android 开发者网站，了解我们推荐的解决方案。
电池用量
唤醒锁定操作卡住与部分唤醒锁定被卡住（后台）部分唤醒锁定操作卡住页面和部分唤醒锁定操作卡住（后台）页面会显示通过应用的 PowerManager 类获取的部分唤醒锁定信息。部分唤醒锁定可确保 CPU 正常运行，但屏幕和键盘背光可以关闭。
数据收集详情
- 为了保护隐私，部分唤醒锁定识别标记已进行匿名化处理。
- 部分唤醒锁定的相关数据是系统在设备未充电且屏幕关闭时收集的。
- 只有当应用在后台运行的时候，系统才会收集“部分唤醒锁定操作卡住（后台）”的相关数据。
- Google 会计算每次电池工作时段的最长部分唤醒锁定持续时间，以显示受到长时间唤醒锁定影响的工作时段数。例如，如果用户触发两次 1 小时长的唤醒锁定，那么 Google 将使用的最大唤醒锁定值为 1 小时。
- 对于在清单文件中设置了
sharedUserId的应用：只有当最多安装了一个具有相同sharedUserId的应用时，您才会看到相关数据。
Vitals 单项详细信息
- 受影响的工作时段数：用户遇到至少 1 次长达 1 小时以上的唤醒锁定的电池工作时段数百分比。
- 会话数：系统已记录的会话的大概数量。
- 第 90/99 个百分位：10%/1% 的活跃日中用户遇到部分唤醒锁定持续时间高于显示的数字。
- 不良行为阈值：如果您的应用发生问题的比例等于或高于显示的阈值，系统会依据 Google Play 上前 1,000 个热门应用的安装量，将此应用归在这项指标最低的 25% 中。
解决问题
如果您的应用经常出现部分唤醒锁定被卡住错误，请转到 Android 开发者网站，了解我们推荐的解决方案。
唤醒次数过多页面会显示由应用触发的 Alarm Manager 唤醒次数。您会看到 ELAPSED_REALTIME_WAKEUP 或 RTC_WAKEUP 类的唤醒数据。
数据收集详情
- 为了保护隐私，唤醒识别标记已进行匿名化处理。
- 唤醒次数是系统在设备未充电时收集的。
- 为了提供标准化指标，系统会将唤醒次数与设备使用电池的时间进行比较。Google 会计算每个用户在每小时的唤醒次数，以显示受到高唤醒率影响的用户数。
- 对于在清单文件中设置了
sharedUserId的应用：只有当最多安装了一个具有相同sharedUserId的应用时，您才会看到相关数据。
Vitals 单项详细信息
- 受影响的会话数：用户遇到每小时 10 次以上唤醒的电池工作时段所占的百分比。电池工作时段是在给定的 24 小时内接收到的所有电池报告的汇总。对于搭载 Android 10 的设备，电池报告是指两次电池充电（从低于 20% 充到 80% 以上或者从任意电量值充满到 100%）之间的时间间隔。对于搭载 Android 11 及更高版本的设备，电池报告是指固定的 24 小时时间段。Google 仅会在设备未充电时收集这项数据。
- 会话数：系统已记录的会话的大概数量。
- 第 90/99 个百分位：10%/1% 的活跃日中用户每小时遇到唤醒次数高于显示的值。
- 不良行为阈值：如果您的应用发生问题的比例等于或高于显示的阈值，系统会依据 Google Play 上前 1,000 个热门应用的安装量，将此应用归在这项指标最低的 25% 中。
解决问题
如果您的应用频繁唤醒，请转到 Android 开发者网站，了解我们推荐的解决方案。
WLAN 扫描次数过多（后台）页面显示了 WLAN 扫描何时会导致电量消耗较高。
数据收集详情
WLAN 扫描的相关数据是系统在设备未充电以及应用在后台运行时收集的。
Vitals 单项详细信息
- 受影响的会话数：用户遇到每小时 4 次以上 Wi-Fi 扫描的电池工作时段所占的百分比。
- 会话数：系统已记录的会话的大概数量。
- 第 90/99 个百分位：10%/1% 的活跃日中用户每小时遇到的后台 Wi-Fi 扫描次数高于显示的数字。
解决问题
如果您的应用在后台进行 WLAN 扫描的次数较多，请前往 Android 开发者网站，了解我们推荐的解决方案。
网络使用量过高页面会显示何时有大量网络数据与后台服务相关联。当移动网络的使用发生在后台时，用户将难以控制和停止数据传输。
数据收集详情
移动网络使用量的相关数据是系统在设备未充电以及应用在后台运行时收集的。
Vitals 单项详细信息
- 受影响的会话数：用户遇到每日后台网络使用量超过 50 MB 的电池工作时段所占的百分比。
- 会话数：系统已记录的会话的大概数量。
- 第 90/99 个百分位：10%/1% 的活跃日中用户每日的后台网络使用量高于显示的数字。
解决问题
如果您的应用的后台网络使用量较高，请转到 Android 开发者网站，了解我们推荐的解决方案。
权限
权限遭拒权限遭拒页面会针对用户拒绝权限的情况，提供权限申请日所占百分比的详细信息。如果您的应用在一天内向用户请求过至少一项权限，该日即计为一个权限申请日。
数据收集详情
系统会在用户针对应用内的权限请求做出回应时，收集权限遭拒的数据。
Vitals 单项详细信息
- 遭拒：用户拒绝了权限的每日权限工作时段数百分比。
- 不再询问：用户通过选择“不再询问”选项拒绝了权限的权限申请日所占的百分比。
- 会话总数：系统已记录会话的大概数量。
解决问题
如果您的应用经常遇到权限遭拒的情况，请转到 Android 开发者网站，了解我们推荐的解决方案。
Android Vitals 核心指标的不良行为阈值
Google Play 针对您应用的 Android Vitals 核心指标设定了不良行为阈值。
如果您的应用超出不良行为阈值，它在 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 改善应用的性能和稳定性的最佳实践。