Android vitals 提升app性能和质量

Android vitals 简介

谷歌在2017年的I/O大会上提出的另一个概念是Vitals，重点是在Android O版本中，将针对设备电池续航、安全、应用启动时间和稳定性的优化上。除了系统的优化外，Google Play控制台提供的新功能Android vitals仪表盘也可以更清楚的帮助开发者理解app的行为表现，进而提升app的性能。有兴趣的读者可以通过Android vitals来了解。

通过分析Android vitals 提供一些参考指标，工程师可以采取正确的措施来优化app，如上通过仪表盘可以看到从设备收集的如下的数据：

Stability: ANR rate & crash rate
Render time: slow rendering (16ms) and frozen UI frames (700ms)
Battery usage: stuck wake locks and excessive wakeups

判断指标

下面是Android vitals 的一些常见的判断指标：

• ANR rates
• Crash rates
• Slow rendering
• Frozen frames
• Stuck partial wake locks
• Excessive wakeups
• Excessive background Wi-Fi scans
• Excessive background network usage

下面是Android vitals常见的检测指标以及解决方案。

ANRs

ANR是Application Not Responding的缩写，是UI线程如果被阻塞太长的时间所造成的。触发ANR问题的主要有两个原因：

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

产生问题的可能的源头有：长耗时计算、IO操作、锁竞争、死锁、慢广播处理。

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

打开详情界面，即 ANR 比率页面，您能够了解不同时间的 ANR 具体比例，以及针对不同应用版本、活动名称、ANR 类别、以及 Android 系统下的 ANR 情况。

Crashes

未经处理的异常或signal将会导致程序的Crash。

• Java代码crash主要是Throwable类抛出的未处理异常
• Nativie代码crash主要是由未经处理的signal导致，比如SIGSEGV

Frozen frames

造成Frozen frames的原因有：

• 超过700毫秒渲染时间的帧，是slow rendering的极端情况。
• app将会在冻帧处卡顿，并且几乎整整一秒都无法响应UI。
• 由于用户操作(比如滑动屏幕)，app需要启动或切换场景，并布局和渲染所有屏幕中的view，使得渲染时间可能超过16ms。

但无论如何，冻帧都不应当出现。系统会自动监控冻帧，并在 Android Vitals dashboard显示冻帧数据。

Excessive wakeups

唤醒机制，是AlarmManager API 为了定时唤醒设备而设置闹铃的机制，app通过AlarmManager的set()方法来设置闹铃，同时还需要选择RTC_WAKEUP 或 ELAPSED_REALTIME_WAKEUP作为FLAG。当闹铃触发时，设备从低功耗模式唤醒，而且当onReceive()或onAlarm()运行时，将自动获取一个局部唤醒锁，过多地唤醒，将加快电量的损耗。

为了解决过度唤醒问题，您须要确认应用在什么地方设定了唤醒闹钟，然后降低这些闹钟的触发频率。为了查看应用在哪些地方使用了唤醒闹钟，可以打开 Android Studio 中的 AlarmManager 类，右击 RTC_WAKEUP 或者 ELAPSED_REALTIME_WAKEUP 域，选择 “Find Usages (查找使用)”，然后您就能看到项目中所有使用到此类旗标的事件了。

若您认为使用唤醒闹钟无法避免，那么如果您的闹钟标签满足以下要求，Play Console 可以提供更好的分析数据：

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

除此之外，WIFI扫描和后台连接移动网络也会加快电量损耗，所以不要在后台启动过多的后台服务。