*****阅读完此文,大概需要3分钟******
关于Memory leak(内存泄漏)的问题,如果是面试被问这个问题以及此类问题,主要涉及下面3个方面:
内存泄漏的常见场景有哪些,列举几个常见的例子?
开发中实际发生了内存泄漏,该如何定位与解决?
开发中该如何避免内存泄漏,有哪些方法?
下面我们就分别从这个3个方面进行总结。
Memory Leak的常见场景
1. 循环引用
ARC机制下,循环引用是导致内存泄漏的一个主要原因,它也分为很多具体的场景,例如:
两个类对象之间的循环引用;
Block中的循环引用问题(包括GCD或其他系统Block等);
Timer的循环引用问题;
delegate带来的循环引用问题;
属性观察、监听类等场景;
2. 对象生命周期管理(持有)不当
这种需要结合实际业务问题来分析,例如,
Static字段或其他全局对象导致的持有不当引起内存泄漏。
集合类等的引用关系不当或未及时释放等。
3. 对象的未及时释放
有些对象需要手动释放内存,例如 Core Foundation(CF)和 Core Graphics(CG)框架的对象。如果不及时释放这些对象,就可能导致内存泄漏。
4. 资源的未及时关闭或释放
资源类未及时关闭(或未释放)也是一种常见的内存泄漏场景,例如:
文件的打开后(FileHandle),未及时Close。
网络请求的URLSession对象未及时释放。
Memory Leak该如何定位与解决
其实找到问题点后,基本很好解决,例如:
循环引用就想办法利用weak来打破循环;对象的生命周期不当可以更换持有者或者需要重新设计代码;CF或CG类的对象需要手动释放;资源类的占用也需要及时手动释放等等。
但是问题主要难在怎么找到泄漏代码。
1. 手动调试法
当我们意识到发生泄漏时,一般都会有明显的表象,例如VC Pop失败等。
如果我们对代码很熟悉,一般情况下,我相信很多人会直接找代码进行手动调试。常见手段有:
重写dealloc或者deinit方法
我们可以尝试在一些类的dealloc或者deinit方法中断点或者加log,没有预期的执行,则为嫌疑泄漏点。
手动检查引用计数
手动检查对象的引用计数,可以帮助我们找到是否存在引用计数错误导致的内存泄漏。我们可以使用 Objective-C 或 Swift 中的 retainCount 属性来手动检查对象的引用计数。
写一些辅助测试代码
如果内存泄漏点比较隐晦,可以通过写一些测试用例的代码来复现,例如连续循环9999次,把问题扩大,引发内存耗尽崩溃的Crash,再根据堆栈定位代码,这也是定位概率性Crash的常用手段;
逐一排查法
逐一注释掉问题的代码,直到发现问题点所在。开发中排查Crash问题,也常用类似手段,虽然看似很Low,但是十分有效。
2. 工具类定位
这种有很多可以借助,例如:
Instruments工具箱,其中的Leaks工具或者内存调试器Analyze来分析;
Xcode Memory Debugger中的Memory Graph,
可以帮助我们分析对象的内存引用关系,并找到循环引用和内存泄漏。
第三方的检测工具,
例如MLeaksFinder、FBRetainCycleDetector、LeakDetector、HeapInspector等。
静态分析工具,
例如 Clang 静态分析器、Infer、OCLint、SwiftLint等工具。
这些工具一般是附带性发现一些内存泄漏的代码,可以给我们一些提示或者警告。
如何避免Memory Leak?
实际开发中,不大可能,写段代码就跑一下Instruments这些工具,就连一些MLeaksFinder这些经常误报的工具都嫌烦会直接关闭。
那我们该如何避免,尽可能降低问题代码的产生?
第一,要有一些风险意识。例如Timer既然选择它,就该知道它的最大的风险就是容易导致内存问题。将一些容易导致泄漏的场景烂熟于心。还例如,谨慎使用全局变量或者单例等。
第二,要养成一些习惯。例如,写完一段代码或者接收一段代码,在dealloc或deinit中断点,保证对象可预期释放。还例如Swift中尽可能采取值类型,而非引用类型;开发完自测时,把一些内存检测工具都打开作为辅助检测;
第三,做好系统设计。有些业务场景很容易产生泄漏,例如曾经我参与过一个直播业务的开发,房间VC与房间的唯一数据模型对象dataModel之间很容易相互引用,由于dataModel承载了很多业务基础信息,业务对这个dataModel都极其依赖,这个对象也因此被传的很深很广,一个不小心就发生循环引用。针对这种开始的设计不当,后面只能打补丁修复(维护一个dataModel弱引用集合,每次用时根据id去查询并获得对应房间的dataModel对象,业务之间只需维护一个id的String对象或者存储最少信息的字典对象即可)。类似的业务场景还有商品详情页等。
第四,定时给工程代码做“体检”,一般工程量较大时,这个十分有必要,跑一下Instruments或Memory Graph,几乎每次都有收获。
欢迎关注公众号ios_hunter,不要错过更多优质文章更新。