分配器对比与跨平台内存管理分析

0. 概述与方法论

本文是一组围绕"移动端内存管理"的源码级分析，全部基于在真实越狱 iPhone 上的实测 + 官方开源仓库逐行核对。覆盖原始需求的两部分：① pagefault 延迟实测（§5）② 内存压缩/解压性能（§6）+ 分配器对比（§1）。核心方法：

• 实测在设备上跑真实汇编：链接 XNU 的 WKdm arm64 汇编直接运行，而非用公共 libcompression 库——测的是设备真实压缩器。
• 交叉编译三方分配器为 arm64 静态库（je_/mi_ 前缀，不覆盖 libc），与原生 libmalloc 跑同等工作负载，每后端独立 fork() 子进程隔离 RSS。
• 源码级溯源：每个结论附带文件名+行号引用（file.c:NNN），不只靠记忆。
• 假设被数据证伪也照实写（见 §7 鸿蒙、§1 的 shared_churn）——bench 的价值正在于它能推翻先入之见。

测试环境与方法细节

1. 分配器实测对比（libmalloc / jemalloc / mimalloc / scudo）

1.1 测试方法与配置依据

8 个工作负载覆盖：快路径延迟（pair_32b/4kb/1mb）、驻留（hold_20k）、大块（large_1mb）、realloc 增长、线程争用（threaded_4t）、跨线程对象流（shared_churn_6t）。配置依据对齐移动端真实默认：

核心工作负载源码（allocbench.c）

/* 每个线程 malloc + atomic_exchange 到共享 slot pool + free 旧对象。
 * 对象在线程间流动：线程 A (核 X) 分配的块被线程 B (核 Y) 释放。
 * jemalloc 走 cross-tcache/remote-free 路径，libmalloc 的 per-CPU 杂志
 * 释放到当前 CPU——锁的 cache line 不跨核弹跳。*/
static void* sc(void*x) {
  struct scarg*a=x; backend_t*b=a->b;
  double t0=now_us(); long c=0; uint32_t s=a->seed;
  while(now_us()-t0 < a->dur*1e6){
    for(int i=0;i<1000;i++){
      s^=s<<13; s^=s>>17; s^=s<<5;     /* xorshift 线程本地 RNG */
      int idx = (int)(s % (uint32_t)a->nslots);
      void *np = b->malloc(a->sz);
      void *old = atomic_exchange(&a->slots[idx], np); /* 原子交换 */
      if(old) b->free(old);  /* 释放另一个线程可能分配的块 */
      c++;
    }
  }
  __atomic_fetch_add(a->ops, c, __ATOMIC_RELAXED);
}

Compressor 系统计数器提取（memperf.c:read_comp_counters）

/* 通过 sysctl 提取内核压缩器的完整计数器 */
c->input_bytes     = sysctl_u64("vm.compressor_input_bytes");
c->compressed_bytes= sysctl_u64("vm.compressor_compressed_bytes");
c->bytes_used      = sysctl_u64("vm.compressor_bytes_used");
c->wk_comp         = sysctl_u64("vm.wk_compressions");
c->lz4_comp       = sysctl_u64("vm.lz4_compressions");
c->lz4_threshold  = sysctl_u64("vm.lz4_threshold");   /* 12288: 12KB 阈值 */
/* mode 32 下 wk_comp/lz4_comp 均为 0 — 统一计数路径 */

1.2 实测结果（hold_20k：live≈170MB）

1.3 shared_churn_6t：验证假设·证伪

原假设：跨线程对象流动（A 分配的块 B 释放）会触发同核争用+跨核 cache 弹跳，libmalloc 的 per-CPU 杂志锁局部性优势应显现、缩小与 jemalloc 的 gap。workload：6 线程共享 2048 槽池，每线程 malloc(64)+atomic_exchange(slots[i],new)+free(old)。

每线程速率：libmalloc 1.58M ops/t（跌 7.2×）、jemalloc 10.0M ops/t（跌 4.8×）——libmalloc 跌得更狠，假设被证伪。

根因（源码级）：① libmalloc 每操作付两把杂志锁（malloc 的 SZONE_MAGAZINE_PTR_LOCK+free 的锁，libmalloc/magazine_tiny.c:2409/506）叠加争用的 atomic_exchange；② jemalloc 跨线程 free 免费——je_free 对小对象总进当前线程 tcache（不追踪分配者），无 remote-free 惩罚，快路径仍无锁（jemalloc/include/jemalloc/internal/cache_bin.h:348），只付 atomic 争用。→ per-CPU 锁局部性真实但不足以抵消"两次锁/次"的固定开销；jemalloc per-thread 无锁 tcache 在所有吞吐场景都赢。

1.4 scudo：安全优先的加固分配器

scudo（LLVM Sanitizer Combined Allocator successor）是 Android 11+ 的默认分配器，设计目标是安全加固而非极致速度。上游 scudo standalone 只有 linux.cpp/fuchsia.cpp/trusty.cpp 三个平台层，没有 Darwin 端口。本次测试写了完整的 Darwin 平台层（darwin.cpp：用 os_unfair_lock 替代 Linux futex、arc4random_buf 替代 getrandom syscall、mach_task_basic_info 替代 /proc/self/statm），是首个在真实 iOS 设备上跑的 scudo benchmark。

1.4a 线程扩展性实测：1→2→4→6 线程

A14 Bionic 有 6 核（2 Firestorm 性能核 + 4 Icestorm 能效核）。测试方法：N 个线程各自做 64B malloc/free 循环 0.5 秒，统计总 ops/sec。关键问题：哪个分配器扩展性最好？

1. 所有分配器扩展性几乎相同（3.90×-4.00×）——无论 per-CPU（libmalloc）、per-thread（jemalloc/mimalloc）还是 size-class（scudo），多线程扩展倍率一致。→ 扩展性瓶颈是硬件（6 核中 4 核有效），不是分配器。
2. 1→2→4 线程完美线性（每翻倍 ~2×），但 4→6 线程几乎不增长（+0.6%-1.7%）。原因：A14 的 2 个性能核（Firestorm）在 4 线程时已被占满，第 5-6 线程只能跑在能效核（Icestorm，频率低 ~50%）上，贡献极小。
3. 分配器只决定每线程天花板，不决定扩展性：jemalloc 单线程 46.7M vs libmalloc 11.2M（4.2× 差距），但 6 线程时 182.7M vs 44.1M（仍 4.1× 差距）——差距不随线程数收敛。libmalloc 的 per-CPU 杂志没有在多线程时追上 jemalloc 的 per-thread tcache。
4. 这解释了为什么 iOS UI 流畅不受 libmalloc 慢影响：UI 线程是单线程的（1 thread = 11.2M ops/s），88ns/op 的开销在 16ms 帧预算中仅占 0.0006%。多线程扩展性在 UI 场景下无关——UI 不需要多线程 malloc。
5. scudo 6 线程时增量最小（+0.6%）：scudo 的 size-class per-CPU 设计在 6 线程时竞争略有增加。但差异极小（0.6% vs 1.7%），可忽略。

