通过第三方统计所搜集的错误信息应该如何准确的修复?

公司项目嵌入了第三方的错误统计SDK,隔一段时间去查看会发现不少的错误信息,能够定位到具体的界面,但是很少有机会重现那个bug,查看前后的代码逻辑也没…
关注者
28
被浏览
980
登录后你可以
不限量看优质回答私信答主深度交流精彩内容一键收藏

这类问题确实存在,总会有一些所谓顽固crash难以修复,用户量级越大,这类问题越多。

我曾被安排专门去处理这些顽疾,简单谈几点吧:

1. 首先要根据实际情况,设置一些的crash相关指标,比如整体的crash rate不要超过0.2%, 某个crash影响的人数与数量,不要超过预期值。是的,我的意思是crash未必一定要修复,理论上大部分的都是可以修复的,但往往投入的精力与回报不成比例,也许我们可以把精力放在更合适的地方。另外就Android系统这碎片化的程度,各种兼容性问题太多太奇葩,我刚接手那个crash顽疾整理工作时,发现影响人数1~2个的一些Crash, 居然有超过4000种,尼玛我看都看不完,谈何一个个分析处理?

2. 把值得修的问题都列出来,根据优先级逐个处理。

3. 善用Google, 耐心找找,很多问题应该别人也出现过。

4. 实在找不到的,也许是收集到的信息有限,可以增强一些信息收集,一些第三方crash收集平台,其实也支持上传crash现场附近的Log, 在关键地方多打些Log, 异常要处理好,经常是一些异常被不合理的吃掉了,导致问题被掩盖。

5. 还是不行就换个同事看看,别觉得丢脸,很多时候未必是水平问题,人很容易陷入到自己的思路里出不来。

6. 同事大牛都请教过了,还是没辙?二分大法好,看这个crash是哪个版本开始出现的,一点一点定位到具体版本,再一点一点定位到具体的change,这就要求持续集成与代码管理要做到位。我们有不少超级难搞的问题,就是这种方式解决的,这种比较适合有一定重现概率的问题,如果完全没头绪重现,也只能根据提交的change, 根据经验联想猜测其可能性了。

7. 如果还不行,只能用神器了,我的微信公众号里有介绍

Appsee: 为什么叫它神器?

其中有个功能,可以直接查看每次crash之前用户都干了些啥,如果这都不能定位问题,有点说不过去吧。

很多时候即便知道了原因,也未必能修复,有时候真是系统或者环境的坑,有时候可以换个实现方式或设计避开它,总之crash要尽量先定位出原因,之后怎么处理大家就各想各招吧,尽量用一些优雅简洁的方式去处理它。

另外可以使用一些静态分析工具,提前发现代码中的各种隐患,比如Lint, Find Bugs等等,平时养成良好的编码习惯,模块之间不要牵连太多,充分解藕,规范异常处理、仔细考虑各种分支异常场景,不要偷懒,多打些Log,单元测试能做好就更好了(我的公众号里也有介绍单元测试的文章,大家可以参考)。这样一方面可以提前发现问题,另一方面也可以在问题出现时轻松定位。

最后想提一下,这种难以重现的顽疾,对测试与开发都是挑战,很多时候需要大家通力合作才能有好的结果,切忌互相推诿,毕竟大家的最终目标是一致的。