对待棘手bug，新手与大牛的差距在哪里？

导语：一行代码引发周边童鞋的Xcode内存爆炸。作为一名喜欢探究到底的工程师，岂能袖手旁观？来自高德的涛澜童鞋，给出了一个样本式的解决思路。下面就让我们一起走进“案发现场”。

​问题描述：

• 自上上周起，团队中陆续有iOS开发抱怨电脑特别卡。有细心的同学发现，因为Xcode占用了约6-7G内存，而部分mac只有8G内存，所以内存爆满引起卡顿。

• 而部分同学的mac是16G内存的，比如我（嘲讽脸），因为内存充足没感觉到卡。

• 但这个问题影响团队的开发效率，所以需要去解决问题。

内存对比：

在沐浴更衣焚香、杀进程、清缓存后，分别拉取相邻的812版本代码和816版本代码分别编译，得到结论：

• 812调试时，占用2G内存

• 816调试时，占用6.8G内存 

​吐槽：

• 对于这个数据，我们内心是拒绝接受的。有如下2点吐槽:

1. 如果代码乱申请内存，那么内存爆掉的应该是模拟器或真机。而不该是Xcode
2. 如果当前版本新增10w行代码（其实不到），对总代码量增长不超10%，Xcode内存怎么可能翻两翻。

• 所以我们觉得，这一定是苹果的锅，我们不背

但是不管是谁的锅，肯定是代码或者配置触发的，分析还要继续。

分析方法选择：

• 摆在我们面前有2个分析方法：

1. 找代码：通过二分法，编译不同日期的版本，找到引发问题的那次提交，确定是哪个改动引起
2. 找内存：分析增大的内存是什么，根据增大的内容分析问题出在哪。

• 如果使用方法1，编译一次代码需要15分钟，假设问题是某一行代码引起的，估计需要找一天。如果是某多行代码组合影响的问题，时间会更长。而且就算找到代码，也未必知道原理是什么。

• 所以我选择**方法2**，不行再退到方法1

分析步骤：

• 我在run的时候发现：

1. 812初次打开代码内存1G以内，编译运行时内存2G，关闭Xcode后再打开内存2G
2. 816初次打开代码内存1G以内，编译运行时内存6G，关闭Xcode后再打开内存6G

关闭Xcode后再打开，此时Xcode并没有run，所以推测他在做一件事：读缓存

缓存文件：

• 大家都知道，Xcode编译一个新工程会很慢，但是第二次编译就很快。那是因为他把编译结果存到了缓存文件中。第二次编译只读文件不编译自然就快了。
• 缓存文件存储在“/Users/你的用户名/Library/Developer/Xcode/DerivedData”目录下
• 812和816版本的缓存文件对比如下：

• ​初步可以看出，缓存文件数量一致，但是大小差距很大。所以下一步就是来找茬：到底谁变大了
• 经过一番寻找，发现每个类会生成三个文件：

  ◆ .o文件：二进制对象文件，不多说

  ◆ .d文件：文本文件，记录该类依赖的所有文件路径

  ◆ .dia文件：未知二进制文件，但是变大的就是它

• .dia是有一部分变大了，一部分没变。尝试用二进制工具打开读了一下，有惊喜：

• ​这不就是warning嘛

我的吐槽又来了：

• 是谁！站出来！**写了4个G的warning！**

继续分析：

那具体是什么导致的warning呢，面对几千个.dia文件，我内心是崩溃的。

• 幸好找基友沟通，刚好他做了代码warning扫描，发现816比812只是某组代码多了107个warning，其他组没变化，而且是nonnull相关warning，并不重要所以没追究。
• 我们找到107处warning的代码，查看提交记录，就是在大家反馈卡顿之前。貌似就是它了。我们把warning解了，clean重新编译，问题得解。

问题虽解，但是遗留2个问题：

1. 怎么就提交了107个warning？
2. 区区107个warning。为啥会导致内存飙升？我们还剩几百个warning为啥没问题？

问题1：

• 引发107个warning的只有一行代码
• 对于nonnull相关warning苹果的潜规则是这样的：

  ◆ 自Xcode6起提供的新功能，可以申明一个函数的参数是必传的(nonnull)还是可选的(nullable) ，这会让代码更严谨，我们是推荐使用的

  ◆ 兼容老代码：整个头文件都没有nonnull/nullable申明的，编译没毛病

  ◆ 对新代码高要求：只要给代码中添加了一个nonnull/nullable，剩余的代码也必须添加，否则其他每个接口就会有warning

• 所以，这次涉案的代码是个旧工具类，有107个函数。新增的一行代码添加了nonnull。于是产生了107个warning 

问题2：

举个例子，有A B C三个类

• A.h有一个warning，其.dia文件中会如下信息：

  ◆ insert '_Nullable' if the pointer may be null

  ◆ insert '_Nonnull' if the pointer should never be null

1. A.m文件绝对路径
2. A.h文件绝对路径
3. A.m文件第几行引用了A.h，存在warning
4. warning在A.h的位置
5. warning描述是:pointer is missing a nullability type specifier (_Nonnull, _Nullable, or _Null_unspecified)
6. fix的两种方法：

• 总之，一处warning的信息大约是1k
• 如果B引用了A，则B的.dia文件包含如上所有信息，以及多个B的文件路径，即B的描述信息超过A
• 如果C引用了B，而B在头文件中引用了A，则C的描述信息超过B

所以

• 在工程上，107warning的文件，dia约130k。
• 所有直接间接引用的文件数量大概2500，单个文件都超过130k。文件大小约350M。
• 加上模拟器有2个cpu架构（i386/x86_64），会生成2份文件，缓存中还有个聚合的dgph文件。以及文件在内存中结构化后占用的内存空间。
• 所以最终翻了几倍，达到4G的内存占用是可以理解的。

结论：

• 不要忽略warning，特别是头文件中的warning，会被多处引用导致过大的描述信息
• 头文件中尽量不要import头文件，会造成过度的引用，放大问题。

后续：

• 818版本已经fix了core中的所有nonnull问题。后续逐步将warning清零
• fix后内存占用如图 

​PS:这是苹果的bug么？我觉得还是自己挖坑把自己埋了。

关注「技术边城」把握前沿技术脉搏