iOS内存深入探索之内存用量

0.809字数 1413阅读 1570

前言

我们在查看iOS应用内存时,最常见的手法就是查看左边的Debug Navigator。不知你是否也曾困惑于这个内存究竟包括哪些部分,或者使用Allocations模版观察内存时发现无法和Debug Navigator显示的内存匹配上,这篇文章将带你解答这些疑惑。


Debug Navigator VS Allocations

我们运行一个很简单的iOS App,我只在ViewController中放置了一个View,然后对比下Debug Navigator 和 Allocations给出的内存用量。



可以发现,Debug Navigator给出的是79.3M,而Allocations统计的所有堆和相关VM加起来才38.72M,相差的还是很多的。在之前的文章中我有介绍关于AllocationsVM Tracker的深入理解,其实Allocations中主要包含的是所有MALLOC_XXX VM Region和部分App进程创建的VM Region。非动态的内存,以及部分其他动态库创建的VM Region并不在Allocations的统计范围内。比如主程序或者动态库的_DATA数据段,这些数据内存区域并非通过malloc分配,也就没有统计在All Heap Allocations中,所以你会发现All Heap Allocations往往会比较小。除非你自行使用malloc系列方法创建大内存块,否则很难看到All Heap Allocations有一个大的数值。我们在实际的App中,大的内存占用一般都是类似于WebKit,ImageIO,CoreAnimation等虚拟内存区域(VM Region),这些VM Region一般由系统代码生成和管理,我们编写的代码如果间接引用了这些内存而没有释放,也就会造成大面积的内存泄漏。

Debug Navigator VS VM Tracker

接下来我们来看看VM Tracker统计的内存如何,下面是截图。


在看VM Tracker时,我们主要看Dirty Size和Swapped Size,由于我是在模拟器上调试的,所以才需要关注Swapped Size,在手机上,主进程的内存应该是不会交换到硬盘上的,内存不足时,会触发内存警告。Dirty Size主要指的是不可被重新载入的内存区域大小,比如函数栈,如果你把函数栈的数据给抹掉了,也就无法恢复之前的函数调用栈数据了,这种可以称为Dirty内存区域,但如果是通过文件内存映射载入到内存区域的,可以先清除掉这部分内存里的数据暂时把这部分内存给别人用,需要时再从文件载入到内存,这种内存区域可以认为是非Dirty的。Dirty Size可以代表一个进程需求的最少内存量,当然在模拟器上,还要加上被交换出去的数据大小,即Swapped Size。
我们回到上图,VM Tracker给出的Dirty Size总量时69.79M,还是和79.3M有些差距。不过我们可在在图中看到_DATA数据段,Stack(函数栈)等等Allocations没有统计的内存区域。

Debug Navigator VS vmmap command line

苹果除了Instrument的VM Tracker可以查看虚拟内存之外,还有一个vmmap命令行可以查看进程的虚拟内存分配。使用模拟器启动App,通过Activity Monitor找到App的进程ID,比如1364,使用vmmap查看它的虚拟内存分配。

vmmap 1364 

结果如下

...
                                VIRTUAL RESIDENT    DIRTY  SWAPPED VOLATILE   NONVOL    EMPTY   REGION 
REGION TYPE                        SIZE     SIZE     SIZE     SIZE     SIZE     SIZE     SIZE    COUNT (non-coalesced) 
===========                     ======= ========    =====  ======= ========   ======    =====  ======= 
Activity Tracing                   256K      36K      36K      12K       0K      36K       0K        2 
CoreAnimation                     36.1M    33.3M    33.3M    2848K       0K    33.3M       0K        2 
Kernel Alloc Once                    8K       8K       8K       0K       0K       0K       0K        2 
MALLOC guard page                   48K       0K       0K       0K       0K       0K       0K       13 
MALLOC metadata                    260K      92K      92K      32K       0K       0K       0K       16 
MALLOC_LARGE                      4360K    4256K    4256K     104K       0K       0K       0K        3         see MALLOC ZONE table below
MALLOC_LARGE (empty)              3988K    2080K    2080K    1908K       0K       0K       0K        2         see MALLOC ZONE table below
MALLOC_LARGE metadata                4K       4K       4K       0K       0K       0K       0K        2         see MALLOC ZONE table below
MALLOC_NANO                       16.0M    2160K    2160K       0K       0K       0K       0K        3         see MALLOC ZONE table below
MALLOC_SMALL                      40.0M     840K     840K     356K       0K       0K       0K        3         see MALLOC ZONE table below
MALLOC_TINY                       8192K     320K     320K      36K       0K       0K       0K        3         see MALLOC ZONE table below
Performance tool data              316K     264K     264K      52K       0K       0K       0K        3         not counted in TOTAL below
STACK GUARD                       56.0M       0K       0K       0K       0K       0K       0K        4 
Stack                             9232K      76K      76K      20K       0K       0K       0K        7 
__DATA                            35.4M    16.6M    16.4M    12.3M       0K       0K       0K      282 
__FONT_DATA                          4K       0K       0K       0K       0K       0K       0K        2 
__LINKEDIT                        96.0M    69.5M       0K       0K       0K       0K       0K      225 
__TEXT                           228.3M    54.4M       4K       4K       0K       0K       0K      225 
__UNICODE                          560K     320K       0K       0K       0K       0K       0K        2 
mapped file                       28.7M    2116K       0K       0K       0K       0K       0K        3 
shared memory                       44K      24K      24K       8K       0K       0K       0K        5 
===========                     ======= ========    =====  ======= ========   ======    =====  ======= 
TOTAL                            562.9M   185.8M    59.3M    17.5M       0K    33.4M       0K      786 

我们将Dirty Size和Swapped Size总量相加59.3M + 17.5M = 76.8M,和Debug Navigator给的值已经很相近了,我们再看上面的表格,发现有一行是这么写的Performance tool data ... not counted in TOTAL belowPerformance tool data并没有统计在最下面的TOTAL中,因为这些数据是Debug时提供调用回溯数据用的,所以vmmap默认认为没有价值,没有统计。但是Debug Navigator不这么认为,我们加上Performance tool data的内存用量,264K + 52K = 316K = 0.308M,加上之前的76.8M就是77.108M,由于本次并没有使用Instruments进行profile,所以占用的内存会少一些,Debug Navigator显示的刚好是77.1M。至于为什么vmmap显示的数据要比Instruments VM Tracker的要完整,目前我还没有明确的答案。

shared memory

最后我要提到的时共享内存,共享内存可以提供跨进程访问的能力,不过如果你的App使用了别的进程创建的共享内存,那么Debug Navigator是不会将它计入你自己的内存总量的,不过vmmap会将它加入TOTAL中,所以可能会导致vmmap计算的内存量会大于Debug Navigator统计内存量。由于目前iOS对于shared memory的一些API并不支持,我也没有深入研究,只是在OSX中验证了这一点。

总结

最后来总结一下,Debug Navigator其实就是统计了当前进程的所有虚拟内存的Dirty Size + Swapped Size,当然还要剔除掉对第三方共享内存的使用量,当我们发现Debug Navigator的内存量飙高时,不仅仅要去关注Heap上的内存用量,更要关注VM Tracker中那些大Dirty Size的VM Region,这样才能更透彻的了解你的App究竟是怎样使用内存的。

推荐阅读更多精彩内容