iPhone 12 Pro · 6G DDR 五维拆解与正交恒等式

一、核心结论先看这个

能正交相加，但必须换分母：用「页状态」做桶 → 各项互斥、严格可加（下面每项都实测闭合到页）； 用「进程 footprint」做桶 → 必炸：朴素五维求和 = 5198.7 MiB ≠ 6144 MiB，差 945.3 MiB，五个交叉项已逐一量化（见第四节）。 修正版五维（文件缓存计入可用 ＋ 去两处重复）已做到严格加总 = 6,144.0 —— 见第七节。

二、三层 DDR 恒等式全部实测闭合

S（speculative 17,536 页）在公式中必须显式扣一次：它物理上在 free 里、归属上又在 E+N 里——双重身份，只许出现一次。

三、五维归属实测293/295 进程全量普查

四、交叉项量化五维不能朴素相加的四个原因

差额精确对账（run4 实测）：缺口 945.3 = 文件缓存未计入 +1,883.4 − 压缩换算差 902.9 − iokit/tag 交叠 29.4（余 5.7 为槽位推算的舍入）。加文件缓存是必要条件，但不充分——见第六节演示。

五、优化正交公式推荐口径

六、把文件缓存加进「可用」就行了吗？对账演示：会超 938 MiB

超出的 938.1 恰好就是两处重复记账：压缩换算差 902.9 ＋ iokit/tag 交叠 29.4（余 5.7 舍入）。 所以正确操作是「加文件缓存 ＋ 去两处重复」同时做——做完即得修正版五维（第七节），严格加总 = 6,144.0。

七、五维表（fp 正常算 ＋ 压缩节省单列一行）加总 = 6,144.0 ✓

闭合校验：基数里的压缩数据(stored) = 任务侧 1,794.9（在 fp 内）＋ 内核侧 1,033.9（内核行）= comp_stored 2,828.8 ✓ → 节省行把整机 stored 一次换算成 comp_occ 口径（2,828.8 − 1,405.8 = 1,423.0）。

汇总视图（同项重排，与明细表恒等）：可用 = free＋文件缓存＋volatile 驻留；内核净 = 内核 − iokit 残差；NV＋tagfp 合并为 fp 校准项

汇总语义：广义可用 2,534.0 MiB = 全机 41.2%（立即 10.3% + 可回收 30.7% + 可丢弃 0.3%）；iokit 残差改记任务侧（mediaserverd 等映射者），内核净桶只剩内核自有内存。

历史口径（均与本题恒等于 6,144.0，仅桶间分布不同）：整机零假设版（生态 75.9 / 系统 804.0 / 内核含压缩器 2,170.4）与归属视图版（421.8 / 1,350.0 / 1,278.4），详见 REPORT §10.39b/c。

去重四规则fp 口径求和的卫生规则

验证器（每次普查后跑三条）：① Σint+Σvolatile+内核可分页 = N（实测 57,137 精确）② 任务 stored + 内核 stored = comp_stored（基数闭合，本表成立的必要条件）③ 本表合计 = 6,144.0 ± 0.1。

八、场景实验：公式有效性验证5 场景全成分对比，全部闭合 6,144.0（差 0.0）

S0 基线 → S1 拉起 B站/微信/抖音/淘宝/小红书 → S2 相机前台（预览管线全开）→ S3 相机后台化＋Safari/Maps/照片/音乐 → S4 全家桶＋相机再前台（free 仅剩 4,768 页）。同一公式逐场景计算：

五个极端状态（free 40,067→4,768 页、wire 47,731→114,242 页、压缩槽 90,070→144,920 页）下合计恒 = 6,144.0，偏差 0.0——公式有效性验证通过。注：场景表初版「内核压缩stored／fp卫生小项」两列因 tagcmp/tagfp 解析键名覆盖各偏 ±(tagcmp−tagfp)（补偿性误差，合计不受影响），已修正。

汇总视图跨场景演化（可用 = free＋文件缓存＋volatile；内核净 = 内核 − iokit；校准 = −NV−tagfp）

广义可用 2,533.0 → 782.0 MiB（41.2% → 12.7%）：相机＋全家桶把"实际可用"吃到只剩 1/3，其中文件缓存是被主要征用的部分（1,886.8 → 698.0）；内核净桶在相机场景涨到 2,442.6——相机锁页缓冲中未映射进任何任务 fp 的部分（≈wire 增量 − iokit 残差增量 ≈ 379 MiB）留在内核，已映射部分（608.5~669.4）归系统服务 fp 桶。

占用分析 ①：相机的内存签名（S1→S2）

