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扫描和后台连接移动网络也会加快电量损耗，所以不要在后台启动过多的后台服务。