Android vitals 简介
- 谷歌推荐使用Android vitals来帮助开发者提高App的稳定性和性能表现。
- 作为这个方案的一部分, Play Console提供了Android Vitals dashboard的早期测试版本。当被选中的用户运行App时,设备会记录大量的测试指标数据,包括app稳定性、渲染时间和电池使用数据。
- Play Console统计这些数据并在dashboard中显示。
- 这个dashboard将帮助开发者了解app的性能,而且当app的性能表现不好时,会发出相应的警告。
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
ANRs
描述:UI线程如果被阻塞太长的时间, “Application Not Responding” (ANR) 就被触发。
- 如果被阻塞的app处于前台,系统会显示一个ANR对话框。
触发:以下两个条件,任意各一个都会导致ANR
- 当app处于前台时,在5s内无法相应用户输入或广播。
- 当app没有activity处于前台时,广播接收器正在进行长时间的任务,且无法结束。
- 常见情况:长耗时计算、IO操作、锁竞争、死锁、慢广播处理。
Crashes
未经处理的异常或signal将会导致Crash。
- Java代码crash主要是Throwable类抛出的未处理异常
- Nativie代码crash主要是由未经处理的signal导致,比如SIGSEGV
Slow rendering
- 为了保证UI交互的流畅,必须保证每帧的渲染时间不超过16毫秒,保证60的FPS。
- 一旦界面有较慢的渲染,系统将强制跳帧,用户就会感觉到卡顿。
- We call this jank. 我们把这种现象称为jank。
Frozen frames
- 超过700毫秒渲染时间的帧,是slow rendering的极端情况。
- 你的app将会在冻帧处卡顿,并且几乎整整一秒都无法响应UI。
- 由于用户操作(比如滑动屏幕),app需要启动或切换场景,并布局和渲染所有屏幕中的view,使得渲染时间可能超过16ms。
- 但无论如何,冻帧都不应当出现。系统会自动监控冻帧,并在 Android Vitals dashboard显示冻帧数据。
Stuck partial wake locks
- 局部唤醒锁是PowerManager在屏幕关闭之后,保持cpu继续运行的机制。不管屏幕关闭是系统超时,还是用户按下了电源键。
- app通过
acquire()
及Flag参数PARTIAL_WAKE_LOCK
来请求局部环形锁。 - 当app获得了局部唤醒锁,并长时间运行在后台(对于用户不可见),这个局部环形锁就会处于卡住(stuck)状态。
- 如果局部唤醒锁长期处于卡住状态,将会加快耗尽电池,因为它会阻止系统进入低功耗模式。
- 规范使用:当app需求时才获取局部唤醒锁,并在任务完成后尽快释放掉。
Excessive wakeups
- 唤醒机制,是
AlarmManager
API 为了定时唤醒设备而设置闹铃的机制。 - app通过
AlarmManager
的set()
方法来设置闹铃,同时还需要选择RTC_WAKEUP
或 ELAPSED_REALTIME_WAKEUP
作为FLAG。 - 当闹铃触发时,设备从低功耗模式唤醒,而且当
onReceive()
或onAlarm()
运行时,将自动获取一个局部唤醒锁。 - 过多地唤醒,将加快电量的损耗。
Excessive Wi-Fi Scanning in the Background
- 每当后台执行WIFI扫描,将会唤醒CPU,导致电量损耗。
- 如果多次执行WIFI扫描,电池寿命将会显著地降低。
Excessive background network usage
- 当每app在后台连接移动网络,将会唤醒CPU并打开无线设备。
- 频繁地连接移动网络,将会加快电量损耗。