相机前台总成本 ~2.2 GiB，但 Camera app 自身 fp 仅 23.9 MiB——成本住在 wire（锁页缓冲）与 mediaserverd；S3 相机退场时 wire 回落 −958.6、mediaserverd 708.4→48.6，完全可逆。

占用分析 ①补：mediaserverd 的 fp 与 vm_stat 的 wire——重复，不是累加（S5 相机开 ↔ S6 相机关 A/B 实测）

判定：IOKit 映射的 476.9 MiB 是内核/驱动分配的相机像素缓冲（IOSurface）映射进 mediaserverd 地址空间——fp 按映射面积记账，vm_stat 按物理持有计入 wire：同一批页，两个账本各记一次 = 重复。若当"累加"处理，相机关闭时应在 N 或 free 出现 ~477 MiB 的"独立缓冲池"——实测没有（N 只涨 Safari 的 135.9，free 的回填与 wire 的跌幅对账 Σ≈0）。wire 跌幅 974.6 = IOKit 映射 476.9 ＋ 内核私有锁页 ~497.7（ISP/驱动 DMA，从不在任何 fp 里）。公式因此必须去重一次：明细视图扣 fp 侧（iokit 残差归内核桶），汇总视图扣内核侧（内核净）。S1↔S2↔S3 早前镜像（mediaserverd fp +670/−660 与 wire +984/−958 锁步）为同一结论的二次印证。

占用分析 ①补2：把"wire 重复量"从 fp 里直读出来（S9 A/B，工具 iokitmap）

内核账本层面这是官方定义 [SRC xnu-7195 task.c:986-1009]：phys_footprint = (internal−alternate_accounting) + (internal_compressed−alternate_accounting_compressed) + iokit_mapped + purgeable_NV(+cmp) + page_table；注释明言 alternate_accounting 是"internal 里属于 IOKit 映射的脏页——同时记在 internal 和 iokit_mapped 两个账本，必须减去避免双计"。但 14.8 的 task_vm_info 不暴露这些字段（task_info.h:388-415，新版 xnu 才有 ledger_alternate_accounting）——所以一行式直读在 14.8 无 API，只能减法。用户态直读走两条路：mach_vm_region_recurse 对 App 可行（抖音 t88=61.6M 与 BSD 路径完全一致），对平台二进制被拒（任务端口转 map 权限门槛，kr=0x4）；proc_pidinfo(PROC_PIDREGIONINFO)（BSD 路径，root 即可，不经任务端口）读通平台二进制——mediaserverd 的 IOSURFACE 映射与 fp 残差同步摆动（吻合 92%，差值 ~38 MiB = mediaserverd 的 alternate_accounting/tagged/page_table 记账差）。卫生①今后可直读为主、减法为校验。（注：区域级 pages_resident 对 IOKit 映射对象记账失真，勿用。）

占用分析 ①补3：wire 增量分解——重复 vs 额外驱动开销（"是否两组独立页"假设检验）

"全部是独立驱动开销"假设被三重反驳：① 状态穷尽——映射的 ~496M DMA 缓冲页必须住在 wire 或 N（不可能是 free/external/compressor）；② N 无空间——kp=N−任务账本，相机开时 kp 133.8→81.4 MiB 不升反降（N 的 91% 被任务账本认领），藏不下 496M；③ wire 幅度——全独立且都锁页需涨 985.9+496.3≈1,482M，实测只涨 985.9M。附加强化证据：mediaserverd 自身 pmap 驻留仅 114.7 MiB ≈ int 63.3＋ext 46.7——它几乎没 fault 过那 481M 映射（像素由 ISP/GPU 直接 DMA），fp 仍按映射配额收 497M：配额账本与物理账本指向同一批页。误判为"全额外"（不去重）则合计 +496.3 爆表，实测闭合 6,144.0 证明必须去重。

占用分析 ①补4：记账机制——为什么"减法残差"是精确的（求和项里确实有这一项）

[SRC xnu-7195 task.c:1049-1058] 内核给每个任务开一套独立账本列（internal / iokit_mapped / alternate_accounting(+cmp) / page_table / phys_footprint 本身），每列在事件发生时逐次 credit/debit，查询时直接抄表——fp 不是求和算出的，是里程表。[SRC vm_map.c:20208-20229] IOKit 映射进任务时：ledger_credit(iokit_mapped, bytes); ledger_credit(phys_footprint, bytes); 内核注释原话"phys_footprint is a composite limit consisting of iokit + physmem, so we need to bump both counters"——恒等式由构造保证（另有 LEDGER_CHECK_BALANCE 审计、fork 时 vm_map_copy_ledger 整列继承）。但 14.8 的 task_vm_info 只回传部分列（internal/compressed/NV/tagged ✓；iokit_mapped / alternate / page_table ✗，新版 xnu 才暴露）→ 残差 = 未暴露列的打包和，对账本系统精确；"混小项"（page_table 等 ~8%）正是打包的代价。用户态正向 walk 数的是映射区域面积（不同口径，S9 实测差 38.6 MiB），故生产用减法、walk 做交叉验证。

