分享一个IPhone bug的分析过程(兼xcode编译器应该改进的地方）

核心提示：既然第三方的库也没有问题，那看来是我们自己代码的问题了，分享一个IPhone bug的分析过程(兼xcode编译器应该改进的地方）(2)， 没有什么太好的办法，我只好把我们的代码一个个文件从项目中剥离，应该在链接的时候报错，否则在运行时是很难去定位bug的，验证bug是否重现，运气不太好

既然第三方的库也没有问题，那看来是我们自己代码的问题了。 没有什么太好的办法，我只好把我们的代码一个个文件从项目中剥离，验证bug是否重现。运气不太好，当我剥离到最后两个文件时，才确认bug是出在那两个文件里。 这里也顺便提一下，保证项目中文件结构和依赖层次的清晰是非常重要的。比如A依赖B，B依赖C，C又依赖A，那在剥离的时候就很难下手。

Bug的root cause:

最后的bug出在Queue.h 和Queue.m中，这是我之前写的一个通用的Queue类(Objective-c 不提供Queue和Stack)。在Objective-C 中有Category的概念，跟C#中的partial class 概念类似，就是一个类的定义可以在两个文件中。这样就可以已这种方式对已有的类进行扩展，比如添加你自己的方法。我的Queue类 就是在Array类的基础上 加了pop和push两个方法，悲剧的是，在UINavigationController(IPhone导航)的实现里，它内部是用一个stack来维护每个导航页面，而这个stack的实现方式我猜跟我实现Queue一样，也是扩展了Array类，它也取名叫pop和push，两者发生冲突。 我把push跟pop改为 enqueue和dequeue，问题解决。

@interface NSMutableArray (QueueAdditions)

- (id)pop;

- (void)push:(id)obj;

@end

结论：

不要轻易怀疑SDK或者编译器。 对于一些莫名其妙的bug，起初怀疑时系统的问题，往往还是你自己代码的问题。

大胆假设，小心求证。对于所有难解的bug，从现象出发，根据你的经验假设问题的所在，然后一步步验证，抽丝剥茧，最后总能找出问题所在。

另外的一个结论是， Apple 应该对编译器做改进，在Category(partial class)里对重名的symbol，应该在链接的时候报错，否则在运行时是很难去定位bug的。

黄锦 Email: hj@s-tuan.com 关注移动互联网，电子商务