iOS内存二三事：三大分类解析、指标监控与OOM异常处理全攻略

本次分享，主要从科普有关内存定义和相关名词解释，了解三大内存分类、如何做内存指标监控和常见内存问题--OOM异常监控的进行展开，希望对大家有帮助。

内存二三事

iOS内存分区从高地址到低地址各区域如下：

常量区：

存放的是常量，如常量字符串，程序结束后由系统释放；

代码区：存放函数体的二进制代码，程序结束后由系统释放；

三大内存分类

从 iOS7 开始，系统开始采用Compressed Memory机制优化内存使用，内存类型可以分为三类：

Dirty Memory：指那些被写入过数据的内存，主要包括：在使用 framework 的过程中会产生Dirty Memory，使用单例或者全局初始化方法是减少Dirty Memory；这是因为单例一旦创建就不会销毁，全局初始化方法会在 class 加载时执行。复制代码

Compressed Memory：

说明：在内存吃紧的情况下，释放Clean Memory，不能释放Dirty Memory ，所以Dirty Memory 的内存越多，App的稳定性越差。

内存监控

在了解了内存原理和基础知识后，建议大家可以做一个线上的监控，定位和分析应用在运行期间的实时内存或阶段内存占用情况。

为了能够监测app的内存占用情况，我们通过相应的策略采集到app使用时的应用使用内存、设备可用内存、设备总内存等数据来帮助分析。

采集内存的几个注意点

Resident Memory是已经被映射到虚拟内存中的物理内存。

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

使用时发现这个和Xcode中大小不一致，而phys_footprint才是真正消耗的物理内存同时也和Xcode的大小更接近。

App消耗的实际物理内存（Memory Footprint），包括：

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

应用的可用内存我们采集的是空闲内存（Usage Comparison Free），空闲内存看成总内存大小减去 Wired Memory大小，Active Memory大小以及Inactive Memory大小。在32位系统通过这种方式获取空闲内存与Xcode数据作比较误差范围较小，而在64位系统上的数据与Xcode数据一比较误差较大，最终选择了一个逆向Xcode获取Xcode的计算内存方法。

内存的常见类问题

内存的问题其实可以分为 OOM异常、大对象、内存泄漏三大类， 本次内容我们先从OOM异常讲起。

首先在了解iOS OOM之前，必须要先了解一个概念即Jetsam机制。Jetsam是 iOS 操作系统为了控制内存资源过度使用而采用的一种资源管控机制。不同于MacOS，Linux，Windows等桌面操作系统，出于性能方面的考虑，iOS 系统并没有设计内存交换空间的机制，所以在 iOS 中，如果设备整体内存紧张的话，系统只能将一些优先级不高或占用内存过大的进程直接终止掉。

OOM 其实是Out Of Memory的简称，指的是在 iOS 设备上当前应用因为内存占用过高而被操作系统强制终止，在用户侧的感知就是 App 一瞬间的闪退，与普通的 Crash 没有明显差异。但是当我们在调试阶段遇到这种崩溃的时候，从设备设置-隐私-分析与改进中是找不到普通类型的崩溃日志，只能够找到Jetsam开头的日志，这种形式的日志其实就是 OOM 崩溃之后系统生成的一种专门反映内存异常问题的日志。它是由 iOS 的Jetsam机制造成的一种非主流 Crash，它不能通过 Signal 这种监控方案所捕获。

OOM 分为FOOM和BOOM两种类型，显然前者因为用户的感知更明显，所以对用户的体验的伤害更大，下文中提到的 OOM 崩溃仅指的是FOOM。那么针对 OOM 崩溃问题有必要建立线上的监控手段吗？

答案是有而且非常有必要的！原因如下：

翻阅XNU源码的时候我们可以看到在Jetsam机制终止进程的时候最终是通过发送SIGKILL异常信号来完成的。

#define SIGKILL 9 kill (cannot be caught or ignored)

从系统库 signal.h 文件中我们可以找到SIGKILL这个异常信号的解释，它不可以在当前进程被忽略或者被捕获，我们之前监听异常信号的常规 Crash 捕获方案肯定也就不适用了。那我们应该如何监控 OOM 崩溃呢？

正面监控这条路行不通，2015 年的时候Facebook提出了另外一种思路，简而言之就是排除法。具体流程可以参考下面这张流程图：

发现FOOM问题的关键：监控App使用内存增长，在收到内存警告通知时，dump 内存信息，获取对象名称、对象个数、各对象的内存值，并在合适的时机上报到服务器；加强对大内存的分配监控。

在这个判断逻辑中至少会将以下几种场景误判：

因此在实际的问题处理环节，我们需要关注上述几种误判情况，可以尝试做这三部分的专项治理。

关于U-APM 应用性能监控平台

目前上述提到的 iOS OOM 异常监控，在U-APM的专业版/尊享版中可以使用

友盟+应用性能监测U-APM通过轻量级的集成接入即可拥有免费、实时、可靠、全面的应用崩溃、ANR、自定义异常等捕获能力，及卡顿、启动、内存分析等性能监控能力，支持多场景、多通道智能告警监控，帮助开发者高效还原异常、卡顿用户的访问路径和业务现场，缩短故障排查时间。同时，友盟+提供在线客服、工单系统、项目服务群等多种服务方式，及时响应客户问题。更多请访问：https://www.umeng.com/apm?

参考

关于iOS内存的深入排查和优化

iOS 获取设备内存信息