编辑说明

本文位于CodeProject的赞助商的产品展示部分。这些文章旨在为您提供我们认为有用且对开发人员有价值的产品和服务的信息。

对于应用程序开发人员而言，没有比快乐用户更好的衡量标准，最好是很多用户。实现这一目标的最佳方法是拥有一个人们想要使用的优秀应用程序，但“伟大”是什么意思呢？它归结为两件事：功能和应用程序质量。虽然前者最终取决于您的创造力和选择的商业模式，但后者可以客观地衡量和改进。

在去年进行的Google内部研究中，我们查看了Play商店的一星评价，发现超过40％的人认为应用稳定性是一个问题。相反，人们会不断奖励效果最好的应用，并提供更好的评​​分和评价。这样可以在Google Play上获得更好的排名，这有助于增加安装量。不仅如此，用户仍然更加投入，并愿意花更多的时间和金钱在这些应用程序中。

因此，解决应用程序的稳定性问题会对其成功率产生重大影响。

为了提供客观的质量衡量标准，您可以轻松发现应用程序需要解决的稳定性问题，我们在Play控制台中添加了一个名为Android vitals的新部分。本节将介绍应用程序中的性能和稳定性问题，而无需在代码中添加工具或库。Android vitals收集有关应用程序性能的匿名指标，而您的应用程序可在无数设备上运行。它为您提供了可能难以获得的信息，即使在使用硬件实验室进行测试时也是如此。

Android vitals可以提醒您的问题包括崩溃，应用程序无响应（ANR）和渲染时间。这些问题都会直接影响用户的体验和对应用的看法。然后有一类糟糕的应用程序行为，用户可能无法直接与您的应用程序关联：那些耗尽电池的速度比预期的要快。

在本文中，我将介绍其中两个问题：

• 过度的醒来。这些会影响电池寿命，并且如果用户无法及时到达充电器，则会剥夺用户的设备。这种行为可能会让用户迅速卸载您的应用。
• 应用程序无响应（ANR）事件。当应用程序的UI冻结时，这些事件会记录下来。当冻结发生时，如果您的应用程序位于前台，则会出现一个对话框，让用户有机会关闭应用程序或等待应用程序响应。从用户的角度来看，这种行为与应用程序崩溃一样糟糕。用户可能无法立即卸载您的应用，但如果ANR持续存在，则用户很可能会寻找替代应用。

过度的醒来

那么，什么是唤醒，什么时候变得过度？

为延长电池寿命，屏幕关闭后，Android设备会通过禁用主CPU核心进入深度睡眠模式。除非用户唤醒设备，否则设备应尽可能长时间保持此状态。但是，有些事件在唤醒CPU并提醒用户时很重要 - 例如，当警报响起或新的聊天消息到达时。这些警报可以通过唤醒警报来处理，但正如我将解释的那样，不必如此。到目前为止，唤醒似乎是一件好事，将重要事件带给用户注意，但其中太多和电池寿命都受到影响。

Android vitals如何显示过多的唤醒？

了解您的应用是否会带来太多的唤醒功能，这就是Android vitals的用武之地。收集的有关您应用行为的匿名数据用于显示自设备充满电后每小时经历超过10次唤醒的用户百分比。要寻找的关键是红色图标; 此图标表示您的应用已超出不良行为阈值。此阈值表示您的应用是Google Play中性能较差的应用之一，您应该着眼于改善其行为。

是否有唤醒警报的替代方案？

在给定时间或间隔后唤醒设备的主要方法是使用AlarmManager API使用RTC_WAKEUP或ELAPSED_REALTIME_WAKEUP标志调度警报。重要的是要谨慎使用此功能，并且仅在其他调度和通知机制无法提供更好服务的情况下使用。当您考虑使用唤醒警报时，需要考虑以下事项：

• 如果您需要显示信息以响应来自网络的数据，请考虑通过实施Firebase云消息传递来使用推送消息。使用此机制，您的应用只会在需要时被唤醒，而不是定期轮询新数据。
• 如果您不能使用推送消息并依赖定期轮询，请考虑使用JobScheduler或Firebase JobDispatcher（甚至是SyncManager用于帐户数据）。这些是比AlarmManager更高级的API，并为更智能的作业调度提供以下好处：
  • 批处理 - 而不是多次唤醒系统来运行作业，许多作业将被批量处理，让设备长时间睡眠。
  • 标准 - 您可以指定运行工作时必须满足的条件，例如网络可用性或电池充电状态。使用标准可以避免唤醒设备并不必要地运行您的应用程序。
  • 持久性和自动后退作业可以持久化（即使在重新启动时），并且在发生故障时将自动重试。
  • 只有打盹模式或应用程序待机没有限制时，才会运行打盹兼容性作业。

只有当推送消息和作业调度不适合您的工作时，您是否应该使用AlarmManager来安排唤醒警报。或者从另一个角度来看，只有在需要在特定时间启动警报时才需要唤醒警报，无论网络或其他条件如何。

当Android vitals显示出过多的唤醒时你应该怎么做？

要解决过多的唤醒问题，请确定应用安排唤醒警报的位置，然后降低触发警报的频率。

要确定应用程序在何处安排唤醒警报，请在Android Studio中打开AlarmManager类，右键单击RTC_WAKEUP或ELAPSED_REALTIME_WAKEUP字段，然后选择“查找用法”。这将显示项目中这些标志的所有实例。检查每一个，看看是否可以切换到更智能的作业调度机制之一。

您还可以在“查找用法”选项中将范围设置为“项目和库”，以确定您的依赖项是否正在使用AlarmManager API。如果是，您应该考虑使用替代库或向作者报告问题。

