iOS内存分配：虚拟内存

计算机系统

物理内存

一个设备的 RAM 大小。以下是维基百科上的资料：

简单来说，iPhone 8（不包括 plus） 和 iPhone 7（不包括 plus）及之前都是 2G 内存，iPhone 6 和 6 plus 及之前都是 1G 内存。

虚拟内存(VM for Virtual Memory)

什么是虚拟内存

当我们向系统申请内存时，系统并不会直接返回物理内存的地址，而是返回一个虚拟内存地址。从系统角度来说，每个进程都有一个自己私有的相同大小的虚拟内存空间。对于32位设备来说是4GB，而64位设备（5s以后的设备）是 18EB(1EB = 1000PB, 1PB = 1000TB)，映射到物理内存空间。

只有当进程开始使用申请到的虚拟内存时，系统才会将虚拟地址映射到物理地址上，从而让程序使用真实的物理内存。

获取App申请到的所有虚拟内存：

- (int64_t)memoryVirtualSize {
    struct task_basic_info info;
    mach_msg_type_number_t size = (sizeof(task_basic_info_data_t) / sizeof(natural_t));
    kern_return_t ret = task_info(mach_task_self(), TASK_BASIC_INFO, (task_info_t)&info, &size);
    if (ret != KERN_SUCCESS) {
        return 0;
    }
    return info.virtual_size;
}

Clean Memory

可以简单理解为能够被写入数据的干净内存。对开发者而言是read-only，而iOS系统可以写入或移除。

• System Framework、Binary Executable占用的内存
• 可以被释放（Page Out，iOS上是压缩内存的方式）的文件，包括内存映射文件Memory mapped file（如image、data、model等）。内存映射文件通常是只读的。
• 系统中可回收、可复用的内存，实际不会立即申请到物理内存，而是真正需要的时候再给。
• 每个framework都有_DATA_CONST段，当App运行时使用到了某个framework，该framework对应的_DATA_CONST的内存就由clean变为dirty了。

注意：如果通过文件内存映射机制memory mapped file载入内存的，可以先清除这部分内存占用，需要的时候再从文件载入到内存。所以是Clean Memory。

Dirty Memory

主要强调不可被重复使用的内存。对开发者而言，已经写入数据。

• 被写入数据的内存，包括所有heap中的对象、图像解码缓冲(ImageIO, CGRasterData，IOSurface)。
• 已使用的实际物理内存，系统无法自动回收。
• heap allocation、caches、decompressed images。
• 每个framework的_DATA段和_DATA_DIRTY段。

iOS中的内存警告，只会释放clean memory。因为iOS认为dirty memory有数据，不能清理。所以，应尽量避免dirty memory过大。

Clean和Dirty示例

int *array = malloc(20000 * sizeof(int)); // 第1步
array[0] = 32                             // 第2步
array[19999] = 64                         // 第3步

• 第一步，申请一块长度为80000 字节的内存空间，按照一页 16KB 来计算，就需要 6 页内存来存储。当这些内存页开辟出来的时候，它们都是 Clean 的；

• 第二步，向处于第一页的内存写入数据时，第一页内存会变成 Dirty；

• 第三步，当向处于最后一页的内存写入数据时，这一页也会变成 Dirty；

Resident Memory

已经被映射到虚拟内存中的物理内存。存在一些“非代码执行开销”，如系统和应用二进制加载的内存。

Resident Memory = Dirty Memory + Clean Memory that loaded in pysical memory。

这里存在两种Resident Memory，系统的（dyld_shared_cache，即动态库共享缓存）和我们APP的，下面的代码得到的是我们APP的。

获取App消耗的Resident Memory：

#import <mach/mach.h>
- (int64_t)memoryResidentSize {
    struct task_basic_info info;
    mach_msg_type_number_t size = sizeof(task_basic_info_data_t) / sizeof(natural_t);
    kern_return_t ret = task_info(mach_task_self(), TASK_BASIC_INFO, (task_info_t)&info, &size);
    if (ret != KERN_SUCCESS) {
        return 0;
    }
    return info.resident_size;
}

注意： Resident Memory包含Memory Footprint。

Memory Footprint

App消耗的实际物理内存，苹果推荐用 footprint 命令来查看一个应用进程的内存占用。

我们会发现这个跟我们在 Instruments 里面看到的内存大小不一样，有时候甚至差别很大。其实Footprint主要就是Dirty部分，也就是我们可以控制优化的部分。Xcode Navigator里记录的大致也差不多是这个值。

