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 兜住共享进程的连坐风险——两个平台对"渲染进程"的治理哲学完全不同，移植方案不能照抄。

如果详情页是原生 VC：UINavigationController 把整个栈都留在内存里，UIKit 只负责可见性——push 完成后旧 view 移出 window（view.window == nil），RenderServer 的合成树里没有它，GPU 零开销；CPU 侧也不再给它布局/绘制回调。但内存不会自动回收：iOS 6 起 viewDidUnload 废弃，系统不再卸载视图；内存紧张时 UIKit 只投递 didReceiveMemoryWarning，旧页面释放多少完全取决于 App 自己。

情形 A：同一个 WKWebView 里连续导航（历史栈）

旧页面离开时若可缓存，整个 Page 被挂起后放进 BackForwardCache（旧称 PageCache）——JS 停、定时器停、渲染停，但 DOM 树和 JS 堆留在 WebContent 进程内存里，回退命中即瞬时恢复（触发 pageshow persisted）。

// WebCore/history/BackForwardCache.cpp（WebKit main，本仓 webkit-src/ 归档）
 590 std::unique_ptr<CachedPage> BackForwardCache::suspendPage(Page& page);
 726 void BackForwardCache::prune(PruningReason) {
          while (pageCount() > maxSize()) { ... 逐出最旧 ... } }
// 逐出原因只有三种：MemoryPressure / ProcessSuspended / ReachedMaxSize（L462-470）

容量小得惊人（按页面数计，WebKit/Shared/CacheModel.cpp 的 calculateMemoryCacheSizes）：

也就是说：连点 5 个商品页，只有最近 1–2 页能留在缓存里，更早的已被销毁，回退时只能重新加载。此外缓存还有过期时间（backForwardCacheExpirationInterval）。

情形 B：App 为每个/每几个详情页开独立 WKWebView（大厂常用）

不可见 webview 的 view 不在 window 里 → WebKit 的 activity state 丢失 IsVisible → 渲染更新冻结、requestAnimationFrame 停止、DOM 定时器节流。WebKit 对"整进程全是不可见页面"还有专门策略——把普通警告当致命级处理：

// WebKit/WebProcess/WebProcess.cpp L509-511（原文注释）
// If this process contains only non-visible content (e.g. only contains
// background tabs), then treat the memory warning as if it was a critical
// warning to maximize the amount of memory released for foreground apps.
if (m_pagesInWindows.isEmpty() && critical == Critical::No)
    critical = Critical::Yes;

而预热的、被缓存的（CachedWebContent/PrewarmedWebContent/Suspended）进程遇到内存压力直接退出自己，不尝试省内存（WebProcess.cpp L519-529）。

// WTF/wtf/cocoa/MemoryPressureHandlerCocoa.mm L84-117（WebContent 进程内）
  87 memoryPressureEventSource() = dispatch_source_create(
           DISPATCH_SOURCE_TYPE_MEMORYPRESSURE, 0,
           NORMAL | WARN | CRITICAL | PROC_LIMIT_WARN | PROC_LIMIT_CRITICAL, queue);
// XNU 内核压力/进程限额事件 → dispatch → respondToMemoryPressure()

// WebCore/page/MemoryRelease.cpp L122-128（关键释放路径）
 126 BackForwardCache::singleton().pruneToSizeNow(0, pruningReason);
//  ↳ 内存压力 或 进程即将挂起 时：缓存清零，旧详情页全部销毁
 130 MemoryCache::singleton().pruneLiveResourcesToSize(0, /*销毁全部解码图像*/);
// 另有 CSSValuePool drain、布局缓存清理、JSC GC、bmalloc scavenger 归还物理页

若释放后仍超 per-process phys_footprint 限额：MemoryPressureHandler 的 memoryKillCallback 上报 UI 进程（WebProcess.cpp L545-552），进程被杀，App 收到 webViewWebContentProcessDidTerminate: 回调后重载页面——这正是用户偶见"网页白屏自动刷新"的完整因果链。App 退后台后则由 RunningBoard 挂起、XNU freezer 冻结（见 §6.4/⑦）。

