对待棘手bug,新手与大牛的差距在哪里?

简介:

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

image

问题描述:

  • 自上上周起,团队中陆续有iOS开发抱怨电脑特别卡。有细心的同学发现,因为Xcode占用了约6-7G内存,而部分mac只有8G内存,所以内存爆满引起卡顿。
  • 而部分同学的mac是16G内存的,比如我(嘲讽脸),因为内存充足没感觉到卡。
  • 但这个问题影响团队的开发效率,所以需要去解决问题。

内存对比:

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

  • 812调试时,占用2G内存
  • 816调试时,占用6.8G内存


image


吐槽:

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

    • 如果代码乱申请内存,那么内存爆掉的应该是模拟器或真机。而不该是Xcode
    • 如果当前版本新增10w行代码(其实不到),对总代码量增长不超10%,Xcode内存怎么可能翻两翻。
  • 所以我们觉得,这一定是苹果的锅,我们不背

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

分析方法选择:

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

    • 找代码:通过二分法,编译不同日期的版本,找到引发问题的那次提交,确定是哪个改动引起
    • 找内存:分析增大的内存是什么,根据增大的内容分析问题出在哪。
  • 如果使用方法1,编译一次代码需要15分钟,假设问题是某一行代码引起的,估计需要找一天。如果是某多行代码组合影响的问题,时间会更长。而且就算找到代码,也未必知道原理是什么。
  • 所以我选择方法2,不行再退到方法1

分析步骤:

  • 我在run的时候发现:

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

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

缓存文件:

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


image

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

    • .o文件:二进制对象文件,不多说
    • .d文件:文本文件,记录该类依赖的所有文件路径
    • .dia文件:未知二进制文件,但是变大的就是它
  • .dia是有一部分变大了,一部分没变。尝试用二进制工具打开读了一下,有惊喜:


image

  • 这不就是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


image


问题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

      • 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的内存占用是可以理解的。

结论:

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

后续:

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


image

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

遇到棘手的bug,你的解决思路是什么呢?欢迎在评论区留言,一起交流学习。

来源:阿里技术
原文链接

目录
打赏
0
0
0
0
73529
分享
相关文章
编程中有没有遇到被自己蠢哭的BUG;想学go,有未来吗;如何保持持续学习的热情 |极客观点
编程中有没有遇到被自己蠢哭的BUG;想学go,有未来吗;如何保持持续学习的热情 |极客观点
140 0
当下做前端开发,不算简单,这篇文章可以让少走很多弯路以及需要掌握的知识
当下做前端开发,不算简单,这篇文章可以让少走很多弯路以及需要掌握的知识
赛博朋克首发Bug多,CDPR:旅程刚开始,已着手更新修复
赛博朋克首发Bug多,CDPR:旅程刚开始,已着手更新修复
346 0
赛博朋克首发Bug多,CDPR:旅程刚开始,已着手更新修复
如果你有拖延症,程序员不如试试这个技巧提升效率?
  要吃掉一头大象,每次吃一口。   ——克雷顿·艾布拉姆斯(Creighton Abrams)   造成拖延的首要原因之一,同时也是造成生产力低下的祸根,就是总是在感慨一个问题:好忙啊,问题好大啊……实际上,你并没有真正试着去解决问题。当我们从任务的全貌来审视任务的时候,它们看起来比真实情况都要大,并且更吓人。   在本文中,我会谈及一个能够帮助你克服拖延的提高生产力的窍门:分解任务。通过将大任务分解为小任务,你会发现自己更有动力去完成它们,也更加稳妥地向着目标前进。
178 0
影响程序员生涯的三个错误观念,你千万不要犯!
程序员在社会上,到底是怎样一个生活群体?是否能找到自己方向?其实,路一直都在那里,只是你看不到而已! 当初的你,可能一直被一些技术牵着鼻子走,并不是自己在做着自己想做的,而是被技术推到了现在这样子。
1259 0
强烈推荐|你不可不知的性能优化内幕
一. 基本概念 1. 软件系统质量特性 安全性:同时兼顾向合法用户提供服务,以及阻止非授权使用软件及资源的能力。 健壮、可靠:软件系统在一定的时间内无故障运行的能力、容错能力、恢复能力 可扩展、可维护、可移植:正在运行的软件系统以适应新需求、变化了的需求的难易程度 可用性、易用性、性能:性能是指软件及时提供相应服务的能力。
2023 0

热门文章

最新文章

相关实验场景

更多