获取App的Footprint：

#import <mach/mach.h>
- (int64_t)memoryPhysFootprint {
    task_vm_info_data_t vmInfo;
    mach_msg_type_number_t count = TASK_VM_INFO_COUNT;
    kern_return_t ret = task_info(mach_task_self(), TASK_VM_INFO, (task_info_t)&vmInfo, &count);
    if (ret != KERN_SUCCESS) {
        return 0;
    }
    return vmInfo.phys_footprint;
}

XNU中Jetsam判断内存过大，使用的也是phys_footprint，而非resident size。

内存测量

代码

- (void)viewDidLoad {
    [self logMemorySize];
    void *memBlock = malloc(10 * 1024 * 1024);
    [self logMemorySize];
    memset(memBlock, 0, 10 * 1024 * 1024);
    [self logMemorySize];
}

初始值

申请虚拟内存后

映射物理内存后

Instruments查看

运行Allocations模块，添加VM Tracker。下图是映射物理内存之后：

其中系统的Resident主要就是dyld_shared_cache（动态库共享缓存），所有APP的虚拟内存对动态库的物理内存映射都是映射到这块的，我们运行不同的app查看dyld_shared_cache的地址都是一样的：

总结：
All Resident = 系统Resident + APP Resident
APP Resident = Memory Footprint + Clean Memory that loaded in pysical memory(_TEXT + _OBJC_RO + Other)

内存不够怎么办

进程A和B都拥有1到4的虚拟内存。系统通过虚拟内存到物理内存的映射，让A和B都可以使用到物理内存。上图中物理内存是充足的，但是如果A占用了大部分内存，B想要使用物理内存的时候物理内存却不够该怎么办呢？

OSX

在OSX上系统会将不活跃的内存块写入硬盘，一般称之为Swapped out。

由于虚拟内存的空间远远大于物理内存，在任意一个时间点，虚拟内存中的一个页并不一定总是在物理内存中，而是可能被暂时存到了磁盘上，这样物理内存便可以暂时释放这部分空间，供优先级更高的任务使用，因此磁盘可以作为 backing store 以扩展物理内存（MacOS 中有，iOS 没有）。

iOS

由于闪存容量和读写寿命的限制，iOS 上没有Disk swap机制，取而代之使用 Compressed memory。等压缩后内存也不够用后，iOS上则会通知App，让App清理内存，也就是我们熟知的Memory Warning。

苹果最初只是公开了从 OS X Mavericks 开始使用 Compressed memory 技术，但 iOS 系统也从 iOS 7 开始悄悄地使用。该技术在内存紧张时能够将最近使用过的内存占用压缩至原有大小的一半以下，并且能够在需要时解压复用。它在节省内存的同时提高了系统的响应速度，其特点可以归结为：

• Shrinks memory usage 减少了不活跃内存占用
• Improves power efficiency 改善电源效率，通过压缩减少磁盘IO带来的损耗
• Minimizes CPU usage 压缩/解压十分迅速，能够尽可能减少 CPU 的时间开销
• Is multicore aware 支持多核操作
• 举例：当我们使用 NSDictionary 去缓存数据的时候，假设现在已经使用了 3 页内存，当不访问的时候可能会被压缩为 1 页，再次使用到时候又会解压成 3 页。

Swap In/Out & Page In/Out

• 磁盘内部有一个区域叫做交换空间(Swap Space)，MMU(内存管理单元) 会将暂时不用的内存块内容写在交互空间上(硬盘)，这就是Swap Out；当需要时候再从Swap Space中读取到内存中，这就是Swap In；Swap in和swap out的操作都是比较耗时的, 频繁的Swap in和Swap out操作非常影响系统性能；

• Page In/Out和 Swap In/Out 概念类似，只不过Page In/Out是将某些页的数据写到内存/从内存写回磁盘交互区；而Swap In/Out是将整个地址空间的数据写到内存/从内存写回磁盘交互区；本质都是交互机制。

• macOS支持这类交换机制，但是iOS不支持；主要有两方面考虑吧：

  • 移动设备的闪存读写次数有限，频繁写会降低寿命；
  • 相比PC机，移动设备闪存空间有限(15年6s最小存储空间16GB、最大128GB；19年XS Max最小64GB，最大521GB)

内存分页

