Question

对于一款App而言，最重要的莫过于稳定性，没有之一。

Android之所以存在千奇百怪的Crash，主要归结于以下几种情况：

1）Android系统的碎片化。各种硬件厂商都定制自己的ROM，改写了Android系统的很多方法。对于App而言，在大多数手机上没有问题，但是到了该厂商的手机系统里，使用到这些方法就会崩溃。当然，也不能排除ROM上的方法被改写后存在bug的情况。

2）MobileAPI返回了脏数据。比如说当MobileAPI返回空值或空数组时，App收到数据后就会发生空指针或数组越界的Crash。有时则是某个字段返回0，而这个字段作为除数时，也会发生不能除以0的Crash。

3）混淆时没有Keep要使用的类或方法，也会发生找不到类或方法的Crash。

Android正是因为有这些光怪陆离的Crash而显得比iOS开发有趣得多。

我们继续聊，每个Crash都对应Android中的一类Exception。本章就是要介绍Android中的各类Exception，这些都是我亲身经历过的，其中的大部分都已经修复，当然也有一些Crash直到现在仍是不明觉厉。

Crash信息会因为App进行了混淆处理而看不懂具体是在哪个方法哪行代码崩溃的，所以我们需要把每次发版打包时生成的ProGuardMapping文件保留下来，然后根据这个文件中方法混淆前后的对应关系，找到发生崩溃所在的原始的类、方法和代码行。

此外，我还发现，有些Crash是开发人员在调试的时候发到线上的Crash数据库中的。为此，本地开发版本的渠道号，要与发到线上的渠道号区分开。否则，就会误认为是线上Crash而白花很多时间去查原因。

提示 Unknown Source

异常信息中经常会出现“方法名”（Unknown Source）的内容。这就加大了我们准确定位Crash发生原因的难度。

导致Unknown Source的出现有以下两点原因：

1）执行javac时丢失了文件名和行号

为此我们在进行javac编译时要保留debug信息，如下所示：

-keepattributes SourceFile,LineNumberTable

2）执行混淆时丢失了文件名和行号

为此，我们要在ProGuard文件中增加以下语句：

-keepattributes SourceFile,LineNumberTable

感谢腾讯Bugly平台的“精神哥”在审阅本章的时候所提出的宝贵意见，关于Unknown Source的更详细介绍，请参见：http://bugly.qq.com/blog/?p=110 。

同理，对于测试人员使用的测试包，所使用的渠道号，也要与发到线上的渠道号区分开。

对于每晚跑Monkey的包，由此产生的Crash信息不应该上传到线上，存到测试机上即可。每天有人去排查Monkey日志即可。这样就避免了线上Crash数据中有太多的冗余数据。

接下来我们就对Android中的Crash逐一讲解，共计84个，分为10大类。