声明：尊重原创，原文地址：带你打造一套 APM 监控系统。本文为根据原创文章整理所得，感谢浏览。

三、 CPU 使用率监控

1. CPU 架构

CPU（Central Processing Unit）中央处理器，市场上主流的架构有 ARM（arm64）、Intel（x86）、AMD 等。其中 Intel 使用 CISC（Complex Instruction Set Computer），ARM 使用 RISC（Reduced Instruction Set Computer）。区别在于不同的 CPU 设计理念和方法。

早期 CPU 全部是 CISC 架构，设计目的是用最少的机器语言指令来完成所需的计算任务。比如对于乘法运算，在 CISC 架构的 CPU 上。一条指令 MUL ADDRA, ADDRB 就可以将内存 ADDRA 和内存 ADDRB 中的数香乘，并将结果存储在 ADDRA 中。做的事情就是：将 ADDRA、ADDRB 中的数据读入到寄存器，相乘的结果写入到内存的操作依赖于 CPU 设计，所以 CISC 架构会增加 CPU 的复杂性和对 CPU 工艺的要求。

RISC 架构要求软件来指定各个操作步骤。比如上面的乘法，指令实现为 MOVE A, ADDRA; MOVE B, ADDRB; MUL A, B; STR ADDRA, A;。这种架构可以降低 CPU 的复杂性以及允许在同样的工艺水平下生产出功能更加强大的 CPU，但是对于编译器的设计要求更高。

目前市场是大部分的 iPhone 都是基于 arm64 架构的。且 arm 架构能耗低。

2. 获取线程信息

讲完了区别来讲下如何做 CPU 使用率的监控：

• 开启定时器，按照设定的周期不断执行下面的逻辑
• 获取当前任务 task。从当前 task 中获取所有的线程信息（线程个数、线程数组）
• 遍历所有的线程信息，判断是否有线程的 CPU 使用率超过设置的阈值
• 假如有线程使用率超过阈值，则 dump 堆栈
• 组装数据，上报数据

线程信息结构体

struct thread_basic_info {time_value_t    user_time;      /* user run time（用户运行时长） */time_value_t    system_time;    /* system run time（系统运行时长） */ integer_t       cpu_usage;      /* scaled cpu usage percentage（CPU使用率，上限1000） */policy_t        policy;         /* scheduling policy in effect（有效调度策略） */integer_t       run_state;      /* run state (运行状态，见下) */integer_t       flags;          /* various flags (各种各样的标记) */integer_t       suspend_count;  /* suspend count for thread（线程挂起次数） */integer_t       sleep_time;     /* number of seconds that thread*  has been sleeping（休眠时间） */
};

代码在讲堆栈还原的时候讲过，忘记的看一下上面的分析：

