Facebook 的 iOS 内存泄漏监测自动化实践

内存是移动设备上的共享资源，如果一个 App 无法正确地进行内存管理的话，将会导致内存消耗殆尽，闪退以及性能的严重下降。

Facebook 的 iOS 版本的许多功能模块共用了同一份内存空间，如果其中的某一个模块消耗了特别多的内存资源的话，将会对整个 App 造成严重影响。举个栗子，当某个功能模块不小心造成了内存泄漏的时候，这个情况就很有可能会发生。

在 Facebook，我们有非常多的工程师同时在一个代码仓库下进行并行开发。内存泄漏是在开发过程中难以避免会遇见的问题。当内存泄漏发生时，我们就需要快速地去发现然后修复它。

现在已经存在一些开发者工具来辅助发现内存泄漏了，但是它们的共同点是需要大量的人工操作：

打开 Xcode 并选择 build for profiling 来编译你的工程
打开 Instruments 工具
尝试在你的应用上尽可能多地重现更多的场景与行为
观察内存工具的走势图
找到内存泄漏的源头
修复它！
这样的人工排查与修复工程每次都得不断地重复操作。正因为如此，我们很难在迭代阶段早期就定位与修复内存问题。

将内存泄漏的排查过程尽可能地自动化，减少开发人员的人工干预，可以帮助我们更快地去找到内存泄漏的地方。为了解决这个问题，我们已经在内部开发了一套工具来帮助我们自动化这个排查过程，并且已经帮助我们解决了许多代码中存在的内存泄漏问题。今天，我们很高兴向大家宣布我们正式开源这套内存泄漏排查工具：FBRetainCycleDetector，FBAllocationTracker 和 FBMemoryProfiler。

循环引用
Objective-C 使用引用计数来管理内存与释放未被引用的对象。内存中的对象 A 可以让对象 B 的引用计数加一，即 retain，来使对象 B 尽可能久地存在内存中（只要对象 A 不对它“减一”，即 release）。也就是说：对象 A 持有了对象 B 。

大多数情况下，引用计数这套机制都可以运作得很好。但是，当两个对象直接地，或者更常见的情形是通过某些对象间接地，互相持有了对方，这个时候就陷入了僵局了。这种互相持有对方的引用的现象叫做循环引用。



循环引用会导致一系列的问题。最好的情况是，泄漏的对象本身就会一直长期地占用内存空间，这种情况一般不会造成太大的内存消耗。如果泄漏的对象不停地增加与积累，那么 App 中其他功能模块所能使用的内存就会减少。最坏的情况则是，内存泄漏导致了 App 需要使用的内存超出了限制，这时应用就会闪退了。

阅读全文请点击： http://click.aliyun.com/m/9168/