降低Crash率的正确姿势

红袖读书是ReactNative架构的工程,从第一个版本7.0.0到7.1.0,Crash率一直维持2%上下。公司其他RN和非RN的新项目Crash也是如此。在紧张的项目迭代中,我们花时间处理一下Bugly上的Crash,经过7.2.0和7.3.0两个版本的迭代,10w+日活的情况下已经稳定在0.5%上下。

二八定律:
采取的措施简单粗暴,遍历Bugly上的每一个Java异常,处理完后标记完成。Native层的Crash暂时忽略,然后根据二八定律,优先解决Crash多的问题。

一个也别放过:
解决主要Crash以后,还有一个原则,即使一个Crash只发生一次,也需要处理,防止用户量增大以后Crash增加。

正确的Catch姿势:
Crash的处理包括找到问题的真正原因,纠正逻辑或者代码错误。也包括极端情况的catch。catch的异常还需要进行,异常处理。例如catch了oom,可以执行trimMemory降低内存,然后再次尝试。

第三方问题:
项目中使用到了较多的第三方库,例如GrowingIO、ExoPlayer、TTS等,接入时或多或少会增加一些Crash。一些是使用问题,处理还比较方便。一些是第三方库自身问题,就头疼了。可以尝试一些Hook的黑科技,如果行不通,只能向第三方提issue。

预防:
由于公司测试资源有限,开发成员也有新手,所以对代码的Review也是非常重要的手段。当然这是最累的一环。毕竟通常Review的目的不是为了找bug。

花费:
Android团队三个人力,一月一个大版本迭代,花费在Crash上的时间为1个人力1天的时间。也就是其中一个人花一天时间,处理Bugly上当前版本所有的crash。一个版本的Crash少的30多页,多的时候50页以上,一页10条。其中大部分都是Native层的SIG信号异常,所以还算轻松,一天8小时足矣。

以上。