iOS WebKit 与 鸿蒙 ArkWeb 渲染进程深度对比

iOS 的 WebKit 是 Apple 自研的多进程 Web 引擎（WebKit2 架构）：应用进程只持有 WKWebView 这个"遥控器"，真正解析 HTML、执行 JS、排版绘制的是独立的 WebContent 进程，网络走 Networking 进程，整套进程由 XNU 内核的 per-task 内存账本（ledger）、jetsam 优先级带、freezer 冻结机制精细治理——内核源码里甚至有对 com.apple.WebKit.WebContent 的按名字特判。

鸿蒙的 ArkWeb 渲染进程则基于 Chromium + CEF 构建（官方明示），是"五进程模型"中的一环：Web 渲染进程负责 HTML 解析/排版/绘制 + JS/WASM 执行，GPU 光栅化与合成送显被拆到独立的 Web GPU 进程并与系统 RenderService 对接；移动端默认多个 Web 实例共享一个渲染进程以省内存，2in1 设备才默认独立进程。鸿蒙侧官方文档明确写着「Web 内核对内存大小的申请无限制约束」，内存治理策略与 iOS 完全不同。

本质区别一句话：两者都把"网页代码"隔离进无特权的独立渲染进程（防沙箱逃逸），但 iOS 走的是自研引擎 + 内核级强内存配额 + 按站点拆进程的路线；鸿蒙走的是 Chromium 血统 + 共享渲染进程省内存 + 独立 GPU 进程对接自研合成器的路线。

WebKit 文档定义 Site = scheme + eTLD+1（可注册域）。开启站点隔离后，跨站 iframe 不再和主框架同进程：

• RemoteFrame / RemotePageProxy：帧树中代表"另一个进程里的文档"的占位节点，JS 仍可遍历帧树但摸不到跨站 DOM。
• BrowsingContextGroup：追踪所有经 window.open opener 关系连接的页面及其全部进程；导航跨域时整棵帧树森林要在新进程重建。
• FrameProcess：记录"哪些帧在用哪些进程"，帧全部移除后进程终止或进 WebProcessCache 复用。
• ProvisionalFrameProxy / ProvisionalPageProxy：导航期间的临时进程驻留，收到网络响应才正式换树，失败可回滚。

为什么要拆进程？渲染引擎解析不可信网页，是整个系统最大的攻击面。任何 Blink/WebCore/JSC 的内存破坏漏洞，最坏也只能拿到 WebContent 的无特权上下文——这正是 iOS WebKit 与鸿蒙 ArkWeb 共同的设计出发点。

• setRenderProcessMode(RenderProcessMode.SINGLE=0 / MULTIPLE=1)：控制渲染子进程单/多进程。移动设备默认单（共享）进程渲染，2in1 设备默认多进程渲染；传入非法枚举值系统自动回落到多进程模式。
• sharedRenderProcessToken：多渲染进程模式下，相同 token 的 Web 组件优先复用与该 token 绑定的渲染进程；绑定关系在渲染进程初始化阶段形成，所有关联组件移除后解绑。
• terminateRenderProcess()：应用可主动杀渲染进程；会影响同进程的全部其他实例。
• onRenderExited(renderExitReason)：监听渲染进程退出原因（OOM、crash、正常退出）；多组件共用进程时每个受影响组件都会触发回调。
• onRenderProcessNotResponding / onRenderProcessResponding：渲染进程无响应监听（无法处理输入或未按时导航时触发，持续无响应可反复触发）。

OpenHarmony web_webview 仓库 README 原文："nweb is the native engine of the OpenHarmony webview component and is built based on Chromium and the Chromium Embedded Framework (CEF)"。华为官方版本对应表：

因此 ArkWeb 的"Web 渲染进程"在血统上是 Chromium RenderProcess：Blink 排版引擎 + V8 JS 引擎（ARM64 上同时配 Les Wasm 解释器），经 CEF/nweb 适配层接入鸿蒙图形栈（RenderService）与系统服务。

task.c L1178-1196 的注释块给出了权威定义——WebContent 进程的内存上限按这个口径计量：

/* phys_footprint: This is the sum of:
 *   + (internal - alternate_accounting)
 *   + (internal_compressed - alternate_accounting_compressed)
 *   + iokit_mapped
 *   + purgeable_nonvolatile + purgeable_nonvolatile_compressed
 *   + page_table                                    */
 1241 task_ledgers.internal = ledger_entry_add(t, "internal", ...);
 1243 task_ledgers.iokit_mapped = ledger_entry_add_with_flags(t, "iokit_mapped", ...);
 1249 task_ledgers.page_table = ledger_entry_add_with_flags(t, "page_table", ...);
 1251 task_ledgers.phys_footprint = ledger_entry_add(t, "phys_footprint", "physmem", "bytes");
 1253 task_ledgers.internal_compressed = ledger_entry_add(t, ...);
 1290 task_ledgers.frozen_to_swap = ledger_entry_add(t, "frozen_to_swap", ...);  // CONFIG_FREEZE

