基于 JetsamEvent 探究 APP 最大内存占用上限

最近在研究 iOS 上内存 OOM 的问题，其中看到这篇文章 Handling low memory conditions in iOS and Mavericks 中提到了一点：

Jetsam has another modus operandi, which uses a process memory "high water mark", and will outright kill processes exceeding their HWM.

它这里表明每个进程都有一个 HWM，超过这个值时就会触发 Jetsam 机制去 kill 这个进程。这时我就很好奇了，这个 HWM 的值究竟是多少呢？

1. 在 1GB RAM 的设备上的内存占用上限

于是，我写了一个 Demo，代码很简单：创建了一个定时器，每隔 0.05 秒去不断的申请分配内存并初始化内存。

接着，在自己的 iPhone 6P 上运行了一下 (运行之前把手机后台的进程全部手动kill了)，过一会儿就崩掉了，同时控制台打印了一行 Log：

Message from debugger: Terminated due to memory issue

这时，我去手机的 设置->隐私->分析->分析数据 里找到了刚才进程被 kill 时生成的 JetsamEvent 日志，在里面找到了一些有用的信息：

"pageSize" : 4096,
{
    "uuid" : "8e20cd83-0b76-3bf3-b909-563a5ea89d89",
    "states" : [
      "frontmost",
      "resume"
    ],
    "killDelta" : 7350,
    "genCount" : 0,
    "age" : 816388409,
    "purgeable" : 0,
    "fds" : 25,
    "coalition" : 1482,
    "rpages" : 166400,
    "reason" : "per-process-limit",
    "pid" : 6281,
    "cpuTime" : 2.1654900000000001,
    "name" : "MemoryLimitTest",
    "lifetimeMax" : 41686
}

首先，pageSize 字段表明当前内存页的大小是 4K，大括号里面的内容是我们的 Demo 进程的一些信息，其中最有用的是这 2 个字段："reason"、"rpages"。reason 字段表明进程被 kill 的原因是超过进程的内存限制；rpages 字段应该是 resident pages 的缩写，表明进程当前占用的内存页数量。

因此，基于上面的 pageSize 与 rpages，可以算出进程占用的内存大小为：166400 * 4096 / 1024 / 1024 = 650M。也就是说，在 1GB 的设备上前台 APP 最大可占用内存上限为 650MB。

2. 在 2GB/3GB RAM 的设备上的内存占用上限

然后我又各找了一部 iPhone 8 和 iPhone X，分别运行 Demo 后，发现在这 2 个设备上的崩溃信息是一样的：

"pageSize" : 16384
{
    "uuid" : "b8d6682c-5903-3007-b9c2-561d1e6ca9d5",
    "states" : [
      "frontmost",
      "resume"
    ],
    "killDelta" : 18859,
    "genCount" : 0,
    "age" : 1775369503,
    "purgeable" : 0,
    "fds" : 50,
    "coalition" : 691,
    "rpages" : 89600,
    "reason" : "per-process-limit",
    "pid" : 960,
    "cpuTime" : 1.6920809999999999,
    "name" : "MemoryLimitTest",
    "lifetimeMax" : 34182
}

同样通过 pageSize、rpages 字段的值可以算出：89600 * 16384 / 1024 / 1024 = 1400M。即在 2GB/3GB RAM 的设备上前台 APP 内存占用上限是 1400M。

这里纠正为：在 2GB RAM 和 iPhone X 上前台 APP 内存占用上限是 1400M。

因为根据我们自己 APP 统计到的值，发现在 iPhone 8 Plus 上最大内存值有超过 1400MB 的，所以又找了一个 iPhone 7 Plus 运行了一下(主要是没找到 8P)，发现 JetsamEvent 数据跟 iPhone X 果然不一样：

"pageSize" : 16384
{
    "uuid" : "d6493379-0e74-3a0f-9972-9bbcdd4a7f89",
    "states" : [
      "frontmost",
      "resume"
    ],
    "killDelta" : 19168,
    "genCount" : 0,
    "age" : 2460511710,
    "purgeable" : 0,
    "fds" : 50,
    "coalition" : 1205,
    "rpages" : 131072,
    "reason" : "per-process-limit",
    "pid" : 4476,
    "cpuTime" : 3.0866069999999999,
    "name" : "MemoryLimitTest",
    "lifetimeMax" : 38571
}

通过 pageSize、rpages 字段的值算出：131072 * 16384 / 1024 / 1024 = 2048MB。即在 3GB RAM 的设备上前台 APP 内存占用上限是 2048MB（iPhone X 除外）。

为什么 iPhone X 不一样呢，我通过如下代码获取了设备总内存大小：

double allMemory = [[NSProcessInfo processInfo] physicalMemory]; 
double totalMemory = (allMemory / 1024.0) / 1024.0;

发现在 iPhone 7 Plus 上得到的值是 3072MB，而 iPhone X 上是 2816MB。可能是这个原因导致 iPhone X 有特殊吧。

---

结果出来了，但是是否靠谱呢？实话说，当时通过这种方式拿到这个结果之后，我心里也不是很确定。所以就开始去查找相关的官方文档，结果官方文档中只找到了 2 篇相关文档和 1 个 WWDC2010 的 session：

• Understanding Low Memory Reports
• Understanding Memory Usage Limits for WatchKit Apps and Extensions
• Understanding Crash Reports on iPhone OS（第18-24分钟）

其中第 1 篇介绍的更多一些，这里我只摘出一部分重要的信息：

The format of a low memory report differs from other crash reports in that there are no backtraces for the application threads. A low memory report begins with a header similar to the Header of a crash report. Following the header are a collection of fields listing system-wide memory statistics. Take note of the value for the Page Size field. The memory usage of each process in a low memory report is reported in terms of number of memory pages.

The most important part of a low memory report is the table of processes. This table lists all running processes, including system daemons, at the time the low memory report was generated. If a process was "jettisoned", the reason will be listed under the [reason] column. A process may be jettisoned for a number of reasons:

• [per-process-limit]: The process crossed its system-imposed memory limit. Per-process limits on resident memory are established by the system for all applications. Crossing this limit makes the process eligible for termination.

这段对 JetsamEvent 中的内容作了简单的描述，其中提到了 Page Size 字段；每个进程所使用的内存页数量；以及被 kill 时的 [reason] 项，其中 [per-process-limit] 表示进程内存占用超过了此进程的内存限制。

通过这部分官方描述，可以与上面的 pageSize、reason 相吻合，但是文档在提到当前进程所占用的内存页数量时，没有明确指出是 rpages 项。不过在 session 视频中有提到是 count resident pages:

residentPages.png

所以基于这些只能推测 rpages 应该是 resident pages 的缩写，表示当前进程占用的内存页数量(^_)。

再次声明：此结论不一定准确，仅供参考。

3. 基于内存上限值，能够指导我们做些什么？

其实这个问题，我也没想到太多有用的思路，下面是目前我能想到的一些点，仅供参考：

1. 首先对自己的 APP 内存占用情况有个清晰的了解：可以收集 APP 在线上使用过程中占用的最大内存值。最好是实时记录，尽量精确一些。然后根据收集上来的值分别统计出 1GB 设备、2GB/3GB 设备上的内存分布。
2. 如果上面统计到的值中 2GB、3GB 设备上有不少大于 650M 的情况，那么就需要采取一定的优化策略尽量降低 App 的最大内存值。比如：去响应系统发出的内存警告的通知，做一些内存清理工作。