1. 首先要根据实际情况，设置一些的crash相关指标，比如整体的crash rate不要超过0.2%, 某个crash影响的人数与数量，不要超过预期值。是的，我的意思是crash未必一定要修复，理论上大部分的都是可以修复的，但往往投入的精力与回报不成比例，也许我们可以把精力放在其它地方。另外就Android系统这碎片化的程度，各种兼容性问题太多太奇葩，我曾负责过一个crash顽疾整理工作，发现影响人数1~2个的一些Crash, 居然有超过4000种，尼玛我看都看不完，谈何一个个分析处理？
2. 根据crash的严重程度、影响范围，把值得修的问题都列出来，根据优先级逐个处理，新出现的crash理论上是都需要修复的。
3. 善用Google、stackoverflow, 耐心找找，大部分的问题别人也应该出现过，也头痛过，可能最终的现象不一样，但也许能在一些问题里找到蛛丝马迹。
4. 实在找不到的，也许是收集到的信息有限，可以补充收集更多信息，一些第三方crash收集分析平台，比如crashlytics，其实也支持上传Log, 在关键地方多打些Log, 尽量保存更多crash现场附近的信息，异常要处理好，经常是一些异常被不合理的吃掉了，导致问题被掩盖。
5. 还是不行就换个同事看看，别觉得丢脸，很多时候未必是水平问题，人很容易陷入到自己的思路里出不来。
6. 同事大牛都请教过了，还是没辙？二分大法好，看这个crash是哪个版本开始出现的，一点一点定位到具体版本，再一点一点定位到具体的change，这就要求持续集成与代码管理要做到位。我们有不少超级难搞的问题，就是这种方式解决的，这种比较适合有一定重现概率的问题，如果完全没头绪重现，也只能根据提交的change, 根据经验联想猜测其可能性了。
7. 如果还不行，只能用神器了，我的微信公众号里有介绍 《Appsee: 为什么叫它神器？》， 其中有个功能，可以直接查看每次crash之前用户都干了些啥，如果这还不能定位问题，有点说不过去吧。
Read full article from 难以定位的Crash怎么修？
No comments:
Post a Comment