对于应用开发者而言，衡量应用成功最好的指标就是开心的用户，而且是越多越好。达到这一目的的最佳途径就是开发一个好应用，那么什么样的应用才能被称作是 “好” 应用呢？归根结底就是两件事：功能以及应用质量。前者取决于开发者的创造力以及选用的商业模型；而后者则能够被客观测量及改善。
去年谷歌进行的一项内部调查显示
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 旗标，让应用在特定时间或者在某一时间间隔后唤醒设备。该功能须谨慎对待，仅在没有其它更优的任务调度和通知机制的情况下才可使用。在使用唤醒闹钟的时候，您需要考虑以下几点：
当且仅当消息推送以及任务调度对您的任务不适用时，您才可以利用 AlarmManager
设定唤醒闹钟。换个角度来说就是，仅当您想要在特定时间触发闹钟，不考虑网络以及其它情况，唤醒闹钟才是必要的。
当 Android vitals 显示过度唤醒时，您应采取何种对策？
为了解决过度唤醒问题，您须要确认应用在什么地方设定了唤醒闹钟，然后降低这些闹钟的触发频率。
那么如何查看应用在哪些地方设了唤醒闹钟呢？您可以打开
Android Studio 中的 AlarmManager 类，右击 RTC_WAKEUP 或者 ELAPSED_REALTIME_WAKEUP 域，选择
"Find Usages (查找使用)"，然后您就能看到项目中所有使用到此类旗标的事件了。仔细查看每一种事件，然后考虑能否改用更为智能的任务调度机制。
您也可以将 Find Usage (查找使用) 中的范围设定为 “Project and libraries (项目和库)”，查看依赖项是否在使用 AlarmManager API。如果确实在使用，那么您应该考虑使用别的库，或者向依赖项开发人员报告错误。
若您认为使用唤醒闹钟无法避免，那么如果您的闹钟标签满足以下要求，Play Console 可以提供更好的分析数据：
应用程序无法响应
那么，什么是应用程序无法响应 (以下简称为ANR)？它又是怎么影响到用户的呢？
对用户而言，ANR 就是指当他们试图与应用进行交互时，但界面卡住的事件。界面卡屏几秒后，会出现对话框让用户选择继续等待或者强行停止应用。
从开发者的角度来看，ANR 则是指应用运行的操作耗时过久，如磁盘或网络 I/O，导致主线程阻塞。主线程 (有时候也被称为 UI 线程)
主要负责响应用户事件以及每秒刷新 60 次屏幕。因此很关键的一点将任何可能延时主线程工作的操作转到后台线程。
Android vitals 如何显示应用程序无法响应？
Android vitals 能收集并利用应用 ANR 事件的匿名数据，提供多个级别的 ANR 具体报告。主界面上概述了您应用中 ARN 活动的概览信息，显示用户至少经历一次 ANR 事件的日对话比重，并且提供前一天以及前 30 天的情况的单独报告。同时也提供了不良行为门槛。
打开详情界面，即 ANR 比率页面，您能够了解不同时间的 ANR 具体比例，以及针对不同应用版本、活动名称、ANR 类别、以及 Android 系统下的 ANR 情况。您可以就 APK 版本代码、支持设备、OS 版本以及时间，筛选查看这些数据。
应用程序无法响应常见原因
如上文所述，当应用进程影响到主线程时，ANR 事件会被触发，而导致这种阻塞现象的原因各有不一，较为常见的有：
如何检测应用程序无法响应原因
寻找触发 ANR 的原因不容易，我们拿 URL 类举个例子：
1. 您想看到 URL#equals (判断两个 URL 是否相同的方法) 阻塞线程吗？SharedPreferences 又怎么处理呢？
2. 如果您是在后台读取数值的话，您能在前台调用 getSharedPreferences 吗？
这两种情况都很可能导致长时间阻塞操作。幸好我们有 StrictMode，雅思口语考官不用再自己瞎猜是什么原因导致
ARN 了。在调试构建的时候，您可以使用这个工具捕捉主线程上的意外磁盘或网络访问。
您可以在应用中使用
StrictMode#setThreadPolicy，自定义检查项，包括磁盘和网络 I/O 以及您通过 StrictMode#noteSlowCall
在应用中触发的慢调用。同时，您也可以自己选择让 StrictMode 通过何种方式告知已检测到阻塞调用：应用崩溃、日志记录还是显示对话框？您可参看
ThreadPolicy.Builder class 获取进一步信息。
一旦您消除主线程上的阻塞调用，请记得再上传应用至 Play Store 前，关闭
StrictMode。
解决过度唤醒以及 ANR 问题能够提升应用质量及稳定性，提高应用评分，获取更多好评，最终增加下载量。使用 Android
vitals 让您轻松快速地了解应用中亟待解决的问题。发现并解决代码中的这些问题可能并不容易，但是您可以利用工具和技术有效地完成工作。
?点击屏末?|?阅读原文?| 您可查看?Android?和?Google Play?相关内容信息
推荐阅读：
·?工匠开发者
Hans J?rgen Wiberg 的故事 | #IMakeApps
·?探险家开发者 Niek Bokkers
的故事 | #IMakeApps
文章来源：https://blog.csdn.net/jILRvRTrc/article/details/81199659