说说iOS与内存管理(中)

接着上文简单整理下iOS常见内存问题及排查相关的工具和方法。

上篇日志是6月份写的,由于工作的内容比较丰富,这么久一直没能更新blog,有点小遗憾,这是到这是2015年8月最后一天,趁着8月还没过,赶快把这篇补上。

0. 内存工具

针对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期待和试用下,也许它真得能帮我们解决好多问题!

1 1 收藏 评论

相关文章

可能感兴趣的话题



直接登录
跳到底部
返回顶部