两次release包才出现的bug的解决过程记录

最近两个月遇到了两个特别棘手的bug，有一些共同点：

只在release包会出现

概率出现

基本都用了2-3天才解决，算是遇到的比较难解的bug，这里记录一下。

BUG 1

表现是iOS所有系统下，在release包下，无规律卡死。不管在app的哪个页面都会概率性卡死。中间尝试了很多，最后总结一些有效的解决过程：

看看能否调试：因为是release包，先找一下有没有可能连着xcode调试release包（尝试了各种办法，比如通过打adhoc包，然后attach process，最终均以失败告终），但是这个肯定是正常思维要考虑的方法，并且BUG2只能通过走这条路去发现问题，稍后详细说明。

定义评判标准：不能调试，只能通过打包验证的方法，并且概率性出现的bug。那么必须先找到bug出现的规律，否则之后没有办法判断一个包是否有问题（如果一个包用了一会没有问题，你也不能自信的说bug已经解决了）。通过对于有问题的包的大量使用，发现在某个页面来回的切换前后台最有可能复现bug，基本每次切换3-4次就会卡死。那么我们就有了一个问题解决的标准：如果在这个页面来回切换前后台10几次都没有问题，就可以认为bug已经解决，可以给测试同学再全面的验证一下。

尽量缩小目标：每次打包时间至少10分钟，打包的代价是很高的，每次修改的代码一定最好要能体现问题，最开始，我对于最可疑的代码进行修改，然后打包。可惜不是这些代码的问题。但是这步肯定是必要的。

地毯式搜索解决问题：此时我们处于茫然阶段，完全不知道是什么代码导致的。但是我们知道什么上一次线上版本是好的。目前也没有别的办法了，打开source tree，导出从上次发版，到这次发版所有的git commit，大概有400多个，就是这400多个commit中的某个commit导致这个bug，我们当时不是一个一个commit打400个包去验证。通过二分法，先看200有没有问题，如果有，那么则关注100，如果没有则关注300，这样很快就可以定位有问题的commit，其实只需要打9-10个包就可以找到存在问题的commit了。2的9次方是500，就可以定位了。每次打包验证的时间差不多15分钟，这样，最后花了几小时时间找到了有问题的commit。

上面描述的解决过程，导致BUG的原因其实在fmdb数据的某个方法加了一个bool的方法值，就出现了这个问题，比较重要的解决问题的方法，至于为什么增加了一个返回值，就在release包下不定时卡死，这个问题本想找时间看看，没想到很快遇到了BUG2。也正好解答了BUG1剩余的这个问题。

BUG2

表现是iOS11下，使用某个功能特别容易卡死。下面是解决的过程：

没有考虑是否能否调试release包，因为之前已经尝试过很多次失败了

定义评判标准：通过大量使用，确定了一种使用过程必将导致问题的出现。

对于最可疑地方进行修改，重新打包，验证依然不行

想看下从哪个版本开始有点问题：结果发现一年前的包，在iOS11上依然会有问题。所以也没法地毯式解决问题了。

差不多绝望的时候，把中心转向了步骤1，因为遇到的这个问题，不能调试完全没有头绪是哪出的问题。所以花了很多的时间查询如何调试release。最后依然没有成功，所以目前认为release包是无法调试的。但是换个角度考虑问题：是什么导致的debug和release包的行为不同呢，最后找到了一篇文章提到XCode的一个编译选项：Optimization Level，这个是build debug包和release包时优化的等级，一共分6个等级，越高等级优化的约多，代码效率越高，包越小。对于写的不合理的代码，高等级的优化也会导致一些未知的问题。debug一般选择的是最低的level，release选择的一般是第二高的level。当时想能否把release的优化等级改为debug一样的等级，然后打出来包，能通过Xcode attach process上调试，但是依然不行，哈哈，但是竟然发现，这样打出来的包，就没有问题了，所以判断是这个编译设置导致的问题。再反转下思路，那么我把debug的等级调高成和release的一样，是不是就会出现问题呢，调整之后，果然debug包也出现了问题，并且可以调试了！！之后找到问题就很快了。

其实是对于sql的参数需要传4个，但是我们传了3个，第4个没有用当时就没传，之前一直没有问题，也就没有发现。但是iOS11之后，肯定调整了不同的Optimization Level下的优化策略，开始出现了这个问题。同样BUG1只在release包有问题，也是这个原因。

总结：

如果只在release包下出问题，看看调整Optimization Level之后，debug下能否出问题，如果问了问题，就可以调试了，如果没问题，就只能参考上面其他的方法，打包验证。

代码还是要规范写好，debug没问题不代表release没问题，今天没问题也不代表以后没问题。

交给测试的还是要多测测release包，或者修改下Optimization Level，试试debug包。