要点：匿名脏页 + 压缩器里的份额 + IOKit 映射 + 非易失 purgeable + 页表都算进足迹——WebContent 里庞大的解码图像、IOSurface、JIT 页无一漏网。iOS 18 还加了 media/graphics/neural 分类记账（task.c L1259-1295），为分类限费铺路。

超限回调直接挂在账本上：task.c L1460

 1460 ledger_set_callback(t, task_ledgers.phys_footprint,
      task_footprint_exceeded, NULL, NULL);

 7081 PROC_CROSSED_HIGH_WATERMARK__SEND_EXC_RESOURCE_AND_SUSPEND(...)
      // 先挂起进程（SUSPEND），再发 EXC_RESOURCE 例外；
      // hwm_user_cores 时还会先落一份 coredump（L7104-7112）
 7207 task_footprint_exceeded(int warning, ...)
 7240     // CONFIG_DEFERRED_RECLAIM：先同步回收再复核余额，
      // 余额已回落则直接 return（给进程自救机会）
 7284 task_process_crossed_limit_no_diag(...)
 7297     PROC_CROSSED_HIGH_WATERMARK__SEND_EXC_RESOURCE_AND_SUSPEND(...);  // 真超限
 7319     PROC_CROSSED_HIGH_WATERMARK__SEND_EXC_RESOURCE_AND_SUSPEND(...);  // 诊断阈值

memlimit 分 active/inactive 两档（App 前后台切换时换限额），fatal 与否由 memorystatus 决定。WebContent 进程超限的最终结局通常是 jetsam 的 per-process-limit 原因被杀。

Jetsam 原因码全表 kern_memorystatus.c L103-117：

jettisoned | highwater | vnode-limit | vm-pageshortage | proc-thrashing
fc-thrashing | per-process-limit | disk-space-shortage | idle-exit
zone-map-exhaustion | vm-compressor-thrashing | vm-compressor-space-shortage
low-swap | sustained-memory-pressure | vm-pageout-starvation

优先级带 kern_memorystatus.c L126-143：FOREGROUND / AUDIO_AND_ACCESSORY / CONDUCTOR / DRIVER_APPLE / HOME / EXECUTIVE / IMPORTANT / CRITICAL（数值定义在 sys/proc.h 的 JETSAM_PRIORITY_*）。kill 主循环 kern_memorystatus.c L3884-3990（memorystatus_thread_internal） 的次序：先清超 highwater 的进程 → 再 swap 全部 app → 然后逐 band 从最不重要往重要杀，每杀一个都回头重查 highwater。

关键限额参数：

• L293 MEMORYSTATUS_CRITICAL_BASE_PERCENTAGE_SMALL = 5%（小内存机 critical 档基线；中/大内存机比例不同，L287-307 注释表）
• L381 memorystatus_ios13extended_footprint_limit_mb = 1800（扩展上限）
• L384-387 entitled 设备可调 max_task_footprint；L610 sysctl kern.max_task_pmem
• L613 legacy_footprint_bonus_mb = 50（老 App 补偿额度）

// kern_memorystatus_freeze.c (xnu-11215.1.10)
  104 unsigned int memorystatus_frozen_count_webcontent = 0;
  224 static void memorystatus_demote_frozen_processes(bool urgent_mode);
  312 calculate_thaw_percentage(uint64_t frozen_count, uint64_t thaw_count);
  366 get_thaw_percentage_webcontent();   // WebContent 专属解冻率

Freezer 把后台进程的用户态匿名页整进程收进压缩器/swap（iOS 18 桌面级 iPad 与 Mac 上 swap 路径完备：vm_compressor_backing_file.c L47/L88/L108/L146/L182，含 FIOPINSWAP ioctl、VSWAP 标记与 ENCRYPTED_SWAP）。冻结名额有限（memorystatus_frozen_processes_max），解冻率决定下一轮还愿不愿意冻它——这正是 §7 里 WebContent 特判的意义。

冻/解冻会计账进 ledger 的 frozen_to_swap 条目 task.c L1290 / L5099-5121。

// bsd/sys/mman.h
 127 #define MAP_JIT   0x0800  // Allocate a region that will be used for JIT purposes
 212 #define MADV_FREE_REUSABLE  7   // pages can be reused (by anyone)
 213 #define MADV_FREE_REUSE     8   // caller wants to reuse those pages

// osfmk/vm/vm_map.c — JIT 区域的三重约束
 626/2882 printf("CODE SIGNING: ... curprot cannot be write+execute...");  // W^X 互斥
 2895 if (entry_for_jit && cur_protection != VM_PROT_ALL) {
      // 非 macOS 平台：MAP_JIT 区必须是全 RWX，否则拒绝
 2930     printf("CODE SIGNING: ... JIT requires RWX: failing.");
      return KERN_PROTECTION_FAILURE;
      }
 2945 if (map->map_disallow_new_exec == TRUE) { ... }  // 可执行锁死：封掉新增可执行映射

