iOS与内存管理

内存工具

针对iOS开发，我们所能使用的内存排查工具选择其实并不算特别多。最主要的调试工具就是Instruments。然而，如果仔细探查细节，Instruments还是集成了很多不错的调试模板/Library的。

本文针对如下几类应用场景，对通用的调试方法做基本介绍：

• 最基本最常用的内存问题场景——内存泄露、过度释放

• malloc相关的堆内存分配问题排查相关工具

• 其它内存工具

• 
  

1. 内存泄露与过度释放

我们应该都知道，iOS开发过程中，使用Objective-C分配的堆内存都是通过引用计数来做保留和释放的。一块内存初始分配，引用计数为1，此后每新增一个强引用，引用计数增加1；释放正好相反，每一次release，引用计数减1，直到为0，对象所用内存被真正free掉，以被再次复用。然而，实际开发当中，总有一些原因导致引用计数无法按正常逻辑减少到0，或者减少到0之后仍然被调用release，前者是内存泄露，后者则是过度释放。

当内存泄露发生时，运行的App不会直接第发生明显问题，但废弃内存得不到回收，在长时间持续运行后，App进程会由于可用内存不断变低而被kill或带来其它隐患。

避免内存泄露，首要是有良好的代码习惯，避免循环引用、会用weak，其次可以通过Analyze来进行静态代码检查，以发现在语法上显而易见的内存泄露问题。但更多时候，内存泄露是运行时的问题，这时可用Instruments中的Allocation和Leaks来不断重复操作App，发现和定位内存泄露点。

当运行时发生显示内存泄露时，Leaks会在时间轴上标出红色指示线，同时在Instruments的下方会列出调用细节，结合系统提供的malloc历史，其中包含引用计数变化情况，以及调用栈可以很直接地找到泄露原因。

同时对于一些“隐式”的情况，需要反复操作，同时观察Allocation中只增不减，一直创建新对象而不释放老对象的情况。

过度释放，是对同一个对象释放了过多的次数，其实当引用计数降到0时，对象占用的内存已经被释放掉，此时指向原对象的指针就成了“悬垂指针”，如若再对其进行任何方法的调用，（原则上）都会直接crash（然而由于某些特殊的情况，不会马上crash）。

对于这种问题，可以直接使用Zombie，当过度释放发生时会立即停在发生问题的位置，同时结合内存分配释放历史和调用栈，可以发现问题。

至于上文提到的不会crash的原因，其实有很多，比如：

• 对象内存释放时，所用内存并没有完全被擦除，仍有旧对象部分数据可用

• 原内存位置被写入同类或同样结构的数据

2. malloc库提供的相关工具

上一段提到，对象释放时，所用内存并没有完全被擦除，仍有旧对象部分数据可用，如果不使用Zombie调试，App可能不会直接crash。对付这种情况，其实很简单，可以在对象内存释放时写入无意义数据，如0×55，0xaa等，而系统已经帮我们做了这个工具，那就是Scribble，在Xcode的Edit Scheme里，Diagnostics Tab下勾选Enable Scribble。

Scribble其实是malloc库（libsystem_malloc.dylib）自身提供的调试方案，除了Scribble，malloc还提供了很多其它的调试工具/方案，在Diagnostics Tab下你应该都看到了。其实，malloc可用的工具还不止这些，通过环境变量至少还可以添加如下调试参数：

• MallocLogFile

• MallocGuardEdges

• MallocDoNotProtectPrelude

• MallocDoNotProtectPostlude

• StackLogging

• StackLoggingNoCompact

• MallocCorruptionAbort

• MallocNanoZone

• MallocCheckHeap

其中，有几个参数是和记录分配历史的日志有关的。

除此之外，Xcode里还提供了Guard malloc，这个是等同于默认malloc库功能的另外一个调试库，为了定位大内存越界访问问题，不过只能在模拟器上使用（个人分析是因为真机根本承受不起保护页内存消耗）。

对以上参数的实现细节感兴趣的，可以参看苹果开放出来的malloc源码。

3. 其它

下面我还想对Instruments里的三样东西做简要介绍：

• Allocation

• Activity Monitor

• VM Tracker

Allocation针对堆内存及匿名映射的情况提供了详细的数据，包括某类对象有多少个，对象的具体地址，占用多大内存等。通过Allocation，可以对我们开发中实际接触到的内存有非常全面的把握。

Activity Monitor则从系统的层面，对主要进程的CPU、内存、网络等数据做分析。从内存方面看，我们可以知道占用系统内存最大的5个App，它提供的数据包含了实际物理内存和虚拟内存部分。

VM Tracker则可以告诉我们哪些部分是Dirty的，Dirty的数据系统不会直接清理掉，因为这些数据是被写过的，无法通过外部存储直接生成，只能维持在内存当中。此外，通过VM Tracker我们还可以看到Region Map，看到进程地址空间各部分的映射情况。

除了上面提到的这些，对于诡异的内存问题，我们可以对Xcode7中的Address Sanitizer期待和试用下，也许它真得能帮我们解决好多问题！