• 可见性与渲染归 UIKit/CA：不可见 = 不合成、不布局、不耗 GPU，但对象仍在。
• H5 旧页的挂起与回收归 WebKit：BackForwardCache（0–2 页）+ activity state 冻结 + MemoryPressureHandler 按压清空。
• 进程级生死归 XNU/RunningBoard：限额、挂起、冻结、击杀，一路兜底。
• iOS 不做"页面栈裁剪"：无论原生 VC 还是 WKWebView 实例，系统从不主动销毁；只保留最近 3 个详情页、WebView 复用池这类策略，是淘宝/微信这类 App 在应用层自己实现的。

Chromium base/memory/discardable_shared_memory.cc（本仓归档 purgeable-report/src/chromium_dsm.cc）的 Purge() 按平台选择 madvise 参数——同一个抽象，两种哲学：

// Linux / ChromeOS / Android（含鸿蒙这一 Linux 血统分支）：
// "provide MADV_REMOVE which is preferred as it has a behavior
//  that can be verified in tests"
#define MADV_PURGE_ARGUMENT MADV_REMOVE        // 立即打洞释放

// Apple 平台：
// "MADV_FREE_REUSABLE is similar to MADV_FREE, but also marks the pages
//  with the reusable bit, which allows both Activity Monitor and
//  memory-infra to correctly track the pages"
#define MADV_PURGE_ARGUMENT MADV_FREE_REUSABLE  // = XNU purgeable 入口！

Lock() 的苹果分支注释更直白（chromium_dsm.cc L277-296）：

// On macOS, there is no mechanism to lock pages. However, we do need to call
// madvise(MADV_FREE_REUSE) in order to correctly update accounting for
// memory footprint via task_info().
// ... the corresponding call to MADV_FREE_REUSABLE is in Purge(), since
// that's where the memory is actually released, rather than Unlock(),
// which is a no-op on macOS.

解读：在苹果平台上 Chromium 的"discardable"整个儿降级为 XNU purgeable 的包装——Unlock 是空操作，丢弃决策交还内核状态机；在 Linux 系（鸿蒙）上则是用户态管理器主动 MADV_REMOVE 立即释放，内核只看到一次普通的打洞操作。"discardable" 是个跨平台抽象：落到苹果内核就是 purgeable，落到 Linux 内核就是 madvise。

// vm_purgeable.c（iOS 18 = xnu-11215.1.10，本仓 purgeable-report/src/vm_purgeable_ios18.c）
  62 struct token { token_cnt_t count; ... };      // "成熟度"邮票
  77 int available_for_purge = 0;                 // ripe token 计数：可零成本回收的对象数
 158 vm_purgeable_token_add(queue);              // volatilize 时发行 token，面值=当时 inactive 页流量
 877 vm_purgeable_object_purge_one(force_purge_below_group, ...);
      // 只碰"成熟"对象；force 时清 group < 阈值（压力等级→2/5/8）
1483 vm_purgeable_accounting();                   // VOLATILE 瞬间 ledger 换边：移出 phys_footprint

// 回收入口（vm_pageout.c iOS 14.8 = xnu-7195.141.2）
2999 /* Before anything, we check if we have any ripe volatile objects around. */
3019 retval = vps_purge_object();          // 页回收扫描的第一顺位，先于文件页/压缩
4822 force_purge: warning=2 / urgent=5 / critical=8   // 压力等级旁路成熟度

这条机制链的含义：purgeable 丢弃是 iOS 内存回收的"第一顺位"——零成本（不用压缩、不用写盘、不用杀人），排在文件页回收和压缩器前面。而这一切对被标 volatile 的进程是"免费"的：它的 phys_footprint 同瞬间下降，jetsam 高水位考核也随之宽松。

ImageIO 解码 4000×3000 JPEG（解码缓冲 45.8 MiB），mach_vm_region_recurse + vm_purgable_control(GET_STATE) 探测：

