Android 复杂项目崩溃率收敛至0.01%实践

主要观点总结

本文主要介绍了针对Android应用中各类崩溃问题的收敛方法和实践，包括崩溃白名单、空指针问题、并发修改异常、数据库问题等，以及OOM问题的监控和收敛。同时，也介绍了线程数量和FD数量的监控方法。

关键观点总结

关键观点1: 崩溃收敛机制

创建opt分支修复线上崩溃和业务逻辑BUG，使用Handler机制进行崩溃容灾，拦截常见崩溃类型，如NullPointerException、IndexOutOfBoundsException、ConcurrentModificationException等。

关键观点2: OOM问题收敛

介绍OOM的问题和产生条件，通过KOOM进行内存泄露监控，使用浮窗实时显示APP当前总体内存和线程数量，以及通过代码获取FD数量。

关键观点3: 其他崩溃收敛

针对空指针问题、数据库问题等其他常见崩溃场景，提供解决方案和排查手段。

关键观点4: 总结

介绍如何通过前期的代码审查和工具扫描来降低线上问题的发生概率，并推荐相关工具和实践经验。

文章预览

1 崩溃收敛机制 创建修BUG分支 在我们的项目中，每个版本发布之后，我们会创建一个opt分支，用于修复线上崩溃以及业务逻辑BUG。 开发过程中，一个APP可能同时并行开发多个需求，每个需求上线的预期时间可能会有不同。但是这个opt分支我们会保证在下个版本一定上线，QA同学也会在每个版本发布前预留测试opt分支的时间。 每天早晨查看Dump后台 每天上班第一件事就是查看DUMP后台，收集昨天线上发生的DUMP崩溃，具体的堆栈分配给对应的业务负责人。 业务负责人收到崩溃之后，会优先跟进排查。排查下来如果相对好修复，会第一时间直接修复掉，并提交到opt分支。如果排查下来发现，较难定位或者耗时较久，则需要给出修复预期。也可以将Bug转为技术优化，作为专项推进。因为确实有一些Bug需要通盘考虑，所有业务配合。 2 崩溃容灾机制 背景 我 ………………………………