Android Crash和ANR监控

一、Crash

1.1 概念

表现：Crash也就是程序崩溃或闪退
影响：

1. 程序无法继续运行，数据丢失
2. 糟糕的用户体验

1.2 类型

类型：闪退分为Java层的闪退和native层的闪退。

  Application Crash由于java层线程因未捕获异常而终止，由系统的void uncaughtException(Thread t,Throwable e) 方法进行捕获和处理，通常会给出界面弹窗提示“***已停止运行。”。

Application Crash常见原因如下：（都是常见的java异常）

1. NullPointerException：空指针异常。
2. SQLException：操作数据库异常类。
3. ClassCastException：数据类型转换异常。
4. NumberFormatException：字符串转换为数字类型时抛出的异常。
5. ClassNotFoundException：这个异常的解释是"指定的类不存在"。
6. ArithmeticException：这个异常的解释是"数学运算异常"，比如程序中出现了除以零这样的运算就会出这样的异常。
7. ArrayIndexOutOfBoundsException：数组越界异常
8. IllegalArgumentException：这个异常的解释是"方法的参数错误"
9. IllegalAccessException：这个异常的解释是"没有类访问权限"
10. ArrayStoreException：错误对象存储到数组

二、ANR

2.1 概念

表现：ANR即应用程序无响应。
UI线程被阻塞太长时间，就会出现ANR，然后弹框，结束进程、继续等待。

影响：

1. 等待时间过长，无提示，无法给出等待的反馈，用户流失
2. 无法继续完成操作，数据丢失

2.2 类型

2.2.1 KeyDispatchTimeout（常见）

input事件在5S内没有处理完成发生了ANR。
logcat日志关键字：Input event dispatching timed out

下图为典型的input anr触发流程：

2.2.2 BroadcastTimeout

前台Broadcast：onReceiver在10S内没有处理完成发生ANR。
后台Broadcast：onReceiver在60s内没有处理完成发生ANR。
logcat日志关键字：Timeout of broadcast BroadcastRecord

2.2.3 ServiceTimeout

前台Service：onCreate，onStart，onBind等生命周期在20s内没有处理完成发生ANR。
后台Service：onCreate，onStart，onBind等生命周期在200s内没有处理完成发生ANR
logcat日志关键字：Timeout executing service

下图为典型的 service/broadcast anr触发流程：

2.2.4 ContentProviderTimeout

ContentProvider 在10S内没有处理完成发生ANR。
logcat日志关键字：timeout publishing content providers

下图为典型的 contentProvider anr触发流程：

三、测试中如何关注

3.1 Crash测试关注方法

• 关注界面中的所有按钮、控件的操作有效性，点击是否能产生对应的目标事件
• 通过自动化对应用的部分运算操作进行长时间负载测试，可有效暴露此问题
• 通过重复的多次操作可有效暴露此问题
• 通过对输入框进行异常输入，例如日期输入框，文本输入框等

如何解决：

1. log文件夹下全局搜am_crash，此时会把log文件下下所有的包含am_crash的行显示出来
2. crash问题很好看，基本上就代码写的有问题，针对出现的问题修改一下就好

3.2 ANR测试关注方法

• 对部分上传文件较大的页面、保存文件信息较多的动作，比如电话本信息、带有图片的记事本保存等操作。
• 对某一时间的网络进行极限使用，在被测应用的一个场景无法使用网络的情况下关注。
• 重复多次的操作可能导致ANR事件，可使用Monkey工具进行测试。
• 多任务、多线程应用内存占用极限时

如何解决：

1. log文件夹下全局搜am_anr，此时会把log文件下下所有的包含am_anr的行显示出来（也可以搜activitymanager: ANR）
2. 一般同一个时间点的anr log会在不同的文件中出现两次，一次是logxxx.txt中，一次是在crash_xxxxxx文件夹中的aplog_ANR_时间文件中
3. 进入到crash_xxxxxx文件夹下，找到一个data_app_anr@xxx.txt文件
4. 在data_app_anr@xxx.txt文件中找到"main" prio=5 tid=1 Nativ这一行，往下看会有一些异常log，这些log描述的就是问题原因
5. ANR如果是由于主线程阻塞，在data_app_anr@xxx.txt中的"main" prio=5 tid=1中会显示 block

四、如何记录与处理

4.1 记录保存问题现场

1. 系统各类日志信息收集，如果可以建议开发提供一个一键式日志收集功能或自己编写一个一键式日志收集脚本
2. 保存进程crash的coredump信息，便于后续开发进一步定位分析

4.2 记录问题出现条件或步骤

1. 出现问题后，第一时间记录本次问题发生前各类预置条件：app或系统版本信息，测试工具信息、硬件环境信息、被测试对象版本信息等等
2. 自动化或手动测试操作步骤信息记录：如果是自动化测试，要保存好自动化用例步骤；如果是手动测试，养成良好的记录习惯，记录好测试步骤
3. 很多问题是概率出现的，问题定位解决过程中，很有可能需要你复现问题。 养成良好习惯，可以降低问题复现成本

4.3 协助开发及相关人进行问题定位分析

1. 平时测试过程中，与开发及周边相关人员，建立好良好沟通矩阵
2. 问题出现后，首先详细描述问题现象，拉通开发人员协助收集问题信息及开展问题定位

4.4 风险告知，避免问题扩大化

1. 养成良好的风险意识，结合版本发布计划，与项目经理、测试经理等相关人明确问题影响及风险
2. 譬如：如果版本马上要发布了，你测试过程中遇到致命的crash等问题，需要及时知会项目利益相关人，项目经理/测试经理/开发代表等角色，可能因为你发现的这个问题评估项目发布节奏等

参考文档：
  https://juejin.cn/post/7170975699593855012
  https://blog.csdn.net/sinat_26192119/article/details/115483842