draw#1 (解码)    : 100.0 ms
  0x114230000  46880 KiB  state=EMPTY     tag=70 (VM_MEMORY_IMAGEIO)  // 解码 scratch：用完即 EMPTY
  0xbda800000  46912 KiB  state=EMPTY     tag=3  (MALLOC purgeable)   // 解码缓存刚建
draw#2 (缓存命中): 51.5 ms
  0xbda800000  46912 KiB  state=VOLATILE  tag=3                       // ★ 缓存常驻 VOLATILE
draw#3 (释放重建): 2.3 ms                                                            // volatile ≠ 已回收！页还在，命中零成本

这正是 purgeable 哲学的实证：缓存主动标 VOLATILE 让出记账，但物理页仍在；内存充裕时命中几乎免费（2.3ms），内存紧张时内核第一批收割它们。对照 Chromium 在 Linux 上的 MADV_REMOVE 是"立即还给内核"，两种时机模型截然相反——但目标函数一致：别等 OOM 才动手。

• 是同类设计：都把"可再生数据"标记成可回收，都避免 OOM 被动释放，都靠 zero-fill + 状态查询实现重建。
• 但层次不同：purgeable 是内核原语（状态机/成熟时钟/足迹豁免/第一顺位回收）；鸿蒙上的 discardable 是用户态框架（共享内存段 + 时间戳 LRU + madvise 执行），内核不知情。
• 记账差异最本质：iOS 的 volatile purgeable 不计入 phys_footprint，直接影响 jetsam 生死判卷；鸿蒙无此口径（官方明示 Web 内存申请无内核限制），治理全在框架层。
• 合流彩蛋：Chromium 在苹果平台的 discardable 后端就是 XNU purgeable（MADV_FREE_REUSABLE/REUSE），Unlock 为空操作、决策交还内核——两条技术在苹果平台合流，在鸿蒙平台分叉。
• WebKit 自身的演变：WebCore 的 PurgeableBuffer 已移除；如今 iOS WebKit 的 purgeable 全部经由系统框架（ImageIO/CG/IOSurface/JSC），WebContent 自己只在 RemoteLayerBackingStore 上调 IOSurfaceSetPurgeable。

// cc/tiles/gpu_image_decode_cache.cc (M114)
 594 // Task which decodes an image and stores the result in discardable memory.
     // This task does not use GPU resources and can be run on any thread.
     class GpuImageDecodeTaskImpl : public TileTask { ... };

// RGBA 与 YUV 两种解码结果都包成 DecodedAuxImageData：
 761 DecodedAuxImageData(const SkPixmap& rgba_pixmap,
                    std::unique_ptr<base::DiscardableMemory> in_data);
 771 DecodedAuxImageData(const SkYUVAPixmaps& yuva_pixmaps,
                    std::unique_ptr<base::DiscardableMemory> in_data);

// 分配点（真正的调用处）：
2375 std::unique_ptr<base::DiscardableMemory> backing_memory;
2380 auto* allocator = base::DiscardableMemoryAllocator::GetInstance();
2382 backing_memory =
2383     allocator->AllocateLockedDiscardableMemoryWithRetryOrDie(
2384         info.size, /*on_no_memory=*/ClearCache 回调);

三个值得注意的细节：

• 分配失败自救链：on_no_memory 传的是 ClearCache——分配失败 → 先清自己的缓存 → ReleaseFreeMemory() 清空闲段 → 重试 → 再失败才 TerminateBecauseOutOfMemory（模式定义在 base/memory/discardable_memory_allocator.cc，前章已验证）。
• 科学方法：源码里专门有一个对照组类 gpu_image_decode_cache.cc L478 HeapDiscardableMemory（普通堆内存伪装的 DiscardableMemory），配合 Finch 开关 kNoDiscardableMemoryForGpuDecodePath 做 A/B——"不用 discardable 会怎样"本身就是被实验的课题。
• 为什么这条路最适合 discardable：解码位图上传成 GPU 纹理后就闲置了；但在上传前必须锁定（Lock），上传完 Unlock 即可让出。低频访问、高重建成本可接受、体积大——完美画像。

