当前位置: 首页 > 工具软件 > Leak Hunter > 使用案例 >

iOS开发笔记之九十八——关于Memory Leak总结笔记

方高丽
2023-12-01

*****阅读完此文,大概需要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,不要错过更多优质文章更新。

 类似资料: