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

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