1.4b 分配大小敏感性：32B → 4KB → 1MB

分配大小如何影响延迟？测试 3 种大小（32B = 小对象 / 4KB = 页大小 / 1MB = 大对象）的 malloc+free pair 延迟：

1. 32B→4KB 几乎无差异（所有分配器 <5% 变化）——小对象到页大小都在 fast path（tcache/magazine/size-class），延迟由锁/无锁决定而非大小。
2. 4KB→1MB 延迟暴涨 15-130×——大对象超过 magazine/tcache 阈值，走 mmap 路径（libmalloc: large rack, jemalloc: huge, scudo: secondary）。大对象延迟 ≈ page fault 延迟（~3000ns for 1MB）。
3. scudo 1MB 最慢（8146ns = 133× 32B）——scudo secondary allocator 对每个大块维护完整 chunk header（checksum + tag + size），比 jemalloc/mimalloc 的 huge path 开销大 20×。
4. libmalloc 1MB 慢但可控（2228ns）——large rack 是 XNU 直接 mmap，延迟 ≈ 1 次 page fault（16K 页）+ 一些元数据。这正好对应 §5 的 ~3000ns/fault 实测。
5. 设计启示：App 应避免高频大块分配。1MB malloc = ~100× 32B malloc = ~3× page fault。对象池化对大对象比对小对象重要得多——iOS UIKit 的 cell 复用、image cache 正是为此设计。

1.4c 延迟分布分析：p50/p90/p99/p99.9（10 万次采样）

前面的数据都是批量均值（总时间÷操作数）。但延迟分布的尾部（p99/p99.9）对 UI 流畅性更重要——一个 p99 卡顿就可能导致掉帧。本节用 10 万次单次 malloc+free 采样，测量完整延迟分布：

1. libmalloc p50-p99.9 完全一致（42ns）——延迟分布极窄，说明杂志快路径非常稳定，每次 malloc/free 走的代码路径完全相同（无分支差异）。p99/p50 = 1.02× 是所有后端中最稳定的。
2. jemalloc 4KB 有可见尾部（p99=125ns，是 p50 的 3×）：4KB 分配偶尔超出 tcache bin 容量 → 触发 tcache miss → 走 arena 分配路径（更慢）。这是 jemalloc per-thread tcache 的固有特性——size class 越大，tcache bin 中的 slot 数越少，miss 概率越高。
3. 32B 无尾部：jemalloc 的 32B tcache bin 有足够 slot（通常 200+），10 万次采样中 p99.9 也命中 tcache → 无尾部。libmalloc 的 tiny magazine 同理。
4. max 延迟 19-34μs：这些是上下文切换/中断导致的（CPU 被 OS 调度器抢占），不是分配器本身的延迟。在 100K 采样中约 0.001% 的操作被打断——这解释了为什么 iOS UI 线程用最高优先级：减少抢占 = 减少这种尾部。
5. 设计启示：iOS 用 libmalloc 的 per-CPU 杂志（而非 per-thread tcache）的一个优势是尾部可控——杂志在多个 CPU 间共享，没有"某个 thread 的 tcache 用尽"的问题。p99/p50 = 1.02× vs jemalloc 4KB 的 2.98×——稳定胜过快。

1.5 libmalloc vs scudo 安全性源码级对比

两者都有安全加固，但加固的对象和层次完全不同。

libmalloc 的安全模型：保护元数据 + 信任平台沙箱

libmalloc 的加固哲学："保护 free list 不被腐败，其余交给平台沙箱"。

① free list 指针校验和——两条路径（magazine_inline.h:190-253）：

• arm64e（A12+，含 A14）路径：用 ARMv8.3 PAC（Pointer Authentication Code）对 free list 指针做硬件签名——ptrauth_sign_unauthenticated(ptr, ptrauth_key_process_dependent_data, ...)。签名密钥是 process-dependent 的（每进程不同），攻击者无法伪造。解签失败直接 __builtin_trap()。对"篡改 free list 指针"这个具体威胁，比 scudo 的 CRC32 更强——PAC 是密码学签名，CRC32 可碰撞。
• 非 arm64e 路径：free_list_gen_checksum 做 3 轮折叠（64→32→16→8 bit）只留 4 bit，碰撞概率 1/16 = 6.25%——非常弱。

② 没有 UAF 检测：free → 直接链入 free list → 立即可复用。没有 quarantine、没有 State 追踪。UAF 在复用窗口内被静默吞掉。

③ 没有 double-free 检测：第二次 free 只是把指针再链入（如果 checksum 过了）。没有 State 字段说"这个块已经是 Available 了"。

scudo 的安全模型：每块全生命周期追踪

scudo 的加固哲学："每个 chunk 从分配到释放到回收都有 header 追踪 + CRC32 校验 + quarantine 延迟"。

① 每 chunk header 有 State + CRC32（chunk.h:62-73）：8 字节 header 含 ClassId(8bit)/State(2bit)/Origin(2bit)/Size(20bit)/Offset(16bit)/Checksum(16bit)。每次操作都校验——loadHeader 重算 checksum 对比，不符即 reportHeaderCorruption。16-bit CRC32 碰撞 1/65536。

② quarantine——UAF 检测的核心（combined.h:1128-1141）：free 不直接回收，State 从 Allocated→Quarantined。进 QuarantineCache 延迟释放。quarantine 窗口内 UAF 访问 → 下次 drain 回收时 header 被腐败 → checksum 不匹配 → 报错。这是 libmalloc 完全没有的机制。

③ MTE——100% 硬件级 UAF 检测（memtag.h:30，combined.h:1158）：在 MTE 硬件上，free 时 setRandomTag 换标签。UAF 用旧 tag 访问 → CPU tag check 硬件 trap（SIGSEGV），100% 检测率。libmalloc 不支持 MTE（A14 未实现 MTE）。

④ GWP-ASan——概率性保护页采样（combined.h:29-33）：编译时开 GWP_ASAN_HOOKS，抽样分配放 guard page 区域，overflow/underflow 直接 SIGSEGV 并附栈追踪。libmalloc 没有；WebKit 有独立的 bmalloc 做类似的事。

1.6 为什么 iOS 不用 scudo 替代 libmalloc

scudo 确实比 libmalloc 快（60 vs 88 ns），安全机制也更全。但"快+安全"不是 iOS 不换 scudo 的原因——libmalloc 有 4 件 scudo 架构层面做不到的事，其中第 1 件是 iOS 流畅性的命根。

