Android vitals 帮您解决应用质量问题

对于应用开发者而言，衡量应用成功最好的指标就是开心的用户，并且是越多越好。达到这一目的的最佳途径就是开发一个好应用，那么什么样的应用才能被称做是 “好” 应用呢？归根结底就是两件事：功能以及应用质量。前者取决于开发者的创造力以及选用的商业模型；然后者则可以被客观测量及改善。

去年谷歌进行的一项内部调查显示 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 高，并且在智能任务调度方面具有如下优势：

-- 批量操做：批量操做任务而不是屡次唤醒系统进行操做，这使设备能更长时间处于睡眠状态。

-- 标准：您能够明确任务运行须知足的具体标准，如网络可用性或者电池充电状态。设定标准可以避免唤醒设备以及没必要要的应用运行。

-- 持续性以及自动退避 —— 继续执行任务 (即便在重启后) 而且在失败的状况能自动重试。

-- 低耗电模式 (doze) 兼容性 —— 仅在低耗电模式或者应用待机模式未设定任何限制的状况下，任务才能运行。

当且仅当消息推送以及任务调度对您的任务不适用时，您才能够利用 AlarmManager 设定唤醒闹钟。换个角度来讲就是，仅当您想要在特定时间触发闹钟，不考虑网络以及其它状况，唤醒闹钟才是必要的。

当 Android vitals 显示过分唤醒时，您应采起何种对策？

为了解决过分唤醒问题，您需要确认应用在什么地方设定了唤醒闹钟，而后下降这些闹钟的触发频率。

那么如何查看应用在哪些地方设了唤醒闹钟呢？您能够打开 Android Studio 中的 AlarmManager 类，右击 RTC_WAKEUP 或者 ELAPSED_REALTIME_WAKEUP 域，选择 "Find Usages (查找使用)"，而后您就能看到项目中全部使用到此类旗标的事件了。仔细查看每一种事件，而后考虑可否改用更为智能的任务调度机制。

您也能够将 Find Usage (查找使用) 中的范围设定为 “Project and libraries (项目和库)”，查看依赖项是否在使用 AlarmManager API。若是确实在使用，那么您应该考虑使用别的库，或者向依赖项开发人员报告错误。

若您认为使用唤醒闹钟没法避免，那么若是您的闹钟标签知足如下要求，Play Console 能够提供更好的分析数据：

• 在闹钟标签中包含包、类或者方法名称。这也能够帮助您轻松肯定在源中的哪些地方设定了闹钟；
• 不要使用 Class#getName() 给闹钟命名，由于 Proguard 会对此产生混淆。请使用硬编码字符串；
• 不要向闹钟标签添加计数器或者其它惟一标识符，由于系统可能会贵去掉这类标签，并且没法将它们计入有效数据内。

应用程序没法响应

那么，什么是应用程序没法响应 (如下简称为ANR)？它又是怎么影响到用户的呢？

对用户而言，ANR 就是指当他们试图与应用进行交互时，但界面卡住的事件。界面卡屏几秒后，会出现对话框让用户选择继续等待或者强行中止应用。

从开发者的角度来看，ANR 则是指应用运行的操做耗时太久，如磁盘或网络 I/O，致使主线程阻塞。主线程 (有时候也被称为 UI 线程) 主要负责响应用户事件以及每秒刷新 60 次屏幕。所以很关键的一点将任何可能延时主线程工做的操做转到后台线程。

Android vitals 如何显示应用程序没法响应？

Android vitals 能收集并利用应用 ANR 事件的匿名数据，提供多个级别的 ANR 具体报告。主界面上概述了您应用中 ARN 活动的概览信息，显示用户至少经历一次 ANR 事件的日对话比重，而且提供前一天以及前 30 天的状况的单独报告。同时也提供了不良行为门槛。

打开详情界面，即 ANR 比率页面，您可以了解不一样时间的 ANR 具体比例，以及针对不一样应用版本、活动名称、ANR 类别、以及 Android 系统下的 ANR 状况。您能够就 APK 版本代码、支持设备、OS 版本以及时间，筛选查看这些数据。

应用程序没法响应常见缘由

如上文所述，当应用进程影响到主线程时，ANR 事件会被触发，而致使这种阻塞现象的缘由各有不一，较为常见的有：

• 在主线程上执行磁盘或者网络 I/O。这是迄今为止致使 ANR 的最多见缘由。虽然大部分开发者认同不该该在主线程上进行读写磁盘或者网络，可是有时候咱们就是忍不住这么作。在理想状况下，从磁盘上读取几个字节的数据并不会引起 ANR，可是这绝对不是什么好主意。若是用户的设备闪存很慢，若是其它同时进行读写的应用已经对设备形成了很大压力，而您的应用还在排队等着运行 “快速” 读取操做, 这样真的不够明智，因此千万别在主线程运行 I/O；
• 在主线程上运行长计算。那么内存计算又是怎么一回事呢？访问时间长并不会对内存形成影响，较小的操做应该也没什么问题。可是若是您开始循环运行复杂计算而且处理大数据集，主线程就很容易发生阻塞了。您能够考虑从新调整百万像素大图像的体积，或者在解析大 HTML 文本块后，再将文本显示到 TextView 中。总的来讲，仍是让应用在后台运行此类操做比较合适；
• 向主线程另外一进程同步调用 binder：与磁盘或网络操做类似，在线程间进行阻塞调用时，程序执行会被转移到您没法控制的地方。若是说其它进程忙碌，该怎么办？若是需要访问磁盘或者网络以响应您的请求，又该怎么办？此外，数据在转移到其它进程前，需要通过打包 (parcel) 与解包 (unparcel) 两个步骤，会消耗很多时间。所以，仍是建议从后台线程进行进程间调用；
• 使用同步：即便您将复杂操做转移到后台线程运行，依旧需要与主线程沟通以显示计算结果。多线程编程不容易，而且在使用同步锁的时候，很难保证不出现阻塞执行。在最糟糕的状况下，可能会出现死锁问题，即不一样线程相互卡死。最好不要本身设计同步，建议使用专门的解决方案，好比说 Handler，将不可变数据从后台线程传回主线程。

如何检测应用程序没法响应缘由

寻找触发 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 相关内容信息