阿里妹导语:一行代码引发周边童鞋的Xcode内存爆炸。作为一名喜欢探究到底的工程师,岂能袖手旁观?来自高德的涛澜童鞋,给出了一个样本式的解决思路。下面就让我们一起走进“案发现场”。
问题描述:
自上上周起,团队中陆续有iOS开发抱怨电脑特别卡。有细心的同学发现,因为Xcode占用了约6-7G内存,而部分mac只有8G内存,所以内存爆满引起卡顿。
而部分同学的mac是16G内存的,比如我(嘲讽脸),因为内存充足没感觉到卡。
但这个问题影响团队的开发效率,所以需要去解决问题。
内存对比:
在沐浴更衣焚香、杀进程、清缓存后,分别拉取相邻的812版本代码和816版本代码分别编译,得到结论:
812调试时,占用2G内存
816调试时,占用6.8G内存
吐槽:
如果代码乱申请内存,那么内存爆掉的应该是模拟器或真机。而不该是Xcode
如果当前版本新增10w行代码(其实不到),对总代码量增长不超10%,Xcode内存怎么可能翻两翻。
所以我们觉得,这一定是苹果的锅,我们不背
但是不管是谁的锅,肯定是代码或者配置触发的,分析还要继续。
分析方法选择:
找代码:通过二分法,编译不同日期的版本,找到引发问题的那次提交,确定是哪个改动引起
找内存:分析增大的内存是什么,根据增大的内容分析问题出在哪。
如果使用方法1,编译一次代码需要15分钟,假设问题是某一行代码引起的,估计需要找一天。如果是某多行代码组合影响的问题,时间会更长。而且就算找到代码,也未必知道原理是什么。
所以我选择**方法2**,不行再退到方法1
分析步骤:
关闭Xcode后再打开,此时Xcode并没有run,所以推测他在做一件事:读缓存
缓存文件:
大家都知道,Xcode编译一个新工程会很慢,但是第二次编译就很快。那是因为他把编译结果存到了缓存文件中。第二次编译只读文件不编译自然就快了。
缓存文件存储在“/Users/你的用户名/Library/Developer/Xcode/DerivedData”目录下
812和816版本的缓存文件对比如下:
初步可以看出,缓存文件数量一致,但是大小差距很大。所以下一步就是来找茬:到底谁变大了
经过一番寻找,发现每个类会生成三个文件:
.o文件:二进制对象文件,不多说
.d文件:文本文件,记录该类依赖的所有文件路径
.dia文件:未知二进制文件,但是变大的就是它
.dia是有一部分变大了,一部分没变。尝试用二进制工具打开读了一下,有惊喜:
我的吐槽又来了:
继续分析:
那具体是什么导致的warning呢,面对几千个.dia文件,我内心是崩溃的。
问题虽解,但是遗留2个问题:
怎么就提交了107个warning?
区区107个warning。为啥会导致内存飙升?我们还剩几百个warning为啥没问题?
问题1:
问题2:
举个例子,有A B C三个类
A.m文件绝对路径
A.h文件绝对路径
A.m文件第几行引用了A.h,存在warning
warning在A.h的位置
warning描述是:pointer is missing a nullability type specifier (_Nonnull, _Nullable, or _Null_unspecified)
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的内存占用是可以理解的。
结论:
后续:
PS:这是苹果的bug么?我觉得还是自己挖坑把自己埋了。
遇到棘手的bug,你的解决思路是什么呢?欢迎在评论区留言,一起交流学习。
你可能还喜欢
点击下方图片即可阅读
阿里SRE体系如何支撑24小时峰值压力?
阿里人打车不给钱?内部自研神器“欢行”首次曝光
如何打造酷炫的高科技年会?六万阿里人为之尖叫
关注「阿里技术」
把握前沿技术脉搏