① jetsam 协同链（命根——scudo 完全没有）

这是 iOS App 后台能保命的核心。libmalloc 把"何时还内存"的决策权下放给内核，scudo 架构里没有这个通道：

关键反证：把 libmalloc 换成 scudo → App 后台时 scudo 不响应 jetsam 压力信号 → jetsam 看到占着 RAM 不还 → 直接杀进程。这是 iOS 不能接受的结果——流畅性的第一支柱"进程还在"就塌了。

② arm64e PAC 比 scudo CRC32 更强（对 free list 篡改这个具体威胁）

scudo 的 16-bit CRC 可碰撞；libmalloc arm64e 用 ptrauth_sign 硬件密码学签名。对 free list 篡改这一个威胁，iOS 已有比 scudo 更强的方案。scudo 多出的 quarantine/MTE/GWP-ASan 防的是 UAF/overflow——这些在 iOS 上由代码签名 + 沙箱 + WebKit bmalloc 在平台层消化了。

③ per-CPU 杂志——固定核数硬件的最优 cache 局部性

Apple 既造 SoC（A14=6 核）又出 OS，已知固定核数。per-CPU 杂志的锁 cache line 永远只被同一核碰——不跨核弹跳。scudo 的 per-thread TSD（pthread_key_create）每次访问多一层 pthread_getspecific，线程多时 tcache 膨胀。

④ 25 年深度集成

libmalloc 是 Bertrand Serlet 1999 年设计（magazine_malloc.c:26），25 年来与 XNU/CoreFoundation/Foundation/UIKit 深度耦合：malloc_zone_t 注册机制、scalable_zone_info_task 跨任务安全读（诊断/Instruments 基础）、malloc_memory_event_handler 注册在 dispatch 源上（事件总线）。scudo 没有这些 Darwin 集成。

↑ 以上四节的实测数据揭示了一个共同模式：每个分配器都在不同维度上做权衡——速度、内存、安全、平台协同——没有"全能最优解"。下一节从源码层面解释这些数据差异的根因。

2. 源码级对比：libmalloc vs jemalloc

2.1 快路径定位：per-CPU vs per-thread（核心差异）

libmalloc：杂志按当前 CPU 选，不是按线程。libmalloc/magazine_rack.c:228：

unsigned int rack_get_thread_index(rack_t *rack) {
    index = _malloc_cpu_number();        // 当前 CPU 号，不是线程号
}
// magazine_tiny.c:2399  tiny_malloc_should_clear
mag_index = rack_get_thread_index(rack) % rack->num_magazines;

杂志数 = 核数：num_magazines = mag_max_magazines()（magazine_malloc.c:1699，注释"per-CPU magazines that scale way better"）。

jemalloc：tcache 按线程绑，经 tsd（thread-specific data）。

Apple 为何选 per-CPU：① 核数已知且小（A14=6），杂志数恒定省内存（线程多时 jemalloc tcache 膨胀）；② 杂志锁的 cache line 永远只被同一核拿→不跨核弹跳（锁真正开销在跨核 cache line 迁移，per-CPU 避开了）；③ 杂志元数据硬件 cache 局部性钉在核上；④ 同核争用在 iOS cooperative 调度下低频。

2.2 快路径是否持锁：持锁 vs 无锁（~88ns vs ~21ns 根因）

libmalloc：快路径仍持 magazine 锁，即使命中单槽 cache：magazine_tiny.c:2409

SZONE_MAGAZINE_PTR_LOCK(tiny_mag_ptr);        // ← 加锁
ptr = tiny_mag_ptr->mag_last_free;           // 唯一一个 cache 槽
if (mag_last_free_msize == msize) {
    SZONE_MAGAZINE_PTR_UNLOCK(tiny_mag_ptr); // 命中也锁了
    return ptr;
}

jemalloc：无锁无原子，走线程私有栈：cache_bin.h:348

void *ret = *bin->stack_head;     // 线程私有栈，无 lock/atomic
if (likely(low_bits != bin->low_bits_low_water)) {
    bin->stack_head = new_head;
    *success = true; return ret;
}

libmalloc 的快 cache 仅 mag_last_free 单槽；jemalloc 是深栈（每 size-class 几百个）。libmalloc 每操作还付 free 的校验和（free_list_checksum_ptr，抗堆攻击）。→ 估算 88ns 里大头是：锁开销(~30-40ns)+校验和(~10-15ns)+链表慢路径(~15-20ns)。注：此拆解为源码推算，非 dtrace 实测（iOS 无 dtrace，MallocScribble 等检查开关会改变行为路径无法隔离单一因素）。

2.3 回收策略：pressure 驱动 vs decay 定时

libmalloc：region 进 depot 后才逐页 MADV_FREE_REUSABLE（magazine_tiny.c:839，pinned_to_depot 保证锁外 madvise 安全）。回收是 pressure/recirc 驱动；大块走 MADV_REUSABLE death-row cache。

jemalloc：decay_dirty/decay_muzzy（默认 10s，jemalloc/src/pac.c:78）→ purge：MADV_FREE(→muzzy)/MADV_DONTNEED(decommit)。定时、可调、可确定。

→ 解释实测 retained：libmalloc 17MB（pressure 下 depot madvise 起作用）、jemalloc 默认 81MB（10s decay 没触发）、jemalloc0 6MB（decay=0 立即 decommit）。

3. libmalloc 设计思想与 jetsam 协同链

3.1 设计思想

源码文件头注释（magazine_malloc.c:26）：Author Bertrand Serlet, August 1999; 2008 多线程增强"in the spirit of Hoard"（Emery Berger ASPLOS 2000 的 per-processor heap）。libmalloc 是 Hoard 在 Apple 硬件上的特化，四个核心思想：

1. per-CPU 杂志而非 per-thread：Apple 既造 SoC 又出 OS，已知固定核数。在固定小核数硬件上缓存局部性最优、无 false sharing，无需为任意线程数动态建/毁 tcache。
2. RAM 是瓶颈而非 CPU：4-6GB 手机上 retained → 被 jetsam 杀 → App 死。回收与内核压力信号耦合（reactive），而非 jemalloc 定时 decay（"eventually 还"在突发压力下来不及）。把"何时还内存"决策权交给内核——它知道全局压力。
3. 安全优先：手机跑不可信 Web 内容（WebKit），堆加固比纳秒更重要 → 校验和指针 + guard page。
4. 原生集成：用 Darwin 独有的 VM-tag / MADV_FREE_REUSABLE / vm_purgable_control——这是 mmap-only 的 jemalloc/mimalloc 拿不到的协同通道。

3.2 jetsam 协同链（双层：主动提示 + 被动释放）