占用分析 ②：后台生态 App 的压缩收容（S1 前台新拉 → S4 后台，fp / 驻留 / 压缩 MiB）

铁证：后台化后驻留清零、数据全进压缩器（抖音 345.5→0.5 驻留），而 fp 几乎不变（564.6→573.1）——fp 是配额视角（stored 口径），物理成本全部转移到压缩槽。这正是「压缩节省行」必须存在的实证：节省行 S0→S4 从 −1,407.6 加深到 −2,442.4（节省了 2.4 GiB），压缩器用 2,264 MiB 槽位装下了 4,707 MiB 数据。

九、原始数据run4 原子快照 + 普查合计

十、复现方法与工具坑全部可在越狱设备上重放

# ① 三层数字
sysctl hw.memsize hw.pagesize
vm_stat                                  # 各页状态
ioreg -p IODeviceTree -l | grep -E "dram-size|secluded"   # 6GiB 物理与 secluded

# ② 全进程普查（探针 ios-probe/cli/memcensus.c，编译后设备侧 ldid 签名）
xcrun -sdk iphoneos clang -arch arm64 -o memcensus memcensus.c
#   部署后: /var/mobile/ios_memslice/memcensus
#   输出 M/V/E/K/S 行 + 每进程 P 行（fp/internal/external/compressed/账本）

# ③ 恒等式核验（本页所有 ✓）
#   states+R_pool==hw.memsize/16384 ; R_chip+memsize==dram-size
#   ext+int==active+inactive+speculative

十一、鸿蒙拆解公式（对照 iOS 结构）HUAWEI Mate 80 Pro · HarmonyOS 7 · HongMeng 1.13 · 16 GB DDR

同一套"每页恰一状态、页页闭合、重复记账显式去重"的方法论移植到鸿蒙。数据源全部为单快照可读计数器： /proc/meminfo + /proc/memview + 每进程 /proc/<pid>/status(VmRSS/RssAnon/VmSwap) + /proc/<pid>/smaps_rollup(Pss/Pss_Anon/Pss_File/Pss_HHP)。

A. 物理状态恒等式（空闲态 3 快照验证，残差 ±24 MiB ≈ 0.15%）

MemTotal = MemFree + AnonPages + Cached + Slab + KernelStack + KernelDynamic + PageTables
         + VmallocUsed + ShmmAnon + DireAllocate + ZramUsed + IOFastUsed + IonTotalUsed
         + GpuTotalUsed + DmaHeapThirdTotalUsed + CmaUsed + RsvTotalUsed + Unevictable
         + HhpFree ± ε(±24)

B. 归因拆解公式（iOS 维度 ↔ 鸿蒙计数器，空闲快照实测，MiB）

C. 相机 A/B（关→开，与 iOS 相机场景同构的签名）

签名与 iOS 完全同构：相机 App 自身只涨 40 MiB，真实成本 ~1.6-1.7 GB 全在驱动池（ION/DmaHeap +1,689，其中 1,467 来自池缓存转化而非新增 DDR——这正是 MemAvailable 恰好只跌 1,550≈一个池的量的原因；free/文件缓存/匿名纹丝不动）。鸿蒙版"fp×wire 重复"是双账本重复：闭合超额 +3,223 = ① ION×IOFast 同批页两账本各记一次(~1,761，内核自身只把其中一个计入不可回收——MemAvailable 幅度独立证明) + ② 驱动池缓存转化×文件回填(~1,462，IonTotalCache 排空 −1,467 而 Cached 净不变 +5，说明转化页与新写入文件页等量对冲)。公式在相机态需两条卫生行去重，空闲态两者皆 0。

口径注意：① IonTotalUsed−DmaHeapTotalUsed=375.9 恒定（同一池的两个 API 视图）；② IOFastTotal==UDrvTotal==DevhostRsvPagesSize≈2.9 GB（设备主机保留区三个名字一个池）；③ Pss_HHP(每进程换出归因)存在但其与 ZramUsed/SwapUsed 的精确关系在 1.13 未定，公式 v1 采用"驻留归因+换出整行"的保守口径；④ 相机态闭合超额的分解(1,761/1,462)由池差分推得，颗粒度计数器未暴露。