外观
Virtual Memory（进程虚拟地址空间映射规模）
当前采集源（2026-10-11 G440/G441）：使用pymobiledevice3原生DeviceInfo/Sysmontap，经DTX 主连接采集完整依赖列；实际请求虚拟内存且发表间隔500ms时，复用最多两个连接，在补充连接使用真实memVirtualSize列及独立原生窗口去重。补充schema为4/5/5/6列，按是否同时请求物理/驻留内存选择；不新增第三连接，不借CPU/驻留内存的值或token补虚拟内存。原始bytes公式未变，独立6-entry FIFO、单次token与TTL=3×实际interval拒绝旧值续点。当前签名162已唯一覆盖安装，软件验证不等于正式五轮或独立校准。源方案与验证 · 包核验。
作用域属性：[进程级 · 目标专属]（Process Scope ） Memory Contract：memory-contract.v2
1. 定义与业务价值
Virtual Memory 描述目标进程的虚拟地址空间映射规模，包括预留地址区间、内存映射文件、共享库等。它不等于实际消耗的物理 RAM：一个 64 位进程的 Virtual Memory 达到数百 GiB 是正常现象，不天然意味着采集错误或真实内存问题。
2. metricID / scope / unit / source
| 字段 | 值 |
|---|---|
| metricID | ios.process.memory.virtual |
| scope | process |
| unit | bytes |
| source | dvt.sysmontap |
| sourceKey | Processes[targetPID].memVirtualSize |
| definitionVersion | raw-gauge.v1 |
取自当前 Registry 。
3. iOS 系统原理
64 位进程的虚拟地址空间远大于物理内存容量；地址预留、mmap 映射的文件、动态库加载等都会占用地址空间而不实际消耗等量物理页。memVirtualSize 反映的是地址空间层面的规模，不是物理内存消耗层面的规模。
4. 系统服务 / 通信通道 / 采集命令与实现
通道：com.apple.instruments.server.services.sysmontap（DTX）。采集：pymobiledevice3 原生 Sysmontap(provider, process_attributes, system_attributes, interval_ms=intervalMs) 返回的进程条目字段；实现于 metric_engine.py::_process_metrics。
5. 原始字段与字段语义
Processes[targetPID].memVirtualSize：sysmontap 上报的目标进程虚拟地址空间映射规模，单位字节。
6. 精确公式
text
VirtualMemoryBytes = Processes[targetPID].memVirtualSize（原样保留）例如 Memory = 200 MiB、Real = 250 MiB、Virtual = 300~500 GiB 三者同时成立并不自相矛盾——它们回答完全不同的问题。
7. Clock / Window / Freshness
Gauge 类型。G440实现独立单次来源发布：6-entry FIFO、TTL=3×实际interval、每token仅一次；旧161仍为通用scalar缓存，本修复已通过软件控制/完整native回归，实际五轮已按v5完成范围内验收，不把snapshot时刻当内核读取时刻。
8. Baseline / Reset / Discontinuity
无 counter 语义，无前值依赖。
9. Quality：valid / candidate / missing
G440批准的准入：字段缺失、≤0、非有限、bool、旧值/过期/重复事件→null / missing ；身份未验证或绑定不符→null / identity-unverified（缺原值可missing）。真实新鲜正值→candidate。数百GiB不按物理RAM裁剪。本条已实现并通过软件验证，实际阶段验收状态见下段。
10. 合法 0 的条件
不存在合法的 0 值。
11. 当前证据、校准与平台覆盖
2026-10-11当前：已按v5异常筛查门完成第四项阶段交付，整体4/54。正常162五个全新Session各240/240新鲜有效、120/120完整槽、240/240正常包络，gap0.5秒，来源违规/偏离/严重/不可评估0，15工程和已交付前三保护通过；原Raw→真实发表token/bytes与完整参考已复核封存。仅该设备/目标/负载范围，不保证所有App持续零缺失。独立精度/calibrated仍false；数百GiB不按物理RAM限制。阶段证据。
12. 如何分析：能得到什么结论，不能得到什么结论
能得到：目标进程地址空间的规模趋势，通常在诊断内存问题时作为 Footprint/Real 的补充背景信息，而不是主要判据。
不能得到：不能把 Virtual Memory 的绝对数值大小直接解读为"内存问题"或"泄漏"——它主要受地址空间预留、共享库/文件映射策略影响，与实际物理内存压力不是同一维度。
13. 常见误区
- 把 Virtual 数百 GiB 当作异常数据或采集错误；
- 把 Virtual 增长直接等同于物理内存增长。
14. Legacy / 历史实现
无历史候选版本记录；实现自初始版本起即为直读映射。
15. 版本历史与来源批次
本页由 site/knowledge/metrics/memory-metrics.md v5（2026-09-15）拆分而来。
| 版本 | 日期 | 修订要点 |
|---|---|---|
| v1（本页） | 2026-09-18 | 从 memory-metrics.md 拆出，成为 Virtual Memory 独立 Canonical。 |
采集源版本更新 · 2026-10-07
G84将SDK全列factory改为固定共享11+3列、输出与采样节拍一致；原生服务/DTX通道不变，支持列仍由SDK查询，传输及指标转换为Perfowl适配层，SDK来源和自研计算分开。初missing、counter warmup/reset、VM近似质量等原边界保留，不外推其他设备/场景持续100%。来源批次。
基础内存独立观察预检 · 2026-10-07（G131）
G131基础内存3字段同life预检：254个源点中virtual254/254观察范围数值相容，footprint245/254、resident247/254；均Raw→当前engine差0，但旧126/1Hz参考/原生read语义不充当前130五轮验收。 独立原生API括号与源native窗口不自动同刻，1Hz的未观察时刻不是有界真值，不新增校准或改公式。Virtual数百GiB是映射地址空间，不等物理RAM；优先Virtual新same-life资格不替代physical/real验收。来源。
版本更新 · 2026-10-11 G456
virtual-memory-source-freshness.v1与independent-virtual-connection.v1原bytes公式不变，固定五新轮/完整封存后按最新异常筛查门验收；未独立精度校准。来源见阶段证据。