A. 主动提示层（常开——让内核优先回收 libmalloc 的页，而非杀进程）

1. VM tag：每次 mach_vm_allocate(... VM_MAKE_TAG(VM_MEMORY_MALLOC_TINY))（libmalloc/vm.c:89）。jetsam 杀选启发式按 per-task VM tag 找大消耗者。
2. MADV_FREE_REUSABLE（CONFIG_MADVISE_STYLE）：depot 中 free span 走 MADV_FREE_REUSABLE（vm.c:463，注释 :467 确认）。Darwin 语义：标记页可复用 → 内核压力下优先回收这些页，先于杀进程。libmalloc 的"已释放但缓存"页是全系统最便宜的 RAM 回收源。
3. Large death-row（large_entry_cache）：大块 free → LIFO 进缓存 + MADV_REUSABLE；内核可回收，下次大块 alloc 直接复用。
4. Purgeable（vm_purgable_control(VM_PURGABLE_SET_STATE)）：可清除分配 → 内核单方面清空。

B. 被动释放层（收到压力信号即 flush）——完整调用链

内核 kern_memorystatus(jetsam) 监控压力，越阈值
   → 投递 NOTE_MEMORYSTATUS kqueue 事件(带 NORMAL/WARN/CRITICAL 级别)
   → 用户态 dispatch source DISPATCH_SOURCE_TYPE_MEMORYSTATUS 触发
   → libmalloc: malloc_memory_event_handler(event)            [malloc.c:3139]
       event & MALLOC_MEMORYSTATUS_MASK_PRESSURE_RELIEF
       → malloc_zone_pressure_relief(0, 0)                    [malloc.c:3142]
           → 每个 zone->pressure_relief(zone, 0)              [malloc.c:3181]
               → 杂志区: szone_pressure_relief                  [magazine_malloc.c:1425]
                   ① tiny/small/medium_madvise_pressure_relief [magazine_tiny.c:976]
                      遍历每 per-CPU 杂志每 region，RACK_DISPOSE_DELAY
                      → 迁 depot → 对每个 free span MADV_FREE_REUSABLE
                   ② Large death-row: 锁外拷出后逐个 mvm_deallocate_pages(全 munmap)
                      置 flotsam_enabled=FALSE 使压力期新大块 free 不再回缓存

净效果：jetsam 发压力信号后毫秒级内，libmalloc 把所有 free/cached 页归还内核 → jetsam 的回收轮拿走 RAM 而无需杀进程。

C. 可观测层（供 jetsam/diagnostics 安全读他任务 zone）

scalable_zone_info_task(task, memory_reader_t reader, ...)（magazine_malloc.c:954）：跨任务（用 memory_reader_t）安全读 malloc zone 统计。

D. 实测验证：MADV_FREE_REUSABLE 的延迟优势

理论分析了 jetsam 协同链，但 MADV_FREE_REUSABLE 真的有延迟优势吗？实测验证：分配 512MB → 写入全部页（minor fault）→ madvise(MADV_FREE_REUSABLE) → sleep 1s → 重新访问全部页，对比两种路径：

1. 为什么更快：fresh minor fault = 分配物理页 + 清零 16K + 建 PTE。REUSABLE reactivation = 页已在 RAM（数据保留），只需取消 volatile 标记 + 恢复写权限——无需分配、无需清零。省下的 ~900ns 是清零 16K 的开销。
2. 对比 MADV_DONTNEED：实测 MADV_DONTNEED reaccess = 1895ns，与 REUSABLE 相近——说明 iOS 对两者在"无压力"时处理一致（都保留数据在 RAM）。
3. 对比 5GB 压力下的 reactivation：§5.3c 中 5GB 压力测试的 reactivation = ~11000ns（从 compressor 解压）。REUSABLE 在无压力时 = 1960ns——5.6× 更快。这就是 libmalloc 优先用 MADV_FREE_REUSABLE 而非压缩的原因：在无压力时，数据保留在 RAM 且 reactivation 几乎免费；只有真正压力来时才进 compressor。
4. 设计哲学：libmalloc 的 MADV_FREE_REUSABLE 是零成本缓存——free 了但数据还在，内核有压力时优先回收（比杀进程便宜），无压力时 reactivation 几乎免费（比 minor fault 快 31%）。这是 iOS "慢但流畅" 的微观机制之一。

4. 为什么 libmalloc 慢但 iOS 流畅

bench 证 libmalloc 慢 4-6×，但手里的 iPhone 依然丝滑。因为分配器快路径延迟根本不是流畅性的瓶颈——流畅性是一个系统级指标，由完全不同的因素决定。

4.1 绝对量级：不是瓶颈

libmalloc 一次 32B malloc+free = ~88ns。一个 App 每帧（16.6ms@60Hz）做 10 万次 alloc/free（已是很重的逻辑）：100,000 × 88ns = 8.8ms < 16.6ms，不掉帧。jemalloc 同负载省下的 6.7ms 在 16.6ms 帧预算里省不出肉眼可感区别。

4.2 流畅性真正依赖的 5 件事，libmalloc 全做对了

1. 内存不膨胀 → 不被 jetsam 杀（最关键）：libmalloc retained 低（17MB）+ jetsam 协同，App 后台能保命、前台不重启。jemalloc 默认（81MB）同压力下更早被杀 → 切回前台冷启动 → 真正可感的卡顿。流畅的前提是"进程还在"。
2. UI 在独立高优先级线程，不与 App 逻辑争 malloc：iOS 渲染是 Core Animation + Render Server（独立进程 backboardd），App 只提交 layer 树。App malloc 慢只影响逻辑线程，Render Server 不用 App 的 malloc → 渲染帧率不受影响。
3. UIKit 用对象池/缓存，规避了快路径：UICollectionView/TableView 的 cell 复用、UIImage 缓存——高频 UI 对象根本不走 malloc/free 循环，一次 dequeue 是查表不是分配。
4. ARC + autorelease pool 的释放是批量的：ARC 释放延迟批量（autoreleasepool drain 一次性 free），不是紧耦合 alloc/free pair。libmalloc 的单槽 cache 在批量复用时命中率高。bench 的 pair_32b 是最不利于 libmalloc 命中率的模式——真实 App 没这么用。
5. A14 算力冗余 + 大核突发：Firestorm 大核 ~3GHz，88ns ≈ 260 周期，微秒级抖动被算力冗余吃掉。UI 线程最高优先级 + 大核绑定。

4.3 对照：Android 用 jemalloc 但仍卡？

Android Bionic 用 jemalloc（后换 Scudo），分配器更快。但 Android 卡顿来源是：后台进程多→RAM 竞争→LMK 频繁杀→切回冷启动；ART GC 停顿；RenderThread 与 App 共进程争用。Android 选择了快的分配器，输在了"内存/进程保命"。这反向印证：分配器快慢不是关键，内存策略协同才是。libmalloc 慢但协同好，iOS 反而更流畅。

