[译] 如何用 Android vitals 解决应用程序的质量问题

• 原文地址：How to fix app quality issues with Android vitals
• 原文做者：Wojtek Kaliciński
• 译文出自：掘金翻译计划
• 本文永久连接：github.com/xitu/gold-m…
• 译者：LeeSniper
• 校对者：DateBro

两篇中的第一篇：修复 ANR 事件和过分唤醒是如何提升应用在 Play Store 上的表现的

对于一个应用开发者来讲，没有比开心的用户更好的衡量成功的标准，并且最好是有不少这样的用户。实现这一目标的最佳方式是拥有一我的人都想用的优秀应用，不过咱们所说的“优秀”指的是什么呢？它能够归结为两件事：功能和应用质量。前者最终取决于你的创造力和选择的商业模式，然后者能够客观地衡量和改进。

在去年进行的一项 Google 内部研究中，咱们查看了 Play Store 中的一星评论，发现超过 40％ 的人提到应用稳定性的问题。相对的，人们会用更高的评分和更好的评论持续奖励那些表现最佳的应用。这使得它们在 Google Play 上得到更好的排名，而好的排名有助于提升安装量。不只如此，用户还会更加投入，并愿意在这些应用程序上花费更多的时间和金钱。

所以，解决应用程序的稳定性问题能够在很大程度上决定它有多成功。

为了提供一个客观的质量衡量标准，使你能够轻松发现应用须要解决哪些稳定性问题，咱们在 Play Console 中添加了一个名为 Android vitals 的新模块。这个模块能够告诉你应用程序的性能和稳定性问题，而不须要在代码中添加仪器或库。当你的应用程序运行在众多设备上的时候，Android vitals 会收集关于应用程序性能的匿名指标。即便在使用硬件实验室进行测试时，它也会以其余方式难以得到的规模为你提供信息。

Android vitals 能够提醒你的问题包括崩溃、应用程序无响应（ANR）和渲染时间。这些问题都直接影响你的用户对应用的体验和见解。此外，还有一类用户可能不会直接与你的应用关联的不良应用行为：好比耗电的速度比预期的要快。

在本文中，我将着眼于如下两个问题：

• 过分唤醒。这会影响电池的续航时间，若是用户没法及时充电，可能会致使他们没法使用设备。这种行为极可能会让用户迅速卸载你的应用。
• 应用程序无响应（ANR）事件。这些事件发生在你的应用程序 UI 冻结的时候。发生冻结时，若是你的应用位于前台，会弹出对话框让用户选择关闭应用或等待响应。从用户的角度来看，这种行为与应用崩溃同样糟糕。用户可能不会当即卸载你的应用，但若是 ANR 持续存在，用户极可能会寻找替代的应用。

过分唤醒

那么，唤醒是什么以及它们什么时候变得过分呢？

为了延长电池的续航时间，屏幕关闭后，Android 设备将经过禁用主 CPU 内核进入深度睡眠模式。除非用户唤醒设备，不然设备会尽量长时间地保持在此状态。可是，有一些重要事件须要唤醒 CPU 并提醒用户，例如，当闹钟响起或有新的聊天消息到达时。这些警报能够经过唤醒警报（wakeup alarm）来处理，但正如我将要解释的那样，这并非必须的。到目前为止，唤醒彷佛是一件好事，它能够显示重要的事件引发用户的注意，可是若是有太多这种事件那么电池寿命就会受到影响。

Android vitals 如何显示过分唤醒？

了解你的应用是否在驱动过多的唤醒是 Android vitals 的重要任务。收集的有关你应用行为的匿名数据用于显示自设备彻底充电后，每小时经历超过 10 次唤醒的用户的百分比。要查看的关键点是一个红色的图标；这个图标告诉你，你的应用已超出不良行为阈值。而这个阈值表示你的应用属于 Google Play 上表现较差的应用，你应该考虑改善其行为。

唤醒警报是否有其余替代方法？

在指定时间或间隔后唤醒设备的主要方法是使用 AlarmManager API 的 RTC_WAKEUP 或 ELAPSED_REALTIME_WAKEUP 标志来安排警报。可是必定要注意谨慎地使用此功能，并且只有在其余调度和通知机制不能更好地提供服务的状况下。当你想要使用唤醒警报时，请注意考虑如下几点：