thread_act_array_t threads;
mach_msg_type_number_t threadCount = 0;
const task_t thisTask = mach_task_self();
kern_return_t kr = task_threads(thisTask, &threads, &threadCount);
if (kr != KERN_SUCCESS) {return ;
}
for (int i = 0; i < threadCount; i++) {thread_info_data_t threadInfo;thread_basic_info_t threadBaseInfo;mach_msg_type_number_t threadInfoCount;kern_return_t kr = thread_info((thread_inspect_t)threads[i], THREAD_BASIC_INFO, (thread_info_t)threadInfo, &threadInfoCount);if (kr == KERN_SUCCESS) {threadBaseInfo = (thread_basic_info_t)threadInfo;// todo：条件判断，看不明白if (!(threadBaseInfo->flags & TH_FLAGS_IDLE)) {integer_t cpuUsage = threadBaseInfo->cpu_usage / 10;if (cpuUsage > CPUMONITORRATE) {NSMutableDictionary *CPUMetaDictionary = [NSMutableDictionary dictionary];NSData *CPUPayloadData = [NSData data];NSString *backtraceOfAllThread = [BacktraceLogger backtraceOfAllThread];// 1. 组装卡顿的 Meta 信息CPUMetaDictionary[@"MONITOR_TYPE"] = CMMonitorCPUType;// 2. 组装卡顿的 Payload 信息（一个JSON对象，对象的 Key 为约定好的 STACK_TRACE， value 为 base64 后的堆栈信息）NSData *CPUData = [SAFE_STRING(backtraceOfAllThread) dataUsingEncoding:NSUTF8StringEncoding];NSString *CPUDataBase64String = [CPUData base64EncodedStringWithOptions:0];NSDictionary *CPUPayloadDictionary = @{@"STACK_TRACE": SAFE_STRING(CPUDataBase64String)};NSError *error;// NSJSONWritingOptions 参数一定要传0，因为服务端需要根据 \n 处理逻辑，传递 0 则生成的 json 串不带 \nNSData *parsedData = [NSJSONSerialization dataWithJSONObject:CPUPayloadDictionary options:0 error:&error];if (error) {CMMLog(@"%@", error);return;}CPUPayloadData = [parsedData copy];// 3. 数据上报会在 [打造功能强大、灵活可配置的数据上报组件](https://github.com/FantasticLBP/knowledge-kit/blob/master/Chapter1%20-%20iOS/1.80.md) 讲[[PrismClient sharedInstance] sendWithType:CMMonitorCPUType meta:CPUMetaDictionary payload:CPUPayloadData]; }}}
}

四、 OOM 问题

1. 基础知识准备

硬盘：也叫做磁盘，用于存储数据。你存储的歌曲、图片、视频都是在硬盘里。

内存：由于硬盘读取速度较慢，如果 CPU 运行程序期间，所有的数据都直接从硬盘中读取，则非常影响效率。所以 CPU 会将程序运行所需要的数据从硬盘中读取到内存中。然后 CPU 与内存中的数据进行计算、交换。内存是易失性存储器（断电后，数据消失）。内存条区是计算机内部（在主板上）的一些存储器，用来保存 CPU 运算的中间数据和结果。内存是程序与 CPU 之间的桥梁。从硬盘读取出数据或者运行程序提供给 CPU。

虚拟内存 是计算机系统内存管理的一种技术。它使得程序认为它拥有连续的可用内存，而实际上，它通常被分割成多个物理内存碎片，可能部分暂时存储在外部磁盘（硬盘）存储器上（当需要使用时则用硬盘中数据交换到内存中）。Windows 系统中称为 “虚拟内存”，Linux/Unix 系统中称为 ”交换空间“。

iOS 不支持交换空间？不只是 iOS 不支持交换空间，大多数手机系统都不支持。因为移动设备的大量存储器是闪存，它的读写速度远远小电脑所使用的硬盘，也就是说手机即使使用了交换空间技术，也因为闪存慢的问题，不能提升性能，所以索性就没有交换空间技术。

2. iOS 内存知识

内存（RAM）与 CPU 一样都是系统中最稀少的资源，也很容易发生竞争，应用内存与性能直接相关。iOS 没有交换空间作为备选资源，所以内存资源尤为重要。

什么是 OOM？是 out-of-memory 的缩写，字面意思是超过了内存限制。分为 FOOM（foreground OOM）和 BOOM（background OOM）。它是由 iOS 的 Jetsam 机制造成的一种非主流 Crash，它不能通过 Signal 这种监控方案所捕获。

什么是 Jetsam 机制？Jetsam 机制可以理解为系统为了控制内存资源过度使用而采用的一种管理机制。Jetsam 机制是运行在一个独立的进程中，每个进程都有一个内存阈值，一旦超过这个内存阈值，Jetsam 会立即杀掉这个进程。

为什么设计 Jetsam 机制？因为设备的内存是有限的，所以内存资源非常重要。系统进程以及其他使用的 App 都会抢占这个资源。由于 iOS 不支持交换空间，一旦触发低内存事件，Jetsam 就会尽可能多的释放 App 所在内存，这样 iOS 系统上出现内存不足时，App 就会被系统杀掉，变现为 crash。

2种情况触发 OOM：系统由于整体内存使用过高，会基于优先级策略杀死优先级较低的 App；当前 App 达到了 “highg water mark” ，系统也会强杀当前 App（超过系统对当前单个 App 的内存限制值）。

读了源码（xnu/bsd/kern/kern_memorystatus.c）会发现内存被杀也有2种机制，如下

highwater 处理 -> 我们的 App 占用内存不能超过单个限制：

1. 从优先级列表里循环寻找线程
2. 判断是否满足 p_memstat_memlimit 的限制条件
3. DiagonoseActive、FREEZE 过滤
4. 杀进程，成功则 exit，否则循环

memorystatus_act_aggressive 处理 -> 内存占用高，按照优先级杀死：

1. 根据 policy 家在 jld_bucket_count，用来判断是否被杀
2. 从 JETSAM_PRIORITY_ELEVATED_INACTIVE 开始杀
3. Old_bucket_count 和 memorystatus_jld_eval_period_msecs 判断是否开杀
4. 根据优先级从低到高开始杀，直到 memorystatus_avail_pages_below_pressure

内存过大的几种情况

• App 内存消耗较低，同时其他 App 内存管理也很棒，那么即使切换到其他 App，我们自己的 App 依旧是“活着”的，保留了用户状态。体验好
• App 内存消耗较低，但其他 App 内存消耗太大（可能是内存管理糟糕，也可能是本身就耗费资源，比如游戏），那么除了在前台的线程，其他 App 都会被系统杀死，回收内存资源，用来给活跃的进程提供内存。
• App 内存消耗较大，切换到其他 App 后，即使其他 App 向系统申请的内存不大，系统也会因为内存资源紧张，优先把内存消耗大的 App 杀死。表现为用户将 App 退出到后台，过会儿再次打开会发现 App 重新加载启动。
• App 内存消耗非常大，在前台运行时就被系统杀死，造成闪退。

App 内存不足时，系统会按照一定策略来腾出更多的空间供使用。比较常见的做法是将一部分优先级低的数据挪到磁盘上，该操作为称为 page out。之后再次访问这块数据的时候，系统会负责将它重新搬回到内存中，该操作被称为 page in。

Memory page** 是内存管理中的最小单位，是系统分配的，可能一个 page 持有多个对象，也可能一个大的对象跨越多个 page。通常它是 16KB 大小，且有3种类型的 page。

• Clean Memory
  Clean memory 包括3类：可以 page out 的内存、内存映射文件、App 使用到的 framework（每个 framework 都有 _DATA_CONST 段，通常都是 clean 状态，但使用 runtime swizling，那么变为 dirty）。

  一开始分配的 page 都是干净的（堆里面的对象分配除外），我们 App 数据写入时候变为 dirty。从硬盘读进内存的文件，也是只读的、clean page。

• Dirty Memory

  Dirty memory 包括4类：被 App 写入过数据的内存、所有堆区分配的对象、图像解码缓冲区、framework（framework 都有 _DATA 段和 _DATA_DIRTY 段，它们的内存都是 dirty）。

  在使用 framework 的过程中会产生 Dirty memory，使用单例或者全局初始化方法有助于帮助减少 Dirty memory（因为单例一旦创建就不销毁，一直在内存中，系统不认为是 Dirty memory）。

• Compressed Memory

  由于闪存容量和读写限制，iOS 没有交换空间机制，而是在 iOS7 引入了 memory compressor。它是在内存紧张时候能够将最近一段时间未使用过的内存对象，内存压缩器会把对象压缩，释放出更多的 page。在需要时内存压缩器对其解压复用。在节省内存的同时提高了响应速度。

  比如 App 使用某 Framework，内部有个 NSDictionary 属性存储数据，使用了 3 pages 内存，在近期未被访问的时候 memory compressor 将其压缩为 1 page，再次使用的时候还原为 3 pages。

App 运行内存 = pageNumbers * pageSize。因为 Compressed Memory 属于 Dirty memory。所以 Memory footprint = dirtySize + CompressedSize

设备不同，内存占用上限不同，App 上限较高，extension 上限较低，超过上限 crash 到 EXC_RESOURCE_EXCEPTION。

接下来谈一下如何获取内存上限，以及如何监控 App 因为占用内存过大而被强杀。

3. 获取内存信息

3.1 通过 JetsamEvent 日志计算内存限制值

当 App 被 Jetsam 机制杀死时，手机会生成系统日志。查看路径：Settings-Privacy-Analytics & Improvements- Analytics Data（设置-隐私- 分析与改进-分析数据），可以看到 JetsamEvent-2020-03-14-161828.ips 形式的日志，以 JetsamEvent 开头。这些 JetsamEvent 日志都是 iOS 系统内核强杀掉那些优先级不高（idle、frontmost、suspended）且占用内存超过系统内存限制的 App 留下的。

日志包含了 App 的内存信息。可以查看到 日志最顶部有 pageSize 字段，查找到 per-process-limit，该节点所在结构里的 rpages ，将 rpages * pageSize 即可得到 OOM 的阈值。

日志中 largestProcess 字段代表 App 名称；reason 字段代表内存原因；states 字段代表奔溃时 App 的状态（ idle、suspended、frontmost…）。

为了测试数据的准确性，我将测试2台设备（iPhone 6s plus/13.3.1，iPhone 11 Pro/13.3.1）的所有 App 彻底退出，只跑了一个为了测试内存临界值的 Demo App。 循环申请内存，ViewController 代码如下

- (void)viewDidLoad {[super viewDidLoad];NSMutableArray *array = [NSMutableArray array];for (NSInteger index = 0; index < 10000000; index++) {UIImageView *imageView = [[UIImageView alloc] initWithFrame:CGRectMake(0, 0, 100, 100)];UIImage *image = [UIImage imageNamed:@"AppIcon"];imageView.image = image;[array addObject:imageView];}
}

iPhone 6s plus/13.3.1 数据如下：

{"bug_type":"298","timestamp":"2020-03-19 17:23:45.94 +0800","os_version":"iPhone OS 13.3.1 (17D50)","incident_id":"DA8AF66D-24E8-458C-8734-981866942168"}
{"crashReporterKey" : "fc9b659ce486df1ed1b8062d5c7c977a7eb8c851","kernel" : "Darwin Kernel Version 19.3.0: Thu Jan  9 21:10:44 PST 2020; root:xnu-6153.82.3~1\/RELEASE_ARM64_S8000","product" : "iPhone8,2","incident" : "DA8AF66D-24E8-458C-8734-981866942168","date" : "2020-03-19 17:23:45.93 +0800","build" : "iPhone OS 13.3.1 (17D50)","timeDelta" : 332,"memoryStatus" : {"compressorSize" : 48499,"compressions" : 7458651,"decompressions" : 5190200,"zoneMapCap" : 744407040,"largestZone" : "APFS_4K_OBJS","largestZoneSize" : 41402368,"pageSize" : 16384,"uncompressed" : 104065,"zoneMapSize" : 141606912,"memoryPages" : {"active" : 26214,"throttled" : 0,"fileBacked" : 14903,"wired" : 20019,"anonymous" : 37140,"purgeable" : 142,"inactive" : 23669,"free" : 2967,"speculative" : 2160}
},"largestProcess" : "Test","genCounter" : 0,"processes" : [{"uuid" : "39c5738b-b321-3865-a731-68064c4f7a6f","states" : ["daemon","idle"],"lifetimeMax" : 188,"age" : 948223699030,"purgeable" : 0,"fds" : 25,"coalition" : 422,"rpages" : 177,"pid" : 282,"idleDelta" : 824711280,"name" : "com.apple.Safari.SafeBrowsing.Se","cpuTime" : 10.275422000000001},// ...{"uuid" : "83dbf121-7c0c-3ab5-9b66-77ee926e1561","states" : ["frontmost"],"killDelta" : 2592,"genCount" : 0,"age" : 1531004794,"purgeable" : 0,"fds" : 50,"coalition" : 1047,"rpages" : 92806,"reason" : "per-process-limit","pid" : 2384,"cpuTime" : 59.464373999999999,"name" : "Test","lifetimeMax" : 92806},// ...]
}

iPhone 6s plus/13.3.1 手机 OOM 临界值为：(16384*92806)/(1024*1024)=1450.09375M

iPhone 11 Pro/13.3.1 数据如下：

{"bug_type":"298","timestamp":"2020-03-19 17:30:28.39 +0800","os_version":"iPhone OS 13.3.1 (17D50)","incident_id":"7F111601-BC7A-4BD7-A468-CE3370053057"}
{"crashReporterKey" : "bc2445adc164c399b330f812a48248e029e26276","kernel" : "Darwin Kernel Version 19.3.0: Thu Jan  9 21:11:10 PST 2020; root:xnu-6153.82.3~1\/RELEASE_ARM64_T8030","product" : "iPhone12,3","incident" : "7F111601-BC7A-4BD7-A468-CE3370053057","date" : "2020-03-19 17:30:28.39 +0800","build" : "iPhone OS 13.3.1 (17D50)","timeDelta" : 189,"memoryStatus" : {"compressorSize" : 66443,"compressions" : 25498129,"decompressions" : 15532621,"zoneMapCap" : 1395015680,"largestZone" : "APFS_4K_OBJS","largestZoneSize" : 41222144,"pageSize" : 16384,"uncompressed" : 127027,"zoneMapSize" : 169639936,"memoryPages" : {"active" : 58652,"throttled" : 0,"fileBacked" : 20291,"wired" : 45838,"anonymous" : 96445,"purgeable" : 4,"inactive" : 54368,"free" : 5461,"speculative" : 3716}
},"largestProcess" : "杭城小刘","genCounter" : 0,"processes" : [{"uuid" : "2dd5eb1e-fd31-36c2-99d9-bcbff44efbb7","states" : ["daemon","idle"],"lifetimeMax" : 171,"age" : 5151034269954,"purgeable" : 0,"fds" : 50,"coalition" : 66,"rpages" : 164,"pid" : 11276,"idleDelta" : 3801132318,"name" : "wcd","cpuTime" : 3.430787},// ...{"uuid" : "63158edc-915f-3a2b-975c-0e0ac4ed44c0","states" : ["frontmost"],"killDelta" : 4345,"genCount" : 0,"age" : 654480778,"purgeable" : 0,"fds" : 50,"coalition" : 1718,"rpages" : 134278,"reason" : "per-process-limit","pid" : 14206,"cpuTime" : 23.955463999999999,"name" : "杭城小刘","lifetimeMax" : 134278},// ...]
}

iPhone 11 Pro/13.3.1 手机 OOM 临界值为：(16384*134278)/(1024*1024)=2098.09375M

iOS 系统如何发现 Jetsam ？

MacOS/iOS 是一个 BSD 衍生而来的系统，其内核是 Mach，但是对于上层暴露的接口一般是基于 BSD 层对 Mach 的包装后的。Mach 是一个微内核的架构，真正的虚拟内存管理也是在其中进行的，BSD 对内存管理提供了上层接口。Jetsam 事件也是由 BSD 产生的。bsd_init 函数是入口，其中基本都是在初始化各个子系统，比如虚拟内存管理等。

// 1. Initialize the kernel memory allocator, 初始化 BSD 内存 Zone，这个 Zone 是基于 Mach 内核的zone 构建
kmeminit();// 2. Initialise background freezing, iOS 上独有的特性，内存和进程的休眠的常驻监控线程
#if CONFIG_FREEZE
#ifndef CONFIG_MEMORYSTATUS#error "CONFIG_FREEZE defined without matching CONFIG_MEMORYSTATUS"
#endif/* Initialise background freezing */bsd_init_kprintf("calling memorystatus_freeze_init\n");memorystatus_freeze_init();
#endif>// 3. iOS 独有，JetSAM（即低内存事件的常驻监控线程）
#if CONFIG_MEMORYSTATUS/* Initialize kernel memory status notifications */bsd_init_kprintf("calling memorystatus_init\n");memorystatus_init();
#endif /* CONFIG_MEMORYSTATUS */

主要作用就是开启了2个优先级最高的线程，来监控整个系统的内存情况。

CONFIG_FREEZE 开启时，内核对进程进行冷冻而不是杀死。冷冻功能是由内核中启动一个 memorystatus_freeze_thread 进行，这个进程在收到信号后调用 memorystatus_freeze_top_process 进行冷冻。

iOS 系统会开启优先级最高的线程 vm_pressure_monitor 来监控系统的内存压力情况，并通过一个堆栈来维护所有 App 进程。iOS 系统还会维护一个内存快照表，用于保存每个进程内存页的消耗情况。有关 Jetsam 也就是 memorystatus 相关的逻辑，可以在 XNU 项目中的 kern_memorystatus.h 和 **kern_memorystatus.c **源码中查看。

iOS 系统因内存占用过高会强杀 App 前，至少有 6秒钟可以用来做优先级判断，JetsamEvent 日志也是在这6秒内生成的。

上文提到了 iOS 系统没有交换空间，于是引入了 MemoryStatus 机制（也称为 Jetsam）。也就是说在 iOS 系统上释放尽可能多的内存供当前 App 使用。这个机制表现在优先级上，就是先强杀后台应用；如果内存还是不够多，就强杀掉当前应用。在 MacOS 中，MemoryStatus 只会强杀掉标记为空闲退出的进程。

MemoryStatus 机制会开启一个 memorystatus_jetsam_thread 的线程，它负责强杀 App 和记录日志，不会发送消息，所以内存压力检测线程无法获取到强杀 App 的消息。

当监控线程发现某 App 有内存压力时，就发出通知，此时有内存的 App 就去执行 didReceiveMemoryWarning 代理方法。在这个时机，我们还有机会做一些内存资源释放的逻辑，也许会避免 App 被系统杀死。

源码角度查看问题

iOS 系统内核有一个数组，专门维护线程的优先级。数组的每一项是一个包含进程链表的结构体。结构体如下：

#define MEMSTAT_BUCKET_COUNT (JETSAM_PRIORITY_MAX + 1)typedef struct memstat_bucket {TAILQ_HEAD(, proc) list;int count;
} memstat_bucket_t;memstat_bucket_t memstat_bucket[MEMSTAT_BUCKET_COUNT];

在 kern_memorystatus.h 中可以看到进行优先级信息：

#define JETSAM_PRIORITY_IDLE_HEAD                -2
/* The value -1 is an alias to JETSAM_PRIORITY_DEFAULT */
#define JETSAM_PRIORITY_IDLE                      0
#define JETSAM_PRIORITY_IDLE_DEFERRED		  1 /* Keeping this around till all xnu_quick_tests can be moved away from it.*/
#define JETSAM_PRIORITY_AGING_BAND1		  JETSAM_PRIORITY_IDLE_DEFERRED
#define JETSAM_PRIORITY_BACKGROUND_OPPORTUNISTIC  2
#define JETSAM_PRIORITY_AGING_BAND2		  JETSAM_PRIORITY_BACKGROUND_OPPORTUNISTIC
#define JETSAM_PRIORITY_BACKGROUND                3
#define JETSAM_PRIORITY_ELEVATED_INACTIVE	  JETSAM_PRIORITY_BACKGROUND
#define JETSAM_PRIORITY_MAIL                      4
#define JETSAM_PRIORITY_PHONE                     5
#define JETSAM_PRIORITY_UI_SUPPORT                8
#define JETSAM_PRIORITY_FOREGROUND_SUPPORT        9
#define JETSAM_PRIORITY_FOREGROUND               10
#define JETSAM_PRIORITY_AUDIO_AND_ACCESSORY      12
#define JETSAM_PRIORITY_CONDUCTOR                13
#define JETSAM_PRIORITY_HOME                     16
#define JETSAM_PRIORITY_EXECUTIVE                17
#define JETSAM_PRIORITY_IMPORTANT                18
#define JETSAM_PRIORITY_CRITICAL                 19#define JETSAM_PRIORITY_MAX                      21

可以明显的看到，后台 App 优先级 JETSAM_PRIORITY_BACKGROUND 为3，前台 App 优先级 JETSAM_PRIORITY_FOREGROUND 为10。

优先级规则是：内核线程优先级 > 操作系统优先级 > App 优先级。且前台 App 优先级高于后台运行的 App；当线程的优先级相同时， CPU 占用多的线程的优先级会被降低。

在 kern_memorystatus.c 中可以看到 OOM 可能的原因：

/* For logging clarity */
static const char *memorystatus_kill_cause_name[] = {""								,		/* kMemorystatusInvalid							*/"jettisoned"					,		/* kMemorystatusKilled							*/"highwater"						,		/* kMemorystatusKilledHiwat						*/"vnode-limit"					,		/* kMemorystatusKilledVnodes					*/"vm-pageshortage"				,		/* kMemorystatusKilledVMPageShortage			*/"proc-thrashing"				,		/* kMemorystatusKilledProcThrashing				*/"fc-thrashing"					,		/* kMemorystatusKilledFCThrashing				*/"per-process-limit"				,		/* kMemorystatusKilledPerProcessLimit			*/"disk-space-shortage"			,		/* kMemorystatusKilledDiskSpaceShortage			*/"idle-exit"						,		/* kMemorystatusKilledIdleExit					*/"zone-map-exhaustion"			,		/* kMemorystatusKilledZoneMapExhaustion			*/"vm-compressor-thrashing"		,		/* kMemorystatusKilledVMCompressorThrashing		*/"vm-compressor-space-shortage"	,		/* kMemorystatusKilledVMCompressorSpaceShortage	*/
};

查看 memorystatus_init 这个函数中初始化 Jetsam 线程的关键代码：

__private_extern__ void
memorystatus_init(void)
{// .../* Initialize the jetsam_threads state array */jetsam_threads = kalloc(sizeof(struct jetsam_thread_state) * max_jetsam_threads);/* Initialize all the jetsam threads */for (i = 0; i < max_jetsam_threads; i++) {result = kernel_thread_start_priority(memorystatus_thread, NULL, 95 /* MAXPRI_KERNEL */, &jetsam_threads[i].thread);if (result == KERN_SUCCESS) {jetsam_threads[i].inited = FALSE;jetsam_threads[i].index = i;thread_deallocate(jetsam_threads[i].thread);} else {panic("Could not create memorystatus_thread %d", i);}}
}

/**	High-level priority assignments*************************************************************************** 127		Reserved (real-time)*				A*				+*			(32 levels)*				+*				V* 96		Reserved (real-time)* 95		Kernel mode only*				A*				+*			(16 levels)*				+*				V* 80		Kernel mode only* 79		System high priority*				A*				+*			(16 levels)*				+*				V* 64		System high priority* 63		Elevated priorities*				A*				+*			(12 levels)*				+*				V* 52		Elevated priorities* 51		Elevated priorities (incl. BSD +nice)*				A*				+*			(20 levels)*				+*				V* 32		Elevated priorities (incl. BSD +nice)* 31		Default (default base for threads)* 30		Lowered priorities (incl. BSD -nice)*				A*				+*			(20 levels)*				+*				V* 11		Lowered priorities (incl. BSD -nice)* 10		Lowered priorities (aged pri's)*				A*				+*			(11 levels)*				+*				V* 0		Lowered priorities (aged pri's / idle)**************************************************************************/

可以看出：用户态的应用程序的线程不可能高于操作系统和内核。而且，用户态的应用程序间的线程优先级分配也有区别，比如处于前台的应用程序优先级高于处于后台的应用程序优先级。iOS 上应用程序优先级最高的是 SpringBoard；此外线程的优先级不是一成不变的。Mach 会根据线程的利用率和系统整体负载动态调整线程优先级。如果耗费 CPU 太多就降低线程优先级，如果线程过度挨饿，则会提升线程优先级。但是无论怎么变，程序都不能超过其所在线程的优先级区间范围。

可以看出，系统会根据内核启动参数和设备性能，开启 max_jetsam_threads 个（一般情况为1，特殊情况下可能为3）jetsam 线程，且这些线程的优先级为 95，也就是 MAXPRI_KERNEL（注意这里的 95 是线程的优先级，XNU 的线程优先级区间为：0～127。上文的宏定义是进程优先级，区间为：-2~19）。

紧接着，分析下 memorystatus_thread 函数，主要负责线程启动的初始化

static void
memorystatus_thread(void *param __unused, wait_result_t wr __unused)
{//...while (memorystatus_action_needed()) {boolean_t killed;int32_t priority;uint32_t cause;uint64_t jetsam_reason_code = JETSAM_REASON_INVALID;os_reason_t jetsam_reason = OS_REASON_NULL;cause = kill_under_pressure_cause;switch (cause) {case kMemorystatusKilledFCThrashing:jetsam_reason_code = JETSAM_REASON_MEMORY_FCTHRASHING;break;case kMemorystatusKilledVMCompressorThrashing:jetsam_reason_code = JETSAM_REASON_MEMORY_VMCOMPRESSOR_THRASHING;break;case kMemorystatusKilledVMCompressorSpaceShortage:jetsam_reason_code = JETSAM_REASON_MEMORY_VMCOMPRESSOR_SPACE_SHORTAGE;break;case kMemorystatusKilledZoneMapExhaustion:jetsam_reason_code = JETSAM_REASON_ZONE_MAP_EXHAUSTION;break;case kMemorystatusKilledVMPageShortage:/* falls through */default:jetsam_reason_code = JETSAM_REASON_MEMORY_VMPAGESHORTAGE;cause = kMemorystatusKilledVMPageShortage;break;}/* Highwater */boolean_t is_critical = TRUE;if (memorystatus_act_on_hiwat_processes(&errors, &hwm_kill, &post_snapshot, &is_critical)) {if (is_critical == FALSE) {/** For now, don't kill any other processes.*/break;} else {goto done;}}jetsam_reason = os_reason_create(OS_REASON_JETSAM, jetsam_reason_code);if (jetsam_reason == OS_REASON_NULL) {printf("memorystatus_thread: failed to allocate jetsam reason\n");}if (memorystatus_act_aggressive(cause, jetsam_reason, &jld_idle_kills, &corpse_list_purged, &post_snapshot)) {goto done;}/** memorystatus_kill_top_process() drops a reference,* so take another one so we can continue to use this exit reason* even after it returns*/os_reason_ref(jetsam_reason);/* LRU */killed = memorystatus_kill_top_process(TRUE, sort_flag, cause, jetsam_reason, &priority, &errors);sort_flag = FALSE;if (killed) {if (memorystatus_post_snapshot(priority, cause) == TRUE) {post_snapshot = TRUE;}/* Jetsam Loop Detection */if (memorystatus_jld_enabled == TRUE) {if ((priority == JETSAM_PRIORITY_IDLE) || (priority == system_procs_aging_band) || (priority == applications_aging_band)) {jld_idle_kills++;} else {/** We've reached into bands beyond idle deferred.* We make no attempt to monitor them*/}}if ((priority >= JETSAM_PRIORITY_UI_SUPPORT) && (total_corpses_count() > 0) && (corpse_list_purged == FALSE)) {/** If we have jetsammed a process in or above JETSAM_PRIORITY_UI_SUPPORT* then we attempt to relieve pressure by purging corpse memory.*/task_purge_all_corpses();corpse_list_purged = TRUE;}goto done;}if (memorystatus_avail_pages_below_critical()) {/** Still under pressure and unable to kill a process - purge corpse memory*/if (total_corpses_count() > 0) {task_purge_all_corpses();corpse_list_purged = TRUE;}if (memorystatus_avail_pages_below_critical()) {/** Still under pressure and unable to kill a process - panic*/panic("memorystatus_jetsam_thread: no victim! available pages:%llu\n", (uint64_t)memorystatus_available_pages);}}done:	}

可以看到它开启了一个 循环，memorystatus_action_needed() 来作为循环条件，持续释放内存。

static boolean_t
memorystatus_action_needed(void)
{
#if CONFIG_EMBEDDEDreturn (is_reason_thrashing(kill_under_pressure_cause) ||is_reason_zone_map_exhaustion(kill_under_pressure_cause) ||memorystatus_available_pages <= memorystatus_available_pages_pressure);
#else /* CONFIG_EMBEDDED */return (is_reason_thrashing(kill_under_pressure_cause) ||is_reason_zone_map_exhaustion(kill_under_pressure_cause));
#endif /* CONFIG_EMBEDDED */
}

它通过 vm_pagepout 发送的内存压力来判断当前内存资源是否紧张。几种情况：频繁的页面换出换进 is_reason_thrashing, Mach Zone 耗尽了 is_reason_zone_map_exhaustion、以及可用的页低于了 memory status_available_pages 这个门槛。

继续看 memorystatus_thread，会发现内存紧张时，将先触发 High-water 类型的 OOM，也就是说假如某个进程使用过程中超过了其使用内存的最高限制 hight water mark 时会发生 OOM。在 memorystatus_act_on_hiwat_processes() 中，通过 memorystatus_kill_hiwat_proc() 在优先级数组 memstat_bucket 中查找优先级最低的进程，如果进程的内存小于阈值（footprint_in_bytes <= memlimit_in_bytes）则继续寻找次优先级较低的进程，直到找到占用内存超过阈值的进程并杀死。

通常来说单个 App 很难触碰到 high water mark，如果不能结束任何进程，最终走到 memorystatus_act_aggressive，也就是大多数 OOM 发生的地方。

static boolean_t
memorystatus_act_aggressive(uint32_t cause, os_reason_t jetsam_reason, int *jld_idle_kills, boolean_t *corpse_list_purged, boolean_t *post_snapshot)
{// ...if ( (jld_bucket_count == 0) || (jld_now_msecs > (jld_timestamp_msecs + memorystatus_jld_eval_period_msecs))) {/* * Refresh evaluation parameters */jld_timestamp_msecs	 = jld_now_msecs;jld_idle_kill_candidates = jld_bucket_count;*jld_idle_kills		 = 0;jld_eval_aggressive_count = 0;jld_priority_band_max	= JETSAM_PRIORITY_UI_SUPPORT;}//...
}

上述代码看到，判断要不要真正执行 kill 是根据一定的时间间判断的，条件是：jld_now_msecs > (jld_timestamp_msecs + memorystatus_jld_eval_period_msecs。 也就是在 memorystatus_jld_eval_period_msecs 后才发生条件里面的 kill。

/* Jetsam Loop Detection */
if (max_mem <= (512 * 1024 * 1024)) {/* 512 MB devices */
memorystatus_jld_eval_period_msecs = 8000;	/* 8000 msecs == 8 second window */
} else {/* 1GB and larger devices */
memorystatus_jld_eval_period_msecs = 6000;	/* 6000 msecs == 6 second window */
}

其中 memorystatus_jld_eval_period_msecs 取值最小6秒。所以我们可以在6秒内做些处理。

3.2 开发者们整理所得

stackoverflow 上有一份数据，整理了各种设备的 OOM 临界值

device	crash amount:MB	total amount:MB	percentage of total
iPad1	127	256	49%
iPad2	275	512	53%
iPad3	645	1024	62%
iPad4(iOS 8.1)	585	1024	57%
Pad Mini 1st Generation	297	512	58%
iPad Mini retina(iOS 7.1)	696	1024	68%
iPad Air	697	1024	68%
iPad Air 2(iOS 10.2.1)	1383	2048	68%
iPad Pro 9.7"(iOS 10.0.2 (14A456))	1395	1971	71%
iPad Pro 10.5”(iOS 11 beta4)	3057	4000	76%
iPad Pro 12.9” (2015)(iOS 11.2.1)	3058	3999	76%
iPad 10.2(iOS 13.2.3)	1844	2998	62%
iPod touch 4th gen(iOS 6.1.1)	130	256	51%
iPod touch 5th gen	286	512	56%
iPhone4	325	512	63%
iPhone4s	286	512	56%
iPhone5	645	1024	62%
iPhone5s	646	1024	63%
iPhone6(iOS 8.x)	645	1024	62%
iPhone6 Plus(iOS 8.x)	645	1024	62%
iPhone6s(iOS 9.2)	1396	2048	68%
iPhone6s Plus(iOS 10.2.1)	1396	2048	68%
iPhoneSE(iOS 9.3)	1395	2048	68%
iPhone7(iOS 10.2)	1395	2048	68%
iPhone7 Plus(iOS 10.2.1)	2040	3072	66%
iPhone8(iOS 12.1)	1364	1990	70%
iPhoneX(iOS 11.2.1)	1392	2785	50%
iPhoneXS(iOS 12.1)	2040	3754	54%
iPhoneXS Max(iOS 12.1)	2039	3735	55%
iPhoneXR(iOS 12.1)	1792	2813	63%
iPhone11(iOS 13.1.3)	2068	3844	54%
iPhone11 Pro Max(iOS 13.2.3)	2067	3740	55%

3.3 触发当前 App 的 high water mark

我们可以写定时器，不断的申请内存，之后再通过 phys_footprint 打印当前占用内存，按道理来说不断申请内存即可触发 Jetsam 机制，强杀 App，那么最后一次打印的内存占用也就是当前设备的内存上限值。

timer = [NSTimer scheduledTimerWithTimeInterval:0.01 target:self selector:@selector(allocateMemory) userInfo:nil repeats:YES];- (void)allocateMemory {UIImageView *imageView = [[UIImageView alloc] initWithFrame:CGRectMake(0, 0, 100, 100)];UIImage *image = [UIImage imageNamed:@"AppIcon"];imageView.image = image;[array addObject:imageView];memoryLimitSizeMB = [self usedSizeOfMemory];if (memoryWarningSizeMB && memoryLimitSizeMB) {NSLog(@"----- memory warnning:%dMB, memory limit:%dMB", memoryWarningSizeMB, memoryLimitSizeMB);}
}- (int)usedSizeOfMemory {task_vm_info_data_t taskInfo;mach_msg_type_number_t infoCount = TASK_VM_INFO_COUNT;kern_return_t kernReturn = task_info(mach_task_self(), TASK_VM_INFO, (task_info_t)&taskInfo, &infoCount);if (kernReturn != KERN_SUCCESS) {return 0;}return (int)(taskInfo.phys_footprint/1024.0/1024.0);
}

3.4 适用于 iOS13 系统的获取方式

iOS13 开始 <os/proc.h> 中 size_t os_proc_available_memory(void); 可以查看当前可用内存。

Return Value

The number of bytes that the app may allocate before it hits its memory limit. If the calling process isn’t an app, or if the process has already exceeded its memory limit, this function returns 0.

Discussion

Call this function to determine the amount of memory available to your app. The returned value corresponds to the current memory limit minus the memory footprint of your app at the time of the function call. Your app’s memory footprint consists of the data that you allocated in RAM, and that must stay in RAM (or the equivalent) at all times. Memory limits can change during the app life cycle and don’t necessarily correspond to the amount of physical memory available on the device.

Use the returned value as advisory information only and don’t cache it. The precise value changes when your app does any work that affects memory, which can happen frequently.

Although this function lets you determine the amount of memory your app may safely consume, don’t use it to maximize your app’s memory usage. Significant memory use, even when under the current memory limit, affects system performance. For example, when your app consumes all of its available memory, the system may need to terminate other apps and system processes to accommodate your app’s requests. Instead, always consume the smallest amount of memory you need to be responsive to the user’s needs.

If you need more detailed information about the available memory resources, you can call task_info. However, be aware that task_info is an expensive call, whereas this function is much more efficient.

if (@available(iOS 13.0, *)) {return os_proc_available_memory() / 1024.0 / 1024.0;
}

App 内存信息的 API 可以在 Mach 层找到，mach_task_basic_info 结构体存储了 Mach task 的内存使用信息，其中 phys_footprint 就是应用使用的物理内存大小，virtual_size 是虚拟内存大小。

#define MACH_TASK_BASIC_INFO     20         /* always 64-bit basic info */
struct mach_task_basic_info {mach_vm_size_t  virtual_size;       /* virtual memory size (bytes) */mach_vm_size_t  resident_size;      /* resident memory size (bytes) */mach_vm_size_t  resident_size_max;  /* maximum resident memory size (bytes) */time_value_t    user_time;          /* total user run time forterminated threads */time_value_t    system_time;        /* total system run time forterminated threads */policy_t        policy;             /* default policy for new threads */integer_t       suspend_count;      /* suspend count for task */
};

所以获取代码为：

task_vm_info_data_t vmInfo;
mach_msg_type_number_t count = TASK_VM_INFO_COUNT;
kern_return_t kr = task_info(mach_task_self(), TASK_VM_INFO, (task_info_t)&vmInfo, &count);if (kr != KERN_SUCCESS) {return ;
}
CGFloat memoryUsed = (CGFloat)(vmInfo.phys_footprint/1024.0/1024.0);

可能有人好奇不应该是 resident_size 这个字段获取内存的使用情况吗？一开始测试后发现 resident_size 和 Xcode 测量结果差距较大。而使用 phys_footprint 则接近于 Xcode 给出的结果。且可以从 WebKit 源码中得到印证。

所以在 iOS13 上，我们可以通过 os_proc_available_memory 获取到当前可以用内存，通过 phys_footprint 获取到当前 App 占用内存，2者的和也就是当前设备的内存上限，超过即触发 Jetsam 机制。

- (CGFloat)limitSizeOfMemory {if (@available(iOS 13.0, *)) {task_vm_info_data_t taskInfo;mach_msg_type_number_t infoCount = TASK_VM_INFO_COUNT;kern_return_t kernReturn = task_info(mach_task_self(), TASK_VM_INFO, (task_info_t)&taskInfo, &infoCount);if (kernReturn != KERN_SUCCESS) {return 0;}return (CGFloat)((taskInfo.phys_footprint + os_proc_available_memory()) / (1024.0 * 1024.0);}return 0;
}

当前可以使用内存：1435.936752MB；当前 App 已占用内存：14.5MB，临界值：1435.936752MB + 14.5MB= 1450.436MB， 和 3.1 方法中获取到的内存临界值一样「iPhone 6s plus/13.3.1 手机 OOM 临界值为：(16384*92806)/(1024*1024)=1450.09375M」。

3.5 通过 XNU 获取内存限制值

在 XNU 中，有专门用于获取内存上限值的函数和宏，可以通过 memorystatus_priority_entry 这个结构体得到所有进程的优先级和内存限制值。

typedef struct memorystatus_priority_entry {pid_t pid;int32_t priority;uint64_t user_data;int32_t limit;uint32_t state;
} memorystatus_priority_entry_t;

其中，priority 代表进程优先级，limit 代表进程的内存限制值。但是这种方式需要 root 权限，由于没有越狱设备，我没有尝试过。

相关代码可查阅 kern_memorystatus.h 文件。需要用到函数 int memorystatus_control(uint32_t command, int32_t pid, uint32_t flags, void *buffer, size_t buffersize);

/* Commands */
#define MEMORYSTATUS_CMD_GET_PRIORITY_LIST            1
#define MEMORYSTATUS_CMD_SET_PRIORITY_PROPERTIES      2
#define MEMORYSTATUS_CMD_GET_JETSAM_SNAPSHOT          3
#define MEMORYSTATUS_CMD_GET_PRESSURE_STATUS          4
#define MEMORYSTATUS_CMD_SET_JETSAM_HIGH_WATER_MARK   5    /* Set active memory limit = inactive memory limit, both non-fatal	*/
#define MEMORYSTATUS_CMD_SET_JETSAM_TASK_LIMIT	      6    /* Set active memory limit = inactive memory limit, both fatal	*/
#define MEMORYSTATUS_CMD_SET_MEMLIMIT_PROPERTIES      7    /* Set memory limits plus attributes independently			*/
#define MEMORYSTATUS_CMD_GET_MEMLIMIT_PROPERTIES      8    /* Get memory limits plus attributes					*/
#define MEMORYSTATUS_CMD_PRIVILEGED_LISTENER_ENABLE   9    /* Set the task's status as a privileged listener w.r.t memory notifications  */
#define MEMORYSTATUS_CMD_PRIVILEGED_LISTENER_DISABLE  10   /* Reset the task's status as a privileged listener w.r.t memory notifications  */
#define MEMORYSTATUS_CMD_AGGRESSIVE_JETSAM_LENIENT_MODE_ENABLE  11   /* Enable the 'lenient' mode for aggressive jetsam. See comments in kern_memorystatus.c near the top. */
#define MEMORYSTATUS_CMD_AGGRESSIVE_JETSAM_LENIENT_MODE_DISABLE 12   /* Disable the 'lenient' mode for aggressive jetsam. */
#define MEMORYSTATUS_CMD_GET_MEMLIMIT_EXCESS          13   /* Compute how much a process's phys_footprint exceeds inactive memory limit */
#define MEMORYSTATUS_CMD_ELEVATED_INACTIVEJETSAMPRIORITY_ENABLE 	14 /* Set the inactive jetsam band for a process to JETSAM_PRIORITY_ELEVATED_INACTIVE */
#define MEMORYSTATUS_CMD_ELEVATED_INACTIVEJETSAMPRIORITY_DISABLE 	15 /* Reset the inactive jetsam band for a process to the default band (0)*/
#define MEMORYSTATUS_CMD_SET_PROCESS_IS_MANAGED       16   /* (Re-)Set state on a process that marks it as (un-)managed by a system entity e.g. assertiond */
#define MEMORYSTATUS_CMD_GET_PROCESS_IS_MANAGED       17   /* Return the 'managed' status of a process */
#define MEMORYSTATUS_CMD_SET_PROCESS_IS_FREEZABLE     18   /* Is the process eligible for freezing? Apps and extensions can pass in FALSE to opt out of freezing, i.e.,

伪代码

struct memorystatus_priority_entry memStatus[NUM_ENTRIES];
size_t count = sizeof(struct memorystatus_priority_entry) * NUM_ENTRIES;
int kernResult = memorystatus_control(MEMORYSTATUS_CMD_GET_PRIORITY_LIST, 0, 0, memStatus, count);
if (rc < 0) {NSLog(@"memorystatus_control"); return ;
}int entry = 0;
for (; rc > 0; rc -= sizeof(struct memorystatus_priority_entry)){printf ("PID: %5d\tPriority:%2d\tUser Data: %llx\tLimit:%2d\tState:%s\n",memstatus[entry].pid,memstatus[entry].priority,memstatus[entry].user_data,memstatus[entry].limit,state_to_text(memstatus[entry].state));entry++;
}

for 循环打印出每个进程（也就是 App）的 pid、Priority、User Data、Limit、State 信息。从 log 中找出优先级为10的进程，即我们前台运行的 App。为什么是10？ 因为 #define JETSAM_PRIORITY_FOREGROUND 10 我们的目的就是获取前台 App 的内存上限值。

4. 如何判定发生了 OOM

OOM 导致 crash 前，app 一定会收到低内存警告吗？

做 2 组对比实验：

// 实验1
NSMutableArray *array = [NSMutableArray array];
for (NSInteger index = 0; index < 10000000; index++) {NSString *filePath = [[NSBundle mainBundle] pathForResource:@"Info" ofType:@"plist"];NSData *data = [NSData dataWithContentsOfFile:filePath];[array addObject:data];
}

// 实验2
// ViewController.m
- (void)viewDidLoad {[super viewDidLoad];dispatch_async(dispatch_get_global_queue(0, 0), ^{NSMutableArray *array = [NSMutableArray array];for (NSInteger index = 0; index < 10000000; index++) {NSString *filePath = [[NSBundle mainBundle] pathForResource:@"Info" ofType:@"plist"];NSData *data = [NSData dataWithContentsOfFile:filePath];[array addObject:data];}});
}
- (void)didReceiveMemoryWarning
{NSLog(@"2");
}// AppDelegate.m
- (void)applicationDidReceiveMemoryWarning:(UIApplication *)application
{NSLog(@"1");
}

现象：

1. 在 viewDidLoad 也就是主线程中内存消耗过大，系统并不会发出低内存警告，直接 Crash。因为内存增长过快，主线程很忙。
2. 多线程的情况下，App 因内存增长过快，会收到低内存警告，AppDelegate 中的applicationDidReceiveMemoryWarning 先执行，随后是当前 VC 的 didReceiveMemoryWarning。

结论：

收到低内存警告不一定会 Crash，因为有6秒钟的系统判断时间，6秒内内存下降了则不会 crash。发生 OOM 也不一定会收到低内存警告。

5. 内存信息收集

要想精确的定位问题，就需要 dump 所有对象及其内存信息。当内存接近系统内存上限的时候，收集并记录所需信息，结合一定的数据上报机制，上传到服务器，分析并修复。

还需要知道每个对象具体是在哪个函数里创建出来的，以便还原“案发现场”。

源代码（libmalloc/malloc），内存分配函数 malloc 和 calloc 等默认使用 nano_zone，nano_zone 是小于 256B 以下的内存分配，大于 256B 则使用 scalable_zone 来分配。

主要针对大内存的分配监控。malloc 函数用的是 malloc_zone_malloc, calloc 用的是 malloc_zone_calloc。

使用 scalable_zone 分配内存的函数都会调用 malloc_logger 函数，因为系统为了有个地方专门统计并管理内存分配情况。这样的设计也满足「收口原则」。

void *
malloc(size_t size)
{void *retval;retval = malloc_zone_malloc(default_zone, size);if (retval == NULL) {errno = ENOMEM;}return retval;
}void *
calloc(size_t num_items, size_t size)
{void *retval;retval = malloc_zone_calloc(default_zone, num_items, size);if (retval == NULL) {errno = ENOMEM;}return retval;
}

首先来看看这个 default_zone 是什么东西, 代码如下

typedef struct {malloc_zone_t malloc_zone;uint8_t pad[PAGE_MAX_SIZE - sizeof(malloc_zone_t)];
} virtual_default_zone_t;static virtual_default_zone_t virtual_default_zone
__attribute__((section("__DATA,__v_zone")))
__attribute__((aligned(PAGE_MAX_SIZE))) = {NULL,NULL,default_zone_size,default_zone_malloc,default_zone_calloc,default_zone_valloc,default_zone_free,default_zone_realloc,default_zone_destroy,DEFAULT_MALLOC_ZONE_STRING,default_zone_batch_malloc,default_zone_batch_free,&default_zone_introspect,10,default_zone_memalign,default_zone_free_definite_size,default_zone_pressure_relief,default_zone_malloc_claimed_address,
};static malloc_zone_t *default_zone = &virtual_default_zone.malloc_zone;static void *
default_zone_malloc(malloc_zone_t *zone, size_t size)
{zone = runtime_default_zone();return zone->malloc(zone, size);
}MALLOC_ALWAYS_INLINE
static inline malloc_zone_t *
runtime_default_zone() {return (lite_zone) ? lite_zone : inline_malloc_default_zone();
}

可以看到 default_zone 通过这种方式来初始化

static inline malloc_zone_t *
inline_malloc_default_zone(void)
{_malloc_initialize_once();// malloc_report(ASL_LEVEL_INFO, "In inline_malloc_default_zone with %d %d\n", malloc_num_zones, malloc_has_debug_zone);return malloc_zones[0];
}

随后的调用如下

_malloc_initialize -> create_scalable_zone -> create_scalable_szone 最终我们创建了 szone_t 类型的对象，通过类型转换，得到了我们的 default_zone。

malloc_zone_t *
create_scalable_zone(size_t initial_size, unsigned debug_flags) {return (malloc_zone_t *) create_scalable_szone(initial_size, debug_flags);
}

void *malloc_zone_malloc(malloc_zone_t *zone, size_t size)
{MALLOC_TRACE(TRACE_malloc | DBG_FUNC_START, (uintptr_t)zone, size, 0, 0);void *ptr;if (malloc_check_start && (malloc_check_counter++ >= malloc_check_start)) {internal_check();}if (size > MALLOC_ABSOLUTE_MAX_SIZE) {return NULL;}ptr = zone->malloc(zone, size);// 在 zone 分配完内存后就开始使用 malloc_logger 进行进行记录if (malloc_logger) {malloc_logger(MALLOC_LOG_TYPE_ALLOCATE | MALLOC_LOG_TYPE_HAS_ZONE, (uintptr_t)zone, (uintptr_t)size, 0, (uintptr_t)ptr, 0);}MALLOC_TRACE(TRACE_malloc | DBG_FUNC_END, (uintptr_t)zone, size, (uintptr_t)ptr, 0);return ptr;
}

其分配实现是 zone->malloc 根据之前的分析，就是szone_t结构体对象中对应的malloc实现。

在创建szone之后，做了一系列如下的初始化操作。

// Initialize the security token.
szone->cookie = (uintptr_t)malloc_entropy[0];szone->basic_zone.version = 12;
szone->basic_zone.size = (void *)szone_size;
szone->basic_zone.malloc = (void *)szone_malloc;
szone->basic_zone.calloc = (void *)szone_calloc;
szone->basic_zone.valloc = (void *)szone_valloc;
szone->basic_zone.free = (void *)szone_free;
szone->basic_zone.realloc = (void *)szone_realloc;
szone->basic_zone.destroy = (void *)szone_destroy;
szone->basic_zone.batch_malloc = (void *)szone_batch_malloc;
szone->basic_zone.batch_free = (void *)szone_batch_free;
szone->basic_zone.introspect = (struct malloc_introspection_t *)&szone_introspect;
szone->basic_zone.memalign = (void *)szone_memalign;
szone->basic_zone.free_definite_size = (void *)szone_free_definite_size;
szone->basic_zone.pressure_relief = (void *)szone_pressure_relief;
szone->basic_zone.claimed_address = (void *)szone_claimed_address;

其他使用 scalable_zone 分配内存的函数的方法也类似，所以大内存的分配，不管外部函数如何封装，最终都会调用到 malloc_logger 函数。所以我们可以用 fishhook 去 hook 这个函数，然后记录内存分配情况，结合一定的数据上报机制，上传到服务器，分析并修复。

// For logging VM allocation and deallocation, arg1 here
// is the mach_port_name_t of the target task in which the
// alloc or dealloc is occurring. For example, for mmap()
// that would be mach_task_self(), but for a cross-task-capable
// call such as mach_vm_map(), it is the target task.typedef void (malloc_logger_t)(uint32_t type, uintptr_t arg1, uintptr_t arg2, uintptr_t arg3, uintptr_t result, uint32_t num_hot_frames_to_skip);extern malloc_logger_t *__syscall_logger;

当 malloc_logger 和 __syscall_logger 函数指针不为空时，malloc/free、vm_allocate/vm_deallocate 等内存分配/释放通过这两个指针通知上层，这也是内存调试工具 malloc stack 的实现原理。有了这两个函数指针，我们很容易记录当前存活对象的内存分配信息（包括分配大小和分配堆栈）。分配堆栈可以用 backtrace 函数捕获，但捕获到的地址是虚拟内存地址，不能从符号表 dsym 解析符号。所以还要记录每个 image 加载时的偏移 slide，这样 符号表地址 = 堆栈地址 - slide。

小 tips：

ASLR（Address space layout randomization）：常见称呼为位址空间随机载入、位址空间配置随机化、位址空间布局随机化，是一种防止内存损坏漏洞被利用的计算机安全技术，通过随机放置进程关键数据区域的定址空间来放置攻击者能可靠地跳转到内存的特定位置来操作函数。现代作业系统一般都具备该机制。

函数地址 add: 函数真实的实现地址;

函数虚拟地址：vm_add;

ASLR: slide 函数虚拟地址加载到进程内存的随机偏移量，每个 mach-o 的 slide 各不相同。vm_add + slide = add。也就是：*(base +offset)= imp。

由于腾讯也开源了自己的 OOM 定位方案- OOMDetector ，有了现成的轮子，那么用好就可以了，所以对于内存的监控思路就是找到系统给 App 的内存上限，然后当接近内存上限值的时候，dump 内存情况，组装基础数据信息成一个合格的上报数据，经过一定的数据上报策略到服务端，服务端消费数据，分析产生报表，客户端工程师根据报表分析问题。不同工程的数据以邮件、短信、企业微信等形式通知到该项目的 owner、开发者。（情况严重的会直接电话给开发者，并给主管跟进每一步的处理结果）。
问题分析处理后要么发布新版本，要么 hot fix。

6. 开发阶段针对内存我们能做些什么

1. 图片缩放

   WWDC 2018 Session 416 - iOS Memory Deep Dive，处理图片缩放的时候直接使用 UIImage 会在解码时读取文件而占用一部分内存，还会生成中间位图 bitmap 消耗大量内存。而 ImageIO 不存在上述2种弊端，只会占用最终图片大小的内存

   做了2组对比实验：给 App 显示一张图片

   // 方法1: 19.6M
   UIImage *imageResult = [self scaleImage:[UIImage imageNamed:@"test"]                                                  newSize:CGSizeMake(self.view.frame.size.width, self.view.frame.size.height)];
   self.imageView.image = imageResult;// 方法2: 14M
   NSData *data = UIImagePNGRepresentation([UIImage imageNamed:@"test"]);
   UIImage *imageResult = [self scaledImageWithData:data 				    withSize:CGSizeMake(self.view.frame.size.width, self.view.frame.size.height) scale:3 orientation:UIImageOrientationUp];
   self.imageView.image = imageResult;- (UIImage *)scaleImage:(UIImage *)image newSize:(CGSize)newSize
   {UIGraphicsBeginImageContextWithOptions(newSize, NO, 0);[image drawInRect:CGRectMake(0, 0, newSize.width, newSize.height)];UIImage *newImage = UIGraphicsGetImageFromCurrentImageContext();UIGraphicsEndImageContext();return newImage;
   }- (UIImage *)scaledImageWithData:(NSData *)data withSize:(CGSize)size scale:(CGFloat)scale orientation:(UIImageOrientation)orientation
   {CGFloat maxPixelSize = MAX(size.width, size.height);CGImageSourceRef sourceRef = CGImageSourceCreateWithData((__bridge CFDataRef)data, nil);NSDictionary *options = @{(__bridge id)kCGImageSourceCreateThumbnailFromImageAlways : (__bridge id)kCFBooleanTrue,(__bridge id)kCGImageSourceThumbnailMaxPixelSize : [NSNumber numberWithFloat:maxPixelSize]};CGImageRef imageRef = CGImageSourceCreateThumbnailAtIndex(sourceRef, 0, (__bridge CFDictionaryRef)options);UIImage *resultImage = [UIImage imageWithCGImage:imageRef scale:scale orientation:orientation];CGImageRelease(imageRef);CFRelease(sourceRef);return resultImage;
   }
   

   可以看出使用 ImageIO 比使用 UIImage 直接缩放占用内存更低。

2. 合理使用 autoreleasepool

   我们知道 autoreleasepool 对象是在 RunLoop 结束时才释放。在 ARC 下，我们如果在不断申请内存，比如各种循环，那么我们就需要手动添加 autoreleasepool，避免短时间内内存猛涨发生 OOM。

对比实验

// 实验1
NSMutableArray *array = [NSMutableArray array];
for (NSInteger index = 0; index < 10000000; index++) {NSString *indexStrng = [NSString stringWithFormat:@"%zd", index];NSString *resultString = [NSString stringWithFormat:@"%zd-%@", index, indexStrng];[array addObject:resultString];
}// 实验2
NSMutableArray *array = [NSMutableArray array];
for (NSInteger index = 0; index < 10000000; index++) {@autoreleasepool {NSString *indexStrng = [NSString stringWithFormat:@"%zd", index];NSString *resultString = [NSString stringWithFormat:@"%zd-%@", index, indexStrng];[array addObject:resultString];}
}

实验1消耗内存 739.6M，实验2消耗内存 587M。

3. UIGraphicsBeginImageContext 和 UIGraphicsEndImageContext 必须成双出现，不然会造成 context 泄漏。另外 XCode 的 Analyze 也能扫出这类问题。

4. 不管是打开网页，还是执行 js，都应该使用 WKWebView。UIWebView 会占用大量内存，从而导致 App 发生 OOM 的几率增加，而 WKWebView 是一个多进程组件，Network Loading 以及 UI Rendering 在其它进程中执行，比 UIWebView 占用更低的内存开销。

5. 在做 SDK 或者 App，如果场景是缓存相关，尽量使用 NSCache 而不是 NSMutableDictionary。它是系统提供的专门处理缓存的类，NSCache 分配的内存是 Purgeable Memory，可以由系统自动释放。NSCache 与 NSPureableData 的结合使用可以让系统根据情况回收内存，也可以在内存清理时移除对象。

   其他的开发习惯就不一一描述了，良好的开发习惯和代码意识是需要平时注意修炼的。