4.4 实测：jetsam 杀进程级联（mproc 压力测试）

"App 不被杀"是流畅性第一支柱——但 jetsam 真的会杀吗？本节用 mproc 压力测试实测：启动 N 个进程同时分配内存，观察 jetsam 的杀进程行为。两组实验：8 进程快杀（压缩→全杀）和16 进程渐进杀（先杀 2→再杀余）。

↑ 上面实测了 jetsam 的杀进程级联。但如果分配器快慢是二阶项，那一阶项——内存管理的底层延迟——是多少？下一节直接测量 page fault 延迟，这是内存管理的最底层操作。

5. Page Fault 延迟实测

5.1 测试方法

原始需求的第一部分：验证此设备的 pagefault 性能。测试通过 mmap 匿名映射后首次写入触发 minor fault（zero-fill on demand），测量不同大小（4MB→256MB）和访问模式（顺序 vs 随机）下的 per-fault 延迟。每轮重复 5 次取均值。设备页大小 16384（16K 页）。

核心测试代码（memperf.c:run_pf）

// 1. mmap 匿名映射（不分配物理页，仅建 VM 映射）
void *base = mmap(NULL, bytes, PROT_READ | PROT_WRITE,
                  MAP_ANON | MAP_PRIVATE, -1, 0);

// 2. 顺序/随机访问顺序
for (long i = 0; i < pages; i++) order[i] = i;
if (strcmp(pattern, "rand") == 0) {
    // Fisher-Yates 洗牌 → 随机访问
    for (long i = pages - 1; i > 0; i--) {
        long j = rand() % (int)(i + 1);
        long t = order[i]; order[i] = order[j]; order[j] = t;
    }
}

// 3. 写入每页首字节 → 触发 minor fault（零填充）
getrusage(RUSAGE_SELF, &ru0);       // fault 前计数
double t0 = now_us();
for (long i = 0; i < pages; i++) {
    char *addr = p + (size_t)order[i] * (size_t)psize;
    *addr = (char)(i & 0xff);              // ← minor fault 在这里触发
}
double t1 = now_us();
getrusage(RUSAGE_SELF, &ru1);       // fault 后计数

// 4. 交叉验证：实际 minor fault 次数 = ru_minflt 差值
minflts[rep] = ru1.ru_minflt - ru0.ru_minflt;
// 实测：minflt_delta == pages → 每个 page 确实触发一次 fault

5.2 实测结果

5.3 分析

1. ~3000 ns/fault 是内核 zero-fill + 物理页分配的固定开销：每次 minor fault 内核要 ①找空闲物理页（buddy allocator）②清零 16K 页 ③建立 PTE。这 ~3000ns 不随大小变化，因为每页是独立处理的。
2. 顺序 vs 随机差异极小（3185 vs 3039，差异 <5%）：minor fault 不涉及磁盘 I/O（不像 major fault），所以没有"随机→磁头寻道"的惩罚。TLB miss 在 16K 页下页表项少（256MB / 16K = 16384 项 = L2 TLB 容量边缘），差异被内核处理时间淹没。
3. 16K 页 vs 传统 4K 页：每页清零 16K 而非 4K，但 fault 次数少 4×。净效果：每 MB 的 fault 开销 = (1/4) × 单页开销，这是大页对 mmap 场景的优势——减少 fault 次数即减少 ~3000ns 的固定开销。
4. 与分配器速度的关系：jemalloc malloc 21ns vs minor fault 3000ns——一个 fault = ~143 次 malloc。这就是为什么分配器要 cache：避免每次分配都 mmap（每次 mmap 首写 = 3000ns/fault）。jemalloc tcache 命中 = 21ns，比 mmap+fault 快 143×。
5. 与 jetsam 的关系：当内存压力来了，内核 MADV_FREE_REUSABLE 回收页 → App 下次访问触发 reactivation fault（比 zero-fill 略贵，因为要先检查页是否被回收）。translation_faults sysctl = 36,354,089（设备累计）——这就是真实工作负载下 fault 的规模。

5.2b TLB 访问模式敏感性：Stride 测试

16K 页减少了 page table 项数，但 TLB 容量仍是有限的。测试 stride 1/2/4/8/16（每隔 N 页访问一个）下的非 fault 访问延迟（页面已 fault-in，纯 TLB/cache 效应）：

1. stride 1 在 ≥16MB 时延迟暴涨 25-40×（11.9→266→313→477ns）：连续访问每页时 TLB 频繁 miss（16K 页 × 1024 页 = 16MB 就超过 L1 TLB 容量），page table walk 开销主导。
2. stride 2 立即降到 ~12ns：每隔一页访问一次 → 访问的页数减半 → TLB 压力减半 → 大部分访问 TLB 命中。从 313ns 降到 12ns = 26× 加速。
3. stride 4+ 降到 ~10ns（L1/L2 cache 命中）：访问间隔足够大 → 每次访问的页都在 TLB 中 → 延迟由 cache 而非 TLB 决定。
4. 4MB 不受影响（11.9ns at stride 1）：4MB = 256 页 × 16K = L2 TLB 可容纳，无 miss。
5. 实践意义：16K 页比 4K 页减少了 4× 的 page table 项数，但 TLB 容量有限（A14 L2 TLB ~1024 项）。当工作集 > 16MB 时 TLB 仍会 miss。16K 页不是万能药——它减少了 fault 次数但没消除 TLB miss。stride 2 就能获得 25× 加速说明 TLB miss 是主要瓶颈。

5.3a COW（Copy-on-Write）Fault 延迟实测

补测 COW fault：fork() 后子进程写入共享页，触发内核复制物理页。测试方法：父进程 mmap + 首写触发 minor fault → fork() → 子进程写入每页 → 计时。对比 minor fault 的 ~3000ns。

1. Minor fault（~3000ns）= 找空闲页 + 清零 16K + 建 PTE
2. COW fault（~5000ns）= 检测写保护 + 复制 16K 旧页到新页 + 更新两个 PTE + 恢复写权限
3. 多出的 ~2000ns 主要是页面复制（16K memcpy ~1-2μs at 3GHz）+ 额外的 PTE 操作。清零和复制的内存带宽开销相近，但 COW 多了"检测 + 两个 PTE 更新"。
4. 256MB 时 COW 反而更快（4434 vs 小块 5592ns）：大块时 TLB 预热后 page table walk 更快，且大块连续写入触发 prefetcher。小块每次 fault 间有 TLB miss 开销。
5. 与 jetsam 的关系：iOS 的 MADV_FREE_REUSABLE 回收页后，App 访问触发 reactivation fault（类似 COW——需要恢复页面内容）。reactivation 延迟 ~5000ns 级别，比 minor fault 贵 ~1.7×——但远比 major fault（磁盘 swap）快 1000×。这就是 jetsam"先压缩/回收→再 kill"策略的延迟优势：reactivation 卡 ~5μs，而杀进程+冷启动卡数秒。