• 若是你须要根据网络返回的数据来显示信息，能够考虑使用消息推送来实现，例如 Firebase Cloud Messaging。使用这种机制而不是按期拉取新数据，你的应用只有在须要时才会被唤醒。

• 若是你没法使用消息推送而且依赖按期拉取，能够考虑使用 JobScheduler 或者是 Firebase JobDispatcher（甚至是 SyncManager 来获取账户数据）。这些是比 AlarmManager 更高级别的 API，并且为更智能的按期任务提供如下好处：

  A） 批处理 —— 许多任务将被批量处理以使设备睡眠时间更长，而不是屡次唤醒系统来执行这些任务。

  B） 条件 —— 你能够指定必须知足某些条件才能执行你的任务，例如网络可用性或电池的充电状态。使用这些条件能够避免没必要要的设备唤醒和应用运行。

  C） 持续性和自动重试 —— 任务能够持续执行（即便从新启动也能够），而且能够在发生故障时自动重试。

  D） Doze 兼容性 —— 任务只有在不受 Doze 模式限制或应用程序待机时才会执行。

只有当消息推送和按期任务不适合你的工做时，你才应该使用 AlarmManager 安排唤醒警报。或者从另外一个角度来看，只有当你须要在特定时间启动闹钟时才须要使用唤醒警报，不管网络或其余条件如何。

Android vitals 显示过分唤醒时你应该怎么作？

要解决过分唤醒的问题，请先肯定你的应用在哪些地方设置了唤醒警报，而后下降触发这些警报的频率。

要肯定你的应用在哪些地方设置了唤醒警报，请在 Android Studio 中打开 AlarmManager 类，右键单击 RTC_WAKEUP 或 ELAPSED_REALTIME_WAKEUP 字段并选择 “Find Usages”。这将显示你项目中用到这些标志的全部实例。审查每个实例，看看你是否能够切换到更智能的定时任务机制中的一种。

你还能够在 Find Usages 选项中将范围设置为“项目和库”，以肯定你的依赖库是否使用了 AlarmManager API。若是是，你应该考虑使用替代库或向做者报告这个问题。

若是你决定必须使用唤醒警报，那么若是你提供了符合如下要求的警报标签，则 Play Console 能够提供更好的分析数据：

• 在你的警报标签名称中包含你的包名、类名或方法名。这也能够帮助你轻松识别警报设置在你源码中的什么位置。
• 请勿使用 Class#getName() 做为警报名称，由于它可能会被 Proguard 混淆。改用硬编码的字符串。
• 不要将计数器或其余惟一标识符添加到警报标签，由于系统可能会丢弃标签，并且没法将它们聚合成有用的数据。

应用程序无响应

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

对于用户来讲，ANR 是当他们尝试与你的应用进行交互时，该界面被冻结。界面保持冻结几秒钟后，会显示一个对话框，让用户选择等待或强制应用程序退出。

从应用程序开发的角度来看，当应用程序由于执行耗时操做（如磁盘或网络读写）阻塞主线程时，就会发生 ANR。主线程（有时称为 UI 线程）负责响应用户事件并刷新屏幕上每秒绘制六十次的内容。所以，将任何可能延迟其工做的操做都转移到后台线程是相当重要的。

Android vitals 如何显示 ANR？

使用收集到的有关你应用 ANR 事件的匿名数据，Android vitals 提供了有关 ANR 的多个级别的详细信息。主屏幕显示你应用程序中发生 ANR 的 Activity 的概况。这显示了用户经历过至少一次 ANR 的每日会话的百分比，以及以前最近 30 天的单独报告。还提供了不良行为的阈值。

详细信息视图的 ANR 比例页面显示了 ANR 比例随时间变化的详细信息，以及按应用版本、Activity 名称、ANR 类型和 Android 版本显示的 ANR 信息。你能够经过 APK 版本号、支持的设备、操做系统版本和时间段来过滤这些数据。

你还能够从 ANRs & crashes 部分获取更多详细信息。

ANR 的常见缘由是什么？

如前所述，当应用程序进程阻塞主线程时就会发生 ANR。几乎任何缘由均可能致使这种阻塞，但最多见的缘由包括：

