最近在研究 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:
所以基于这些只能推测 rpages 应该是 resident pages 的缩写，表示当前进程占用的内存页数量(_)。
再次声明：此结论不一定准确，仅供参考。
3. 基于内存上限值，能够指导我们做些什么？
其实这个问题，我也没想到太多有用的思路，下面是目前我能想到的一些点，仅供参考：
- 首先对自己的 APP 内存占用情况有个清晰的了解：可以收集 APP 在线上使用过程中占用的最大内存值。最好是实时记录，尽量精确一些。然后根据收集上来的值分别统计出 1GB 设备、2GB/3GB 设备上的内存分布。
- 如果上面统计到的值中 2GB、3GB 设备上有不少大于 650M 的情况，那么就需要采取一定的优化策略尽量降低 App 的最大内存值。比如：去响应系统发出的内存警告的通知，做一些内存清理工作。