5.3b Guard Page Fault（PROT_NONE → SIGSEGV）延迟实测

补测 guard page fault：mmap 以 PROT_NONE 映射一个页 → 写入触发 SIGSEGV → sigsetjmp/siglongjmp 恢复 → 计时。这测量的是信号传递延迟（内核 trap → 信号投递 → 用户态恢复），不包括磁盘 I/O。

1. 完整路径：用户态写入 → MMU 检测权限违规 → 内核 trap（exception handler）→ 生成 SIGSEGV → 查找信号处理函数 → sigaction 调度 → 用户态信号处理函数执行 → siglongjmp 恢复
2. 比 minor fault 贵 ~570ns（3570 vs 3000）：多出的是信号投递链（trap → 找信号 handler → mask 操作 → 用户态返回），而 minor fault 只走内核 fault handler → 分配清零 → 建 PTE → 返回（无信号路径）
3. 比 COW fault 便宜 ~1430ns（3570 vs 5000）：guard page fault 不需要页面复制（16K memcpy）和双 PTE 更新——它只是 trap + 信号传递 + 恢复，没有页面操作
4. 稳定性极高：100→50000 轮，3356→3574ns，CV < 0.5%——信号路径是固定开销，不随数据量变化
5. 实践意义：iOS 用 guard page 实现 stack overflow detection（栈底 PROT_NONE 页）和 objc_destructivelyRealloc 的 use-after-free 检测。每次栈溢出检测的延迟代价 ~3.5μs——对调试版（MallocStackLogging）可接受，对 Release 版通过编译器静态分析替代。

5.3c 重磅发现：iOS 有加密 Swap — 5GB 压力测试完整画像

5GB 压力测试：分配 5GB 匿名内存 → 写入全部页面（触发 minor fault 填满 RAM）→ sleep 3s（让内核回收）→ 重新访问全部页面并逐页计时。采样 5041 页：

1. 三级内存层次实测确认：RAM（6GB，p50=2.9μs）→ Compressor（WKdm，p90=11μs）→ Encrypted Swap（flash，max=3.9ms）。每一层延迟差一个数量级。
2. 43.9% 的页面被压缩回收（5-20μs 区间）——5GB 分配远超 6GB 物理内存（系统占用~2GB），大量页面被 compressor 回收。重新访问时触发 reactivation fault（~11μs），比 minor fault 贵 3.7×，但比 swap-in 便宜 100×。
3. 仅 0.5% 触发 major fault（25 页 / 5041）——compressor 撑住了 99.5% 的回收压力，swap 是最后手段。max=3.9ms = flash 存储 I/O 延迟（含解密）。
4. Swapins 极少（192 次累计）——说明被 swap out 的页几乎不再被访问。jetsam 在进程触发 swap-in 之前就杀掉了它。→ iOS 的策略不是"swap 换入换出"，而是"swap 作为换出缓冲 + jetsam 杀进程避免换入"。
5. 这解释了 iOS 流畅性的根基：reactivation（~11μs）对 UI 不可感知（16ms 帧预算），major fault（~4ms）也不致命。但连续 major fault 会卡帧——jetsam 杀进程是为了避免连续 swap-in。内存压力下先杀后台进程保前台，正是为了避免前台 App 触发 major fault。

5.3d 深挖：Compressor 子系统与 Freezer 的完整内核计数

通过 sysctl -a 提取的内核内存管理计数器，揭示 iOS 内存管理的完整子系统：

Freezer 子系统：后台进程冻结（不是 kill，是 freeze）

Compressor Swapper：压缩段在 RAM ↔ flash 之间移动

zlib 压缩级别对比（补充数据）

6. 内核 WKdm 多线程解压

6.1 源码结论：解压多 CPU 并发，压缩单线程

6.2 实测（A14 / 6 核，每线程独立 dst+scratch 模拟 per-CPU）

TYPICAL 6 核聚合解压 ~8000 MiB/s ≈ 4× 单核——内核真实聚合解压能力。未达理想 6× 因内存带宽/缓存争用。压缩为单线程，~1600 MiB/s 即设备上限，故 bench 单线程压缩有代表性；解压单线程低估内核（已补 6 核并发测）。

6.3 用户态压缩算法横向对比：为什么内核选 WKdm 而非 LZ4

iOS 内核用 WKdm，Android zram 用 LZ4/LZO。哪个更好？本节实测 5 种算法在相同数据模式下的压缩/解压吞吐量，回答"内核为什么选 WKdm"。

1. LZ4 解压比 WKdm 快 8×（LZ4 mixed 15989 vs WKdm TYPICAL 1978 MiB/s）——如果只看解压速度，LZ4 完胜。
2. 但 LZ4 压缩 mixed 只有 805 MiB/s，WKdm 压缩 TYPICAL 有 1594 MiB/s——压缩端 WKdm 快 2×。内核是压缩（回收）→ 延迟解压（reactivation），压缩端速度更重要（回收发生在后台，解压发生在前台 → 解压延迟直接卡 UI）。
3. WKdm 的真正优势是"固定复杂度"：字典编码的每页处理时间是可预测的（~0.52ms/页），而 LZ4 对 mixed 数据的解压延迟波动大（0.067ms~3.96ms 跨 59×）。内核需要可预测的回收延迟——不能让某个页压缩花 10ms 卡住压缩线程。WKdm 的字典大小固定（~4KB），LZ4 的 hash table 随数据内容变化。
4. LZMA 是反面教材：mixed 压缩 3.5 MiB/s（比 WKdm 慢 455×）、解压 19 MiB/s（比 LZ4 慢 841×）。虽然压缩比略好（0.508 vs 0.507），但延迟完全不可接受——53.9ms 解压一个 1MB 块，会直接卡帧。→ 实时系统不用 LZMA。
5. LZFSE 定位特殊：压缩很慢（88 MiB/s），但解压不错（594 MiB/s mixed）。Apple 用它做用户态文件压缩（如 app 瘦身），不用在内核——因为压缩太慢不适合回收路径。
6. Android 用 LZ4 做 zram 的逻辑：zram 是用户可配置的，追求"解压极快 + 压缩够用"，LZ4 解压 ~16000 MiB/s mixed 足以保证 reactivation 不卡。但 Android 的 zram 是单线程的，没有 iOS 的"6 核并发解压"——iOS 用 WKdm 的低并发放大（4×）弥补单线程劣势。