• 在主线程上执行磁盘或网络读写操做。这是迄今为止 ANR 最多见的缘由。虽然大多数开发人员都认为你不该该在主线程上读取或写入数据到磁盘或网络，但有时咱们总会无心间这么作。在理想状况下从磁盘读取几个字节可能不会致使 ANR，可是这毫不是一个好主意。若是用户使用的设备闪存很慢怎么办？若是他们的设备受到来自其余应用程序同时读取和写入的巨大压力，而你的应用程序在队列中等待执行“快速”读取操做时又该怎么办？切勿在主线程上执行读写操做。
• 在主线程上执行长时间计算。那么内存里的计算会怎么样呢？RAM 不会受长时间访问的影响，较小的操做应该没问题。可是，当你开始在循环中执行复杂计算或处理大型数据集时，能够轻松阻塞主线程。能够考虑调整包含数百万像素的大图像的大小，或解析大块的 HTML 文本，而后在 TextView 中显示。通常来讲，最好让你的应用在后台执行这些操做。
• 从主线程向另外一个进程运行同步绑定调用。与磁盘或网络操做相似，在跨进程边界进行阻塞调用时，程序执行会传递到你没法控制的某个位置。若是其余进程很忙怎么办？若是它须要访问磁盘或网络来响应你的请求怎么办？另外，数据传递给另外一个进程须要进行序列化和反序列化，这也须要时间。最好从后台线程进行进程间调用。
• 使用同步。即便你将繁重的操做移动到后台线程，也须要与主线程进行通讯以显示进度或计算的结果。多线程编程并不容易，并且在使用同步进行锁定时，一般很难保证不会阻塞执行。在最糟糕的状况下，它甚至可能致使死锁，线程之间互相阻塞永久等待下去。最好不要本身设计同步，使用专门的解决方案会更好一些，好比 Handler，从后台线程传递不可变的数据到主线程。

我如何检测 ANR 的缘由？

查找 ANR 的缘由可能会很是棘手，就拿 URL 类来讲吧。 你以为肯定两个 URL 是否相同的 URL#equals 方法是否会被阻塞？SharedPreferences 又会怎样？若是你在后台从中读取值，能够在主线程上调用 getSharedPreferences 方法吗？在这两种状况下，答案是这些均可能是长时间阻塞操做。

幸运的是，StrictMode 使查找 ANR 再也不靠猜的。在调试版本中使用这个工具能够捕获主线程上意外的磁盘和网络访问。在应用程序启动时使用 StrictMode＃setThreadPolicy 能够自定义你想要检测的内容，包括磁盘和网络读写，甚至能够经过 StrictMode＃noteSlowCall 在应用程序中触发自定义的慢速调用。你还能够选择 StrictMode 在检测到阻塞调用时如何提醒你：经过让应用程序崩溃、Log 信息或者是显示对话框。更多详细信息，请参阅 ThreadPolicy.Builder类。

一旦你消除了主线程中的阻塞调用，记得在将你的应用程序发布到 Play Store 以前关闭 StrictMode。

消除过分唤醒和 ANR 将提升应用程序的质量和可用性，提升评分和评论，进而实现更多安装。经过查看 Android vitals，你能够快速轻松地发现是否存在须要解决的问题。在代码中查找和解决这些问题并不老是那么直截了当，但有些工具和技术能够帮你更高效地完成这些工做。

Android vitals 还能够给你提供更多帮助，我会在下一篇文章里介绍更多这些功能。我将在 5 月 8 日星期二下午 3 点，在 Google I/O 2018 大会上和同事 Fergus Hurley 以及 Joel Newman 一块儿演示 “Android vitals：调试应用程序性能和收获奖励” 的环节。若是你在那里或者想经过直播了解更多关于 Android vitals、最新的 Play Console 和 Android Studio 工具以及帮助你提升应用质量的意见，请加入咱们。

---

若是你对 Android vitals 有任何想法或疑问，请经过 #AskPlayDev 发送推特告知咱们。咱们会经过 @GooglePlayDev 回复你，咱们也会按期在上面分享有关如何在 Google Play 上取得成功的新闻和提示。

若是发现译文存在错误或其余须要改进的地方，欢迎到 掘金翻译计划 对译文进行修改并 PR，也可得到相应奖励积分。文章开头的 本文永久连接 即为本文在 GitHub 上的 MarkDown 连接。

---

掘金翻译计划 是一个翻译优质互联网技术文章的社区，文章来源为 掘金 上的英文分享文章。内容覆盖 Android、iOS、前端、后端、区块链、产品、设计、人工智能等领域，想要查看更多优质译文请持续关注 掘金翻译计划、官方微博、知乎专栏。