图片上传到 GPU 后变成 GL 纹理，继续由 discardable 体系管理（GPU 进程侧）：

// gpu/command_buffer/service/service_discardable_manager.h (M114)
// "A helper class used to manage discardable textures...
//  Used by the GLES2 Implementation."（client 侧头注释）
void InsertLockedTexture(uint32_t texture_id, size_t texture_size, ...);
bool UnlockTexture(...);   // unlock 后纹理可被删除回收
bool LockTexture(...);     // 下次绘制前锁定，失败=已被回收需重建
void HandleMemoryPressure(MemoryPressureLevel);  // 压力感知
void EnforceCacheSizeLimit(size_t limit);
size_t DiscardableCacheSizeLimitForPressure(base_cache_limit, level);
//   ↑ 缓存上限随压力等级缩水（不是只在压力事件时一次性清空）
// GpuDiscardableEntry { handle, unlocked_texture_ref, size } + base::LRUCache

渲染进程侧还有对应客户端 gpu/command_buffer/client/client_discardable_manager / client_discardable_texture_manager（ GLES2 实现使用），通过 handle 与 GPU 进程同步锁状态。

  Web 渲染进程                          宿主进程（浏览器进程）
┌────────────────────────────┐              ┌─────────────────────────────┐
│ cc::GpuImageDecodeCache    │   mojo IPC   │ DiscardableSharedMemory     │
│  ├ 解码任务(输出=discardable)│ ───────────► │ Manager (Get())             │
│  └ on_no_memory=ClearCache │  请求段/时间戳 │  ├ 段集合 LRU（按now排序）    │
│ Skia SkDiscardableMemory ──┤              │  ├ OnMemoryPressure          │
│ gpu client:                │              │  └ ReduceMemoryUsageUntil... │
│  ClientDiscardableTexture  │              └─────────────────────────────┘
│ ClientDiscardableShared-   │
│  MemoryManager             │              Web GPU 进程
│  ├ 段内 free-list 堆        │              ┌─────────────────────────────┐
│  └ OnBackgrounded 收缩      │              │ ServiceDiscardableManager   │
└────────────────────────────┘              │  ├ GL 纹理 LRU               │
                                            │  ├ 压力降容(CacheSizeForPressure)│
   后端(Backing Trial 三选一):                │  └ EnforceCacheSizeLimit     │
   共享内存段 | MADV_FREE | ashmem(仅安卓)     └─────────────────────────────┘

对应到 ArkWeb：以上全部组件（①–⑤）就是鸿蒙 Web 渲染进程 / Web GPU 进程 / 宿主进程里的实际代码。鸿蒙差异点：无 ashmem（回落共享内存段后端）；Purge 时走 Linux 分支 MADV_REMOVE（§12 已证）；段本身的创建走 OHOS 的 POSIX 共享内存。

• 核心场景就一个字：图——GPU 解码缓存（上传前的位图）+ GPU 纹理（上传后的）+ Skia lazy-image 像素缓存，全部围绕"图片数据生命周期长于使用瞬间"设计。
• 基础设施比场景更有意思：跨进程统一段管理（宿主进程 LRU + 渲染进程段内堆 + 前后台策略），这是 Chromium 与 XNU purgeable 最本质的差异——iOS 把这些策略全放内核，Chromium 在用户态自建了一套"小内核"。
• 不是所有缓存都适合：软件光栅解码缓存刻意不用 discardable（普通内存+预算+仅 CRITICAL 清空）——高频 CPU 访问的数据配不上锁语义。
• 压力响应是双层的：用户态（ServiceDiscardableManager 缓存上限随压力缩水 / ClientManager 退后台收缩）+ 内核态（段被 MADV_REMOVE 后 Lock 失败）。