↑ 内核选 WKdm 是"可预测 + 压缩快 + 6 核并发放大"的综合权衡。下一节对比鸿蒙 NEXT 如何用不同的方案（memcg + zswapd）实现同样的"reclaim→compress→kill"分层。

7. 鸿蒙 NEXT 对比：统一渲染 + memcg/zswapd

7.1 统一渲染：渲染耦合从"iOS 略优"改为"持平"

统一渲染把"栅格化"从 App 进程搬到 RS 进程——结构上向 iOS 的 backboardd 靠拢。App UI 线程卡顿不再直接卡栅格化，和 iOS"App 卡了当帧仍能渲染"同一机理。渲染耦合维度：撤销原"iOS 略优"，改判持平。

7.2 内存保命：从"iOS 胜（鸿蒙靠 LMK 粗放杀）"改为"结构持平"

核实 OpenHarmony kernel v6.1 的 mm/ 目录，发现一整套 Huawei 自研、非 mainline 的内存子系统：

关键发现：① drivers/staging/android/lowmemorykiller.c 在该分支不存在——OH 不带传统 in-kernel LMK；② memcg_reclaim.c 头注释 (c) 2020-2022 Huawei，引用 hyperhold_inf.h——OH 有个叫 HyperHold 的内存子系统；③ zswapd 的 ub_zram2ufs_ratio/ub_ufs2zram_ratio 是分层压缩交换：冷页先压到 zram（压缩 RAM，快）→ 不够再换到 UFS（闪存），与 iOS"vm_compressor 压 RAM → 极端压力 swap 到闪存"是同一分层策略。

7.3 剩余真实差距（精细化）

鸿蒙 = "Linux memcg 的细粒度 cgroup 定向回收 + iOS 式系统级压缩"的混合。iOS 干脆没用 cgroup，走 per-task+全局压缩+优先级带这条更简的路。三者 reclaim→compress→kill 都到位，但分工哲学不同：Linux 重在"组内精细定向"，iOS 重在"全局压缩最冷+按 App 重要性杀+分配器主动还"，鸿蒙两者都要。

鸿蒙若卡，卡在哪（修正版）：① GC 停顿（ArkTS，头号嫌疑，iOS 无）；② 声明式 diff+复杂 list（AOT 缓解但结构性在）；③ 中低端芯片算力不足放大以上。不再大概率卡在"被杀冷启动"（鸿蒙已有分层回收）。若鸿蒙想追平 iOS 流畅性下限，该补的不是分配器（二阶项），而是继续把 ArkTS GC 往接近无感调。

8. iOS 的 memcg 对等物：per-task ledger + phys_footprint

iOS 没有 memcg（cgroups 子系统），但有完整功能对等物，且架构与 Linux memcg 在关键点上不同。XNU kern_memorystatus.c（5355 行）源码级核实：

8.1 iOS 的"memcg 对等物"组件

7.2 与 Linux memcg 的 5 点架构差异

① 记账指标：phys_footprint vs RSS+swap（iOS 更聪明）

Linux memcg 记账 RSS+swap+cache，可压缩的匿名页按原大小全额计入。iOS phys_footprint 把页拆成 internal_pages（未压缩）+ internal_compressed_pages（已压缩）分别记——压缩后 footprint 变小，App 看起来更省。iOS 的记账天然激励"压缩回收"：压缩后 footprint 降、不触限；Linux memcg 除非开 zswap 记账否则激励不同。

② 分组单元：per-task vs cgroup

Linux memcg = 任意 cgroup 树，可多进程归一组共享预算、可嵌套、父子传播（灵活但 page_cgroup 每页挂钩开销大）。iOS = per-task（进程），Darwin 每任务天生有独立 vm_map，页天然归一 task，无需挂钩，再加优先级带归类。无"多进程共享预算"原生抽象，粒度粗但简单、零挂钩开销。

③ 限制：active/inactive 双限 vs 单 limit（iOS 为移动端调优）

Linux memcg：一个 memory.limit_in_bytes，超限触发回收。iOS：per-task 有 memlimit_active（前台）+ memlimit_inactive（后台）两套限（:973），加 FATAL/NONFATAL 标志（fatal=超限杀，nonfatal=只回收不杀）。前台 App 给大限、后台小限、自动切换——移动端专用调优，Linux 要靠 cgroup 切换+多 limit 模拟。

④ 回收：系统级压缩 vs per-cgroup LRU（最根本架构差）

Linux memcg 回收是 per-cgroup 定向——try_to_free_mem_cgroup_pages() 回收这个 cgroup 的 LRU。iOS 回收是 系统级压缩 + per-task 压力事件双轨：内核 vm_compressor 压缩全系统最冷页（不挑哪个 task，挑最冷），同时给被压 task 发 memorystatus 压力事件 → 该 task 的 libmalloc malloc_memory_event_handler 跑 pressure_relief → 主动 MADV_FREE_REUSABLE 自己的可回收页。iOS 把回收责任部分下放给分配器（libmalloc 主动提示），Linux memcg 模型里分配器只被动被回收——这是 iOS 一个真实但较小的精细度优势。

⑤ 杀：全局按优先级带 vs per-cgroup OOM

Linux memcg：cgroup 超 fatal 限 → 该 cgroup 内 OOM killer 杀一个。iOS：系统压力到阈值 → jetsam 按全系统优先级带从低到高杀（IDLE → AGING_BAND → ... → 前台最后），max_kill_priority（:909）控制杀到哪一带为止。iOS 杀是全局 App 优先级驱动（前台几乎不可能被杀，后台 IDLE 先死），Linux 是组内 OOM，与 App 重要性无关。

9. 背景：Darwin 与 XNU 内核是什么

本文反复提到"Darwin""XNU""Mach""BSD"——这里统一解释。

Darwin 是 Apple 所有操作系统（macOS / iOS / iPadOS / watchOS / tvOS / visionOS）的开源内核 + 核心用户态。它是盖在 GUI 之下的那一层操作系统底座：

┌─────────────────────────────────────┐
│  UIKit / SpringBoard (iOS 的触控 UI) │  ← iOS 专属层
│  AppKit / Aqua   (Mac 的桌面 UI)     │  ← macOS 专属层
├─────────────────────────────────────┤
│  Darwin   ← 就是这一层               │
│  ├─ XNU 内核 (Mach + BSD + IOKit)    │
│  ├─ libSystem (libc / libmalloc…)    │
│  └─ launchd / 核心守护进程            │
├─────────────────────────────────────┤
│  硬件 (A14 / M1 / M2 …)              │
└─────────────────────────────────────┘

• macOS = Darwin + AppKit/Aqua（桌面 UI + Mac 框架）
• iOS = Darwin + UIKit/SpringBoard（触控 UI + 移动框架）
• watchOS / tvOS = Darwin + 各自 UI 层

