去年谷歌进行的一项内部调查显示 Play Store 中超过 40% 的一星应用存在稳定性问题。另一方面，对于性能卓越的应用，人们打分和评论往往越来越好，这让它们在 Google Play 中的排名上升，下载量也随之增加。不仅如此，用户参与度也更高，而且愿意花更多的时间和金钱在这些应用上。
因此，解决应用稳定性问题能够显著影响到应用成功与否。
通过对应用质量的客观测量，开发者能够轻易发现应用亟待解决的稳定性问题，为此我们在 Google Play Console 添加了一款名为 Android vitals 的新板块。借助 Android vitals，开发者无须添加额外工具代码或者库就能了解应用存在的性能及稳定性问题。当应用在大量设备上运行时，Android vitals 会收集与应用性能相关的匿名数据。通过这种途径获得的信息量是其他方式无法匹及的，即使是硬件实验室测试也不行。
Android vitals 可以向开发者发送以下三种警告：崩溃、应用程序无法响应以及渲染次数。这三种情况都会直接影响到用户体验以及他们对应用的评价。此外，用户可能不会将 “异常耗电事件” 这类不良行为与您的应用直接联系起来。
这篇文章将探讨其中以下两个问题：
1. 过度唤醒 ：过度唤醒会对电池寿命造成影响，而且在无法及时充电的情况下，可能导致用户无法继续使用设备。此类行为可能会让用户迅速卸载您的应用；
2. 应用程序无法响应 (ANR)事件 ：当应用的用户界面卡住时候，此类事件会被触发。在界面冻结时，若您的应用在前台运行，会出现对话框提醒用户 “关闭应用” 或者 “等待响应”。对用户而言，此类行为和应用崩溃一样糟糕。他们可能不会马上卸载您的应用，但是如果 ANR 问题一直不解决，就很有可能会寻找其它替代应用。
过度唤醒
为了延长电池续航时间，屏幕关闭后，Android 设备会禁用主 CPU 内核，进入深度睡眠模式。除非用户唤醒设备，设备最好可以尽可能长地保持这种状态。不过，在发生某些事件的情况下，还是很有必要唤醒 CPU 并向用户发出警告 —— 比如说，闹钟触发或者收到新消息。开发者可以通过唤醒闹钟 (wakeup alarm) 来处理此类警告，不过也不一定非要这么操作，在下文中会对此稍加解释。到目前为止，唤醒看上去似乎是个不错的东西，让重要事情能引起用户注意，不过要是唤醒太多次就适得其反，电池寿命也会大打折扣。
Android vitals 如何显示过度唤醒
Android vitals 能够帮助开发者了解自己的应用是否存在唤醒次数太多的问题。通过收集有关应用行为的匿名数据，Android vitals 可以显示有多少比例的用户在设备满电之后，每小时经历 10 次以上的设备唤醒。关键就是看有没有红色的图标出现，若图标出现，则说明应用已经越过了不良行为门槛，属于 Google Play 中表现最次的一档应用，而您则须要想办法改善应用行为了。
除了唤醒闹钟，还有别的方法吗？
开发者主要是通过 AlarmManager API 设定 RTC_WAKEUP 或 ELAPSED_REALTIME_WAKEUP 旗标，让应用在特定时间或者在某一时间间隔后唤醒设备。该功能须谨慎对待，仅在没有其它更优的任务调度和通知机制的情况下才可使用。在使用唤醒闹钟的时候，您需要考虑以下几点：
- 若您需要显示信息以响应来自网络的数据，考虑通过使用 Firebase Cloud Messaging 等工具来实现消息推送。利用该机制而不是定期轮询新数据，您的应用会仅在需要时才被唤醒。
- 如果您无法使用消息推送并依赖定期轮询，考虑使用 JobScheduler 或者 Firebase JobDispatcher (或者使用 SyncManager 来处理账户数据)。它们的 API 等级比 AlarmManager 高，而且在智能任务调度方面具备以下优点：
-- 批量操作：批量操作任务而不是多次唤醒系统进行操作，这使设备能更长时间处于睡眠状态。
