Question

不是所有的Crash都能找到原因，比如说内存爆了，也就是OOM，但是表现为其他的症状，也有可能是混淆的问题。

对于线上的Crash，我们要本着“为什么开发期间没有发现”的思路来进行修复，调试期间没有问题但是到了线上就有问题了，原因有几种：

·测试不充分，有些场景没有考虑到。

·服务器返回给App的数据不规范，而App又没做容错处理。恰恰测试时数据是没问题的，上线后服务器返回的数据不规范，就会有各种崩溃。

·也有可能是在线上调试，没写好的代码抛出来的异常。这种Crash永远不会重现。我们需要排除这样的Crash，否则会浪费大量的人力在上面。

其实，很多线上Crash都是无厘头的，让人无从下手修复。我在这里教大家一种简单有效的办法，那就是发现这样的线上Crash，在出错的代码行加上try…catch…语句，专门捕获这种异常。记得在catch语句中将这次异常发送到服务器，并把crash_type标记为0（线上Crash的这个值为1），这样我们就能在每天几千个Crash中捕获到一些，而阻止应用不崩溃了。

当我们捕获到这种异常，尽量不要让程序崩溃，而是退回到上一个页面，请用户重新操作一遍。之前的操作可能会因为各种各样的原因而引发异常，重新操作一遍能极大减少这种情形。但如果每次退回后重新操作还是这种崩溃，那么就要重点对待了，有可能是MobileAPI脏数据，有可能是某款机型不兼容，有可能就是一个代码上的bug，具体情况具体分析。

6.9.1　内存溢出

异常中的关键字：

OutOfMemoryException

发生频率：★★★★★

我们时常抱怨Android系统为每个App分配的内存太小，只有几十兆，殊不知在AndroidManifest.xml中有个参数可以设置：

<application android:largelHeap="true"

这样就能增加系统为当前App分配的内存了，甚至到100MB以上。使用后，OOM的崩溃明显减少很多。

但是，天底下没有免费的午餐。当内存很大的时候，每次GC的时间也会长一些，性能就会下降。Android官方给的建议是，作为程序员的我们应该努力减少内存的使用，使用回收和复用的方法，而不是想方设法增大内存。

6.9.2　Verify Failed

异常中的关键字：

java.lang.VerifyError:Rejecting class xxxx.package.activityA that attempts to sub-class erroneous class xxxx.package.Activity基类

发生频率：★★★★

这个问题至今没有查到原因。