Darwin 是共同的根。iPhone 和 Mac 跑的是同一个内核家族，只是上层 UI 不同——这就是为什么越狱 iPhone 能跑很多 Mac 的命令行工具（uname、sysctl、mach_vm_allocate 都是同一套）。本文测试设备 Darwin 20.6.0 = iOS 14.8（对应 macOS 11 Big Sur 内核版本号）。

9.1 XNU 内核 = Mach + BSD + I/O Kit

Darwin 的内核叫 XNU（"X is Not Unix"，递归缩写），是一个混合内核，三部分粘在一起跑在同一个内核地址空间：

不是学术意义的微内核——Mach 没有跑在用户态，而是与 BSD 共享内核地址空间，是混合内核。

9.2 本文源码的归属

9.3 为什么 scudo 需要"Darwin 移植"

scudo 上游只有三个平台层：linux.cpp（Linux futex、getrandom、/proc/self/statm）、fuchsia.cpp、trusty.cpp。没有 Darwin 版——因为 Android/Fuchsia 不跑在 Darwin 上，Google 不会写。Darwin 的 API 跟 Linux 不同：

所以"Darwin 移植"= 把这些 Linux 特有调用换成 Darwin 等价物。这不是优化，是让 scudo 能在 XNU 内核上编译运行的基础工作。本项目写了 darwin.cpp + DarwinConfig，是首个在真实 iOS 设备上跑的 scudo benchmark。

9.4 开源

Apple 在 github.com/apple-oss-distributions 开源了 Darwin 的内核（XNU）和核心库（libmalloc、Libc、libdispatch 等）。这就是能拉到 xnu-7195.141.2 和 libmalloc-521.120.7 源码逐行核对的原因。但 GUI 层（AppKit/UIKit/Aqua）不开源。Darwin 是开源的；macOS/iOS 是闭源的商业产品 = Darwin + 闭源 GUI 框架。

10. 结论与方法论

1. iOS libmalloc 慢 4-6× 但 iOS 流畅——分配器速度是二阶项。一阶项：App 不被杀（jetsam 协同实测"先压缩扛再杀 / 先等再渐进杀"——动态策略）+ 渲染走独立流水线 + 无 GC。
2. jemalloc0（decay=0）速度最快且内存最省 → 综合最优（速度 21ns、retained 6MB）。decay 调参是 jemalloc 的免费午餐。mimalloc 调参反而是坏调参（不降 RSS 还拖垮大块）。
3. per-CPU 杂志的锁局部性优势真实但不足以抵消"每操作两次锁"的固定开销——shared_churn 证伪了"跨线程流让 libmalloc 追平"的假设，gap 反从 4.2× 拉到 6.3×。jemalloc per-thread 无锁 tcache 在所有吞吐场景都赢。
4. scudo（Android 11+ 默认）是"安全优先"的中间件：比 libmalloc 快 31%（60 vs 88 ns），比 jemalloc 慢 2.9×（60 vs 21 ns）。retained 最高（206MB）。大块瓶颈（8298 ns，secondary cache max=512KB 绕过缓存）。其 quarantine+checksum+MTE+GWP-ASan 是针对 Android 威胁模型的安全防线——iOS 不需要（沙箱+代码签名+libmalloc PAC+bmalloc），Android 需要（恶意应用+不可信 NDK）。不同威胁模型决定不同分配器选择。
5. iOS 不用 scudo 替代 libmalloc——不是 scudo 不好，而是 libmalloc 有 4 件 scudo 架构层面做不到的事：jetsam 协同链（MADV_FREE_REUSABLE + pressure_relief 回调 + VM tag——scudo 只有 MADV_DONTNEED + 定时 decay，不响应内核压力信号，换上去 App 会被 jetsam 杀）、arm64e PAC（对 free list 篡改比 scudo CRC32 更强）、per-CPU 杂志（固定核数最优）、25 年深度集成。让 scudo 做 Darwin 协同 = 重写 libmalloc。两套方案是各自生态的局部最优。
6. 鸿蒙 NEXT 在"渲染耦合"和"内存保命"两个一阶维度已结构性追平 iOS（统一渲染 + memcg/zswapd 分层回收），不再是"粗放 LMK 杀进程"。剩余 iOS 真实优势收窄为：无 GC（vs ArkTS GC）+ 算力统一冗余 + 分配器级主动回收提示。鸿蒙该补的是 ArkTS GC 而非分配器。
7. iOS 没有 memcg，但 per-task ledger+phys_footprint+memlimit(active/inactive)+jetsam 带+vm_compressor 是其功能对等物，且在"压缩页分开记账""active/inactive 双限""全局压缩+分配器主动还""按 App 优先级杀"这几点上比 Linux memcg 更为移动端调过。三者 reclaim→compress→kill 都到位，分工哲学不同。
8. Page fault 延迟 ~3000ns/fault（16K 页）——这是内核 zero-fill + 物理页分配的固定开销，不随大小/模式变化。一个 fault = ~143 次 jemalloc malloc（21ns）——这就是分配器要 cache 的根本原因：避免每次分配都 mmap。16K 页相比 4K 页减少 4× fault 次数，是大页对 mmap 场景的核心优势。
9. 内核选 WKdm 而非 LZ4 做内存压缩，不是因为快而是因为"可预测"——LZ4 解压比 WKdm 快 8×（15989 vs 1978 MiB/s），但 WKdm 压缩端快 2×（1594 vs 805 MiB/s），且字典编码固定复杂度（~0.52ms/页 可预测，LZ4 波动 59×）。内核需要可预测的回收延迟——6 核并发解压（4× 放大）弥补单线程劣势。LZMA 是反面教材（53.9ms 解压，不可接受）。LZFSE 太慢（88 MiB/s 压缩）不适合回收路径。→ iOS 用 WKdm + 6 核并发，Android 用 LZ4 单线程——不同架构，同一目标。

方法论自省

• 源码优先：每个结论带文件名+行号，不只靠记忆。尤其"鸿蒙靠 LMK 粗放杀"这种基于旧认知的判断，必须用源码核实——否则停在错误叙事上。
• 假设被证伪也照实写：shared_churn 推翻了"per-CPU 在跨线程流会追平"的假设，鸿蒙核实推翻了"靠 LMK 粗放杀"的判断。bench 的价值正在于它能推翻先入之见。
• 区分一阶项与二阶项：分配器速度是二阶项，内存保命/有无 GC/渲染是否进程外是一阶项。优化错了维度（如鸿蒙继续优化分配器而非 GC）事倍功半。
• 诚实边界：对 ArkUI 运行时/ArkTS GC 等无源码逐行核对的判断均标出不确定，等待进一步核实。

常见误区纠正（实测证据）

术语表