系统会对虚拟内存和物理内存进行分页，虚拟内存到物理内存的映射都是以页为最小粒度的。

也就是说内存管理、映射中的基本单位是页，一页的大小是 4kb（早期设备）或者 16kb（A7 芯片及以后）。

分页解决了什么问题

• 解决空间浪费碎片化问题：由于将虚拟内存空间和物理内存空间按照某种规定的大小进行分配，这里我们称之为页（Page），然后按照页进行内存分配，也就克服了外部碎片的问题。
• 解决程序大小受限问题：将当前需要的页面放在内存里，其他暂时不用的页面放在磁盘上，这样一个程序同时占用内存和磁盘，其增长空间就大大增加了。

内存分页的状态

系统将内存页分为三个状态：

• 活跃的内存页（active page）：内存页已经被映射到物理内存中，而且近期被访问过，处于活跃状态。
• 非活跃的内存页（inactive page）：内存页已经被映射到物理内存中，但是近期没有被访问过。
• 可用的内存页（free page）：没有关联到虚拟内存页的物理内存页集合。

当可用的内存页降低到一定的阀值时，系统就会采取低内存应对措施，在OSX中，系统会将非活跃内存页交换到硬盘上，而在iOS中，则会触发Memory Warning，如果你的App没有处理低内存警告并且还在后台占用太多内存，则有可能被杀掉。

VM Region/VM Object

一个 VM Region 是指一段连续的内存页（在虚拟地址空间里），这些页拥有相同的属性（如读写权限、是否是 wired，也就是是否能被 page out）。

每个 VM Region 对应一个数据结构，名为 VM Object。Object 会记录这个 Region 内存的属性:

• Resident pages - 已经被映射到物理内存的虚拟内存页列表
• Size - 所有内存页所占区域的大小
• Pager - 用来处理内存页在硬盘和物理内存中交换问题
• Attributes - 这块内存区域的属性，比如读写的权限控制
• Shadow - 用作（copy-on-write）写时拷贝的优化
• Copy - 用作（copy-on-write）写时拷贝的优化

查看VM Region

编写代码

创建工程运行以下代码，main图片分辨率为750 × 1624，Labrador图片分辨率600 × 704

#import "CustomObject.h"
@implementation CustomObject{
    long a[200];
}
@end

- (void)viewDidLoad {
    [super viewDidLoad];
    // Do any additional setup after loading the view.
    self.myObjsArr = [NSMutableArray array];
    for (int i=0; i<10000; i++) {
        CustomObject *obj = [CustomObject new];
        [self.myObjsArr addObject:obj];
    }
    UIImageView *showImageView = [[UIImageView alloc] initWithFrame:self.view.bounds];
    [showImageView setImage:[UIImage imageNamed:@"main"]];
    [self.view addSubview:showImageView];
    UIImageView *showImageView2 = [[UIImageView alloc] initWithFrame:CGRectMake(100, 100, 325, 412)];
    [showImageView2 setImage:[UIImage imageNamed:@"Labrador.JPG"]];
    [self.view addSubview:showImageView2];
}

查看内存地址

运行Instruments，选择Allocation模版，右上角选择添加VM Track：

Instruments启动app，Allocation里查看到我们创建的CustomObject和Image IO的内存，点击右箭头能看到对应的内存地址：

查看VM Region

我们切换到最底下的VM Track，将模式调整为Regions Map，就能看到VM Region的一个列表了，其中每一行代表一个VM Region，我们能看到每一个VM Region的大小都是不一样的。

我们能看到每张图片解码缓存Image IO占用一个Region，而我们的CustomObject都在一个MALLOC_SMALL类型的Region里。

VM Region类型

我们能看到VM Region有很多不同的类型，这里我们举几个例子：

• Image IO：图片解码缓存
• mapped file：即映射到磁盘的一个文件
• __TEXT：r-x，多数为二进制
• __DATA：rw-，为可读写数据
• MALLOC_(SIZE)：顾名思义是 malloc 申请的内存，根据对象的大小分不同类型（MALLOC_LARGE、MALLOC_SMALL、MALLOC_TINY）

VM Region Size

我们在VM Track中可以看到，一个VM Region有4种size。

• Dirty Size：指的是不能被系统回收的内存占用，
  
  • 所有堆上的对象
  • 图片解码缓冲数据(Decoded image buffers)
  • Frameworks 中的 __DATA 和 __DATA_DIRTY部分