解读：iOS 上 W 与 X 永久互斥（L626/L2882）；带 com.apple.security.cs.allow-jit 身份的进程才能用 MAP_JIT，且该区域权限必须是完整的 RWX（L2895-2930，"JIT requires RWX"）；进程还能自愿锁死后续可执行映射（L2945）。WebContent 里 JSC 的 Baseline/DFG/FTL JIT 代码页就活在这个 MAP_JIT 区里，受 pg_tlb/code signing 监控。对照：鸿蒙的 V8 JIT 走 Linux 血统内核的标准 W^X 双映射，无 MAP_JIT 概念。

MADV_FREE_REUSABLE/REUSE 则是 WebKit 内存缓存"可丢弃"语义的内核支撑——内存吃紧时这些页可被任何人复用，不计入进程压力。

XNU 的强制访问控制框架（TrustedBSD MAC）在内核埋了几百个策略点，sandbox/ContainerManager 等策略模块（闭源）挂上来：

// security/mac_process.c (xnu-11215.1.10)
 209 mac_cred_label_associate_fork(kauth_cred_t cred, proc_t proc);
 323 mac_proc_check_debug(...);   // 谁能调试谁
// 加上 mac_cred_label_associate_kernel/user、mac_proc_check_visible 等全套钩子

WebContent 进程"无网络 socket、无任意文件写、IPC 白名单"的沙箱画像，就是用户态沙箱 profile 编译成 MACF 规则后在全部内核策略点上过滤的结果。

// bsd/kern/kern_memorystatus_notify.c (xnu-11215.1.10)
  150 vm_pressure_level_t memorystatus_vm_pressure_level = kVMPressureNormal;
  129 static struct knote *vm_pressure_select_optimal_candidate_to_notify(...);
  228 if (level == kVMPressureWarning || kVMPressureUrgent) { notify... }
  232 else if (level == kVMPressureCritical) { ... }
  443 uint64_t memorystatus_kill_on_sustained_pressure_window_s = 60*10;  // 10 分钟窗口
  453 static void sustained_pressure_handler(void*, void*);      // iOS16+ 引入

内核按 Normal→Warning→Urgent→Critical 分级，经 knote 通知到"最值得通知的进程"（前台优先）。WebContent 收到 pressure 事件后清 JS GC、丢内存缓存、释放解码位图——这是它超限前的自救窗口。持续高压 10 分钟仍不缓解，iOS 16+ 会直接触发 sustained-memory-pressure 击杀（六版本实测：iOS 12/13/14 无此逻辑，16 起出现）。

iOS 16（xnu-8792.61.2）起，freezer 代码里出现了对渲染进程的按进程名硬编码统计——内核为 WebContent 单独建了一本"冻结台账"：

// kern_memorystatus_freeze.c (xnu-11215.1.10)
// 冻结时：
  628 if (strcmp(p->p_name, "com.apple.WebKit.WebContent") == 0) {
  629     memorystatus_frozen_count_webcontent++;
  630     os_atomic_inc(&memorystatus_freezer_stats.mfs_processes_frozen_webcontent, ...);
       }
// 同样逻辑在 memorystatus_freeze_process() 内再出现一次：L1903-1905

// kern_memorystatus.c (xnu-11215.1.10)
// 进程移除时核销：
 2715 if (strcmp(p->p_name, "com.apple.WebKit.WebContent") == 0) {
 2716     assert(memorystatus_frozen_count_webcontent > 0);
 2717     memorystatus_frozen_count_webcontent--;
       }
// memorystatus_on_resume() 里解冻记账：
 3217 if (strcmp(p->p_name, "com.apple.WebKit.WebContent") == 0) {
 3218     os_atomic_inc(&memorystatus_freezer_stats.mfs_processes_thawed_webcontent, ...);
       }

并用专属 sysctl 暴露 WebContent 解冻率：kern_memorystatus_freeze.c L366-380（get_thaw_percentage_webcontent / kern.memorystatus_freezer_thaw_percentage_webcontent）。

为什么值得单列？这是"内核反过来给某个用户态引擎开小灶"的直接证据：iOS 设备上后台标签页的 WebContent 进程既多又大，Freezer 需要单独评估"冻 WebContent 划不划算"（解冻率太高说明反复冻/解冻浪费带宽），进而影响冻结名额分配策略。鸿蒙侧没有任何等价的内核特判——ArkWeb 的内存治理完全在框架层（且官方明示内核不设申请上限），这是两平台最深刻的设计哲学差异之一。

给开发者的实用结论：在 iOS 上做混合开发，WKWebView 的崩溃与内存问题要盯 WebContent 进程的 phys_footprint（可在 Xcode 的 Memory Report 里看分进程曲线），系统会在超限时杀进程救全局；在鸿蒙上则要主动用 setRenderProcessMode(MULTIPLE) 换隔离性、用 onRenderExited/onRenderProcessNotResponding 兜住共享进程的连坐风险——两个平台对"渲染进程"的治理哲学完全不同，移植方案不能照抄。