做Android/iOS测试也有一段时间了,随着项目壮大,版本crash问题也越来越突出。如何有效地对crash进行预防拦截呢?请看下文。
以下画面相信负责过APP项目一定见过,它是怎么出现的呢?
以下为基于Android源码分析的完整代码调用关系:
主流程如下:
使用try...catch
语句,那么如果没有有效catch exception,此时系统便会来进行捕获,并进入crash流程(分为六大流程):
1首先发生crash所在进程,在创建之初便准备好了defaultUncaughtHandler,用来来处理Uncaught Exception,并输出当前crash基本信息;
2调用当前进程中的AMP.handleApplicationCrash;经过binder ipc机制,传递到system_server进程;
3接下来,进入system_server进程,调用binder服务端执行AMS.handleApplicationCrash;经过一系列的调用最终痛过mUiHandler发送消息SHOW_ERROR_MSG,弹出crash对话框;
4到此,system_server进程执行完成。回到crash进程开始执行杀掉当前进程的操作;
5当crash进程被杀,通过binder死亡通知,告知
system_server进程来执行appDiedLocked();
6最后,执行清理应用相关的
activity/service/ContentProvider/receiver组件信息。
可以尝试自己下载最新的源码并查看分析,相关源文件:
RuntimeInit.java
ActivityManagerNative.java
ActivityManagerService.java
ProcessRecord.java
WindowManagerService.java
更多详情可参考这里(http://gityuan.com/2016/06/24/app-crash/)。
Crash后,我们首先能做些什么呢?测试怎么入手?
最先能想到的是收集crash日志信息:
For Android
Native 程序异常后,会生成tombstone 文件位于路径 /data/tombstones/ 下
Java异常可以在Logcat(adblogcat)日志中看到;
ANR日志会存在系统目录/data/anr/traces.txt
For iOS:
可以连接Mac,通过Xcode->Window->Devices导出对应的crash日志文件。如iPhone设备的CrashLog位置位
于:var/mobile/Library/Logs/CrashReporter
实际项目中都接入了Bugly,APP crash后,会自动上报到分析平台,crash相关的信息相对比较丰富,并可以自动还原异常时调用栈信息(栈还原 加固 混淆 符号化等相关问题都可解决)。
日志信息中,比较关键的信是错误类型。这里带大家了解一下目前移动端关于异常的整体分类情况。
对Android来说主要有以下几种:
iOS下crash大致可如下划分:
除了错误类型信息,还有哪些测试需要重点关注呢?接下来看一下
对于测试来说,接到crash报告后面临的问题有:
1、crash产生的原因初步分析
2、疑难crash的重现
对于错误信息及栈比较明确的crash,定位起来一般没有什么难度。
如图,栈信息及代码行可以很容易定位到出问题的子模块,排查起来难度不大。
比较复杂的问题可能集中在crash的栈都是系统信息或者第三方库,或者多个模块存在耦合的代码,排查起来难度比较大。
如图,栈里面都是android自己的内容:
对于这类问题,从项目角度可以从提升定位效率及快速重现方面入手:
如目前iOS项目中已经加入了点击流上报,可以辅助定位crash栈中无app代码的疑难问题。
Crash基本分析完成了,是否有办法从源头来减少crash问题呢?当然有↓↓↓
随着版本量越来越大,对crash的预估是否力不从心?如何有效地对crash问题进行拦截阻击呢?
以下是crash跟进总结过程中的一些可深入的点,如:
1 体验类问题
体验类问题,如保证异常后的恢复无明显异常:
2 代码质量提升
crash分析总结中,可以把常见的坑,提取成静态扫描规则加入到代码扫描中;
3 通用异常点总结
通过对异常场景的收集总结完善测试分析,规避异常路径未覆盖导致的crash
4 测试覆盖率分析
5 自动化随机测试
6 动态调试
常用于快速复现crash及检测内存相关问题。
通过以上crash拦截手段,也取得了一些效果:
1 Klocwork代码扫描
2 iOS目前接入Infer
iOS目前接入Infer,扫描问题100+:
3 自定义扫描规则
自定义扫描规则,扫描问题200+:
4 Monkey等随机点击测试
Monkey等随机点击测试,发现问题10+;
下面是一些常见的crash列表,供参考
1、【Android】Android Crash之异常信息反馈机制
http://blog.csdn.net/u010119170/article/details/38236991
2、 理解Android Crash处理流程
http://gityuan.com/2016/06/24/app-crash/#handleApplicationCrashInner
3、 理解Native Crash处理流程
http://gityuan.com/2016/06/25/android-native-crash/
4、 iOS崩溃crash大解析
http://www.jianshu.com/p/1b804426d212
5、 Throwable、Error、Exception、RuntimeException 区别 联系
http://blog.csdn.net/liuj2511981/article/details/8524418
6、 Android的crash的类型及原因
http://blog.csdn.net/wtyvhreal/article/details/45146531
7、 Android NDK Tombstone/Crash 分析
http://woshijpf.github.io/2016/06/14/Android-NDK-Tombstone-Crash-%E5%88%86%E6%9E%90/
8、 分析iOS Crash文件:符号化iOS Crash文件的3种方法
http://wufawei.com/2014/03/symbolicating-ios-crash-logs/
9、 iOS 启动连续闪退保护方案
https://wereadteam.github.io/2016/05/23/GYBootingProtection/
10、 Throwable
https://developer.android.com/reference/java/lang/Throwable.html
11、 iOS调试之 crash log分析
http://www.jianshu.com/p/12a2402b29c2
12、 分析iOS Crash文件:符号化iOS Crash文件的3种方法
http://www.cocoachina.com/industry/20140514/8418.html
13、 Understanding iOS Exception Types
http://www.5neo.be/understanding-ios-exception-types/
14、 Unix signal
https://en.wikipedia.org/wiki/Unix_signal
15、 Handling unhandled exceptions and signals
https://www.cocoawithlove.com/2010/05/handling-unhandled-exceptions-and.html