如果您决定必须使用唤醒警报，则如果您提供以下警报标记，Play Console会提供更好的分析数据：

• 在警报的标签名称中包含您的包裹，类别或方法名称。这也可以帮助您轻松识别源中警报的设置位置。
• 不要将Class＃getName（）用于警报名称，因为它可能会被Proguard混淆。请改用硬编码字符串。
• 不要将计数器或其他唯一标识符添加到警报标记，因为系统可能会删除标记，并且无法将它们聚合为有用的数据。

应用程序无响应

那么，什么是应用程序无响应（ANR）以及它如何影响用户？

对于用户而言，ANR是他们尝试与您的应用进行交互的事件，但该界面已被冻结。在界面保持冻结几秒钟后，将显示一个对话框，让用户可以选择等待或强制退出应用程序。

从应用程序开发的角度来看，当应用程序通过执行长操作（例如磁盘或网络I / O）来阻止主线程时，就会发生ANR。主线程（有时称为UI线程）负责响应用户事件并刷新屏幕上每秒60次绘制的内容。因此，任何可能延迟其工作的操作都会转移到后台线程，这一点至关重要。

Android vitals如何显示ANR？

使用收集的有关您应用的ANR事件的匿名数据，Android vitals提供了有关ANR的几个级别的详细信息。主屏幕显示应用中ANR活动的摘要。这显示了用户至少经历过一次ANR的每日会话百分比，以及过去30天和之前30天的单独报告。还提供了不良行为阈值。

详细信息视图（ANR费率页面）显示ANR费率随时间变化的详细信息，以及应用版本，活动名称，ANR类型和Android版本的ANR。您可以按APK版本代码，支持的设备，操作系统版本和句点过滤此数据。

您还可以从ANR和崩溃部分获取更多详细信息。

ANR的常见原因是什么？

如前所述，当app进程阻塞主线程时会发生ANR。几乎任何原因都可能发生阻塞，但最常见的原因包括：

• 执行磁盘或网络I / O的主线程上。这是迄今为止ANR最常见的原因。虽然大多数开发人员都同意您不应该在主线程上读取或写入数据到磁盘或网络，但有时候我们都很想做到这一点。从磁盘读取几个字节可能不会在理想条件下导致ANR，但这绝不是一个好主意。如果用户的闪存设备较慢，该怎么办？如果他们的设备处于同时读写的其他应用程序的极大压力下，而您的应用程序在队列中等待执行“快速”读取操作，该怎么办？切勿在主线程上执行I / O.
• 在主线程上执行长计算。那么内存计算呢？RAM不会受到长访问时间的影响，较小的操作应该没问题。但是，当您开始在循环中执行复杂计算或使用大型数据集时，您可以轻松地阻止主线程。考虑使用数百万像素调整大图像的大小，或者解析大块HTML文本然后在TextView中显示。通常，您的应用最好在后台运行此类操作。
• 从主线程运行同步绑定器调用另一个进程。与磁盘或网络操作类似，当跨进程边界进行阻塞调用时，程序执行将传递到您无法控制的某个位置。如果其他进程繁忙怎么办？如果需要访问磁盘或网络以响应您的请求怎么办？此外，数据需要被分区和未分组以传递给其他进程，这需要时间。最好从后台线程进行进程间调用。
• 使用同步。即使将繁重的操作移动到后台线程，也需要与主线程通信以显示进度或计算结果。多线程编程并不容易，当使用同步进行锁定时，通常很难确保不会阻止执行。在最坏的情况下，它甚至可能导致一个死锁，在这个死锁中你的线程永远等待彼此阻塞。最好避免自己设计同步，最好使用专门构建的解决方案（如Handler）将不可变数据从后台线程传递回主线程。

如何检测ANR的原因？

找到ANR的原因可能很棘手，以URL类为例。您是否期望URL＃equals（用于确定两个URL是否相同的方法）被阻止？那么SharedPreferences呢？如果你在后台读取它的值，你可以在主线程上调用getSharedPreferences吗？在这两种情况下，答案都是这些可能是长期阻塞操作。

幸运的是，StrictMode可以避免发现ANR的猜测。在调试版本中使用此工具可以捕获主线程上的意外磁盘和网络访问。在应用程序启动时使用StrictMode＃setThreadPolicy来自定义要检测的内容，包括磁盘和网络I / O，甚至是通过StrictMode＃noteSlowCall在应用程序中触发的自定义慢速调用。您还可以选择StrictMode在检测到阻止调用时如何提醒您：通过崩溃应用程序，或记录或显示对话框。有关更多详细信息，请参阅ThreadPolicy.Builder类。

一旦消除了主线程上的阻塞调用，请记住在将应用程序发布到Play商店之前关闭StrictMode。

消除过多的唤醒和ANR将提高您的应用程序的质量和可用性，提高评级和评论，反过来，更多的安装。通过检查Android vitals，您可以快速轻松地找出是否存在需要解决的问题。在代码中查找和解决这些问题并不总是那么简单，但是有一些工具和技术可以用来有效地完成工作。

Android vitals可以为您提供更多帮助，我将在下一篇文章中介绍更多这些功能。此外，与同事Fergus Hurley和Joel Newman一起，我将参加Google I / O 2018，在5月8日星期二下午3点举行会议“Android vitals：调试应用程序性能并获得奖励”。如果您在那里或通过直播加入我们，了解有关Android vitals，最新Play控制台和Android Studio工具的更多信息，以及帮助您提高应用质量的见解。

如果你有关于Android vitals的想法，请通过使用#AskPlayDev的推文告诉我们，我们将回复@GooglePlayDev，我们会定期分享有关如何在Google Play上取得成功的新闻和提示。