• Swapped Size：在OSX上表示交换到硬盘上的大小，在iOS上指的是 Compressed memory size且其值表示压缩后的占用大小
• Resident Size：指的是实际使用物理内存的大小（映射到虚拟内存中的物理内存）
• Virtual Size：就是虚拟内存大小，将一个VM Region的结束地址减去起始地址就是这个值

所以一般来说app运行过程中在堆上动态分配的内存页都是Dirty的，加载动态库或者文件内存映射产生的内存页则是非Dirty的。综上，我们可以总结出:

Virtual Size >= Resident Size + Swapped Size >= Dirty Size + Swapped Size，

活跃状态：

非活跃状态：

malloc 和 calloc

我们除了使用NSObject的alloc分配内存外，还可以使用c的函数malloc进行内存分配。malloc的内存分配当然也是先分配虚拟内存，然后使用的时候再映射到物理内存，不过malloc有一个缺陷，必须配合memset将内存区中所有的值设置为0。这样就导致了一个问题，malloc出一块内存区域时，系统并没有分配物理内存。然而，调用memset后，系统将会把malloc出的所有虚拟内存关联到物理内存上，因为你访问了所有内存区域。

• 分配虚拟内存

  我们通过代码来验证一下，在main方法中，创建一个1024*1024的内存块，也就是1M：

  void *memBlock = malloc(1024 * 1024);

  

  我们发现MALLOC_LARGE中有一块虚拟内存大小为1M的VM Region。因为我们没有使用这块内存，所以其他Size都是0。

• 虚拟内存映射到物理内存

  现在我们加上memset再观察：

  void *memBlock = malloc(1024 * 1024);
  memset(memBlock, 0, 1024 * 1024);

  

  现在Resident Size，Dirty Size也是1M了，说明这块内存已经被映射到物理内存中去了。为了解决这个问题，苹果官方推荐使用calloc代替malloc，calloc返回的内存区域会自动清零，而且只有使用时才会关联到物理内存并清零。

malloc_zone_t 和 NSZone

相信大家对NSZone并不陌生，allocWithZone或者copyWithZone这2个方法大家应该也经常见到。那么Zone究竟是什么呢？Zone可以被理解为一组内存块，在某个Zone里分配的内存块，会随着这个Zone的销毁而销毁，所以Zone可以加速大量小内存块的集体销毁。不过NSZone实际上已经被苹果抛弃。你可以创建自己的NSZone，然后使用allocWithZone将你的OC对象在这个NSZone上分配，但是你的对象还是会被分配在默认的NSZone里。我们可以用heap工具查看进程的Zone分布情况。首先使用下面的代码让CustomObject使用新的NSZone。

void allocCustomObjectsWithCustomNSZone() {
    static NSMutableSet *objs = nil;
    if (objs == nil) { objs = [NSMutableSet new]; }
    NSZone *customZone = NSCreateZone(1024, 1024, YES);
    NSSetZoneName(customZone, @"Custom Object Zone");
    for (int i = 0; i < 1000; ++i) {
        CustomObject *obj = [CustomObject allocWithZone:customZone];
        [objs addObject:obj];
    }
}

代码创建了1000个CustomObject对象，并且尝试使用新建的Zone。我们用heap工具看看结果。首先使用Activity Monitor找到进程的PID，在命令行中执行

heap PID

执行的结果大致如下:

......
Process 25073: 3 zones
Zone DefaultMallocZone_0x1004c9000: Overall size: 196992KB; 13993 nodes malloced for 160779KB (81% of capacity); largest unused: [0x102800000-171072KB]
Zone Custom Object Zone_0x1004fe000: Overall size: 1024KB; 1 nodes malloced for 1KB (0% of capacity); largest unused: [0x102200000-1024KB]
Zone GFXMallocZone_0x1004d8000: Overall size: 0KB
All zones: 13994 nodes malloced - 160779KB
Zone DefaultMallocZone_0x1004c9000: 13993 nodes - Sizes: 160KB[1000] 64.5KB[1] 16.5KB[1] 13.5KB[1] 4.5KB[3] 2KB[3] 1.5KB[12] 1KB[1] 704[1] 576[13] 528[4] 512[2] 480[1] 464[1] 448[2] 432[1] 400[1] 384[2] 368[1] 352[1] 336[2] 320[1] 272[8] 256[1] 240[4] 208[10] 192[5] 176[3] 160[5] 144[28] 128[48] 112[43] 96[83] 80[519] 64[3044] 48[5415] 32[3640] 16[82] 
Zone Custom Object Zone_0x1004fe000: 1 nodes - Sizes: 32[1] 
Zone GFXMallocZone_0x1004d8000: 0 nodes
All zones: 13994 nodes malloced - Sizes: 160KB[1000] 64.5KB[1] 16.5KB[1] 13.5KB[1] 4.5KB[3] 2KB[3] 1.5KB[12] 1KB[1] 704[1] 576[13] 528[4] 512[2] 480[1] 464[1] 448[2] 432[1] 400[1] 384[2] 368[1] 352[1] 336[2] 320[1] 272[8] 256[1] 240[4] 208[10] 192[5] 176[3] 160[5] 144[28] 128[48] 112[43] 96[83] 80[519] 64[3044] 48[5415] 32[3641] 16[82] 
Found 523 ObjC classes
Found 56 CFTypes
-----------------------------------------------------------------------
Zone DefaultMallocZone_0x1004c9000: 13993 nodes (164637440 bytes) 
    COUNT     BYTES       AVG   CLASS_NAME                                       TYPE    BINARY
    =====     =====       ===   ==========                                       ====    ======
    12771    779136      61.0   non-object                                                                 
     1000 163840000  163840.0   CustomObject                                     ObjC    VMResearch        
       49      2864      58.4   CFString                                         ObjC    CoreFoundation    
       21      1344      64.0   pthread_mutex_t                                  C       libpthread.dylib  
       20      1280      64.0   CFDictionary                                     ObjC    CoreFoundation    
       18      2368     131.6   CFDictionary (Value Storage)                     C       CoreFoundation    
       16      2304     144.0   CFDictionary (Key Storage)                       C       CoreFoundation    
        8       512      64.0   CFBasicHash                                      CFType  CoreFoundation    
        7       560      80.0   CFArray                                          ObjC    CoreFoundation    
        6       768     128.0   CFPrefsPlistSource                               ObjC    CoreFoundation    
        6       480      80.0   OS_os_log                                        ObjC    libsystem_trace.dylib
        5       160      32.0   NSMergePolicy                                    ObjC    CoreData          
        4       384      96.0   NSLock                                           ObjC    Foundation        
......
-----------------------------------------------------------------------
Zone Custom Object Zone_0x1004fe000: 1 nodes (32 bytes) 
    COUNT     BYTES       AVG   CLASS_NAME                                       TYPE    BINARY
    =====     =====       ===   ==========                                       ====    ======
        1        32      32.0   non-object                                                                 
-----------------------------------------------------------------------
Zone GFXMallocZone_0x1004d8000: 0 nodes (0 bytes) 

一共有3个zone，Zone Custom Object Zone_0x1004fe000: 1 nodes (32 bytes)就是我们创建的NSZone，不过它里面只有一个节点，共32bytes，如果你不设置Zone的name，它会是0bytes。所以我们可以推导出这32bytes是用来存储Zone本身的信息的。我们创建的1000个CustomObject其实在Zone DefaultMallocZone_0x1004c9000里，也就是系统默认创建的NSZone。如果你真的想用Zone内存机制，可以使用malloc_zone_t。通过下面的代码可以在自定义的zone上malloc内存块。

void allocCustomObjectsWithCustomMallocZone() {
    malloc_zone_t *customZone = malloc_create_zone(1024, 0);
    malloc_set_zone_name(customZone, "custom malloc zone");
    for (int i = 0; i < 1000; ++i) {
        malloc_zone_malloc(customZone, 300 * 4096);
    }
}

再次使用heap工具查看。我只截取了custom malloc zone的内容。有1001个node，也就是1000个malloc_zone_malloc出来的内存块加上zone本身的信息所占的内存块。

-----------------------------------------------------------------------
Zone custom malloc zone_0x1004fe000: 1001 nodes (1228800032 bytes) 
    COUNT     BYTES       AVG   CLASS_NAME                                       TYPE    BINARY
    =====     =====       ===   ==========                                       ====    ======
     1001 1228800032 1227572.4   non-object  

我们可以使用malloc_destroy_zone(customZone)一次性释放上面分配的所有内存。

参考

iOS底层系统：虚拟内存
探索iOS内存分配
浅谈进程地址空间与虚拟存储空间
[ WWDC2018 ] - 深入解析iOS内存 iOS Memory Deep Dive
关于iOS内存的深入排查和优化