外观
iOS 网络与 I/O 总览：Process/Device 分离与源时钟边界
先看结论
- Process Network 与 Device Network 是不同 source、不同窗口切分逻辑，禁止相减。 不能用 Device Rx 减去 Process Rx 推导"其他后台消耗了多少流量"。
- Debug Gauge 字节数是真实 Socket 层进出流量，不是 HTTP Body 净载荷，两者差异没有稳定的固定百分比，不应引用任何具体比例数字。
- 高 Disk I/O 与卡顿同窗出现只能提示相关性，不能证明 I/O 发生在主线程，需要结合调用栈或 Instruments 证据。
- 背景持续网络流量也可能是合法场景（后台传输、音频、VoIP 等），必须结合 App 能力声明与测试脚本判断，不能一律当作缺陷。
图：速率必须使用与计数器同语义的 source time 做差分；Mac 侧 receive time 不能替代 source clock。
0. 当前实现摘要
网络领域有两个独立的 source：设备级 com.apple.instruments.server.services.networking（pymobiledevice3 原生 NetworkMonitor）与进程级 com.apple.xcode.debug-gauge-data-providers.NetworkStatistics（Perfowl 自研深度适配层 pmd3_deep_services.py::ProcessNetworkStatistics）。磁盘 I/O 则与 CPU 领域共享同一个 sysmontap 通道。三者虽然都落在"网络与 I/O"这个业务话题下，但底层事实源完全不同。
1. 这个领域到底观察什么
回答“目标 App 自身网络字节速率如何、设备整机网络环境是否干净、目标 App 的进程级磁盘/文件 I/O 字节速率如何”。不直接回答“具体是哪个网络请求、哪个文件，或 NAND 闪存物理吞吐是多少”——那需要抓包工具、文件级追踪或 Instruments 证据。
2. iOS 系统原理
- 网络：Process Network 使用 Debug Gauge
NetworkStatistics的 source-native 增量字节字段；它不是 HTTP Body 指标，具体协议层组成尚未被本项目独立验证； - 磁盘：sysmontap 暴露进程级累计读写字节 counter，Perfowl 对相邻样本做差分得到速率；该值描述进程 I/O 活动，不等价于 NAND 闪存的物理读写吞吐。
3. 本领域指标地图
| 指标 | metricID | scope | 回答什么问题 |
|---|---|---|---|
| Process Network Tx/Rx | ios.process.network.send_rate / receive_rate | process | 目标 App 自身收发了多少流量 |
| Device Network Tx/Rx | ios.device.network.send_rate / receive_rate | device | 设备整机网络环境是否干净 |
| Disk I/O Rate | ios.process.disk.read_rate / write_rate | process | 目标 App 进程级磁盘/文件 I/O 字节速率 |
4. Perfowl 当前怎样取得这些事实
Device Network 经 NetworkMonitor 累加 ConnectionUpdateEvent，按 host monotonic 窗口输出速率；Process Network 经 ProcessNetworkStatistics 按目标 PID 订阅，必须使用源端 NSDate 时钟而不是主机收包时刻做分母（详见 Network 采集技术演进与实验，有真实的 19 分钟源时钟异常案例）；Disk I/O 复用 CPU 领域的 sysmontap counter 差分逻辑。
5. Scope / Identity / Runtime Condition
- Process Network、Disk I/O 都是 process scope，经目标 PID 过滤；
- Device Network 是 device scope，包含系统服务与其他 App 的流量，不能单独归因到目标 App；
- 两个网络 scope 的窗口切分逻辑不同（Process 用源端时钟，Device 用 host monotonic 锚定 sysmontap 节奏），不能简单相减。
6. 指标应该怎样组合阅读
排查流量问题：先看 Process Network（App 自身是否有异常流量）→ 若怀疑环境噪声再看 Device Network 对照 → 需要理解是否阻塞主线程时结合 FrameTime 与调用栈。排查卡顿是否与 I/O 相关：看 Disk I/O 是否与 FrameTime 尖峰同窗，再结合 APP CPU 是否偏低（提示阻塞可能不是纯计算）。
7. 常见异常形态：观察 → 候选原因 → 交叉验证 → 不能确认
| 观察到的现象 | 候选原因（需交叉验证） | 下一步验证 | 不能确认的结论 |
|---|---|---|---|
| FrameTime 尖峰同窗伴随 Disk Read 尖峰，APP CPU 不高 | 主线程同步磁盘 I/O 等候选方向 | 结合调用栈/Instruments 确认是否发生在主线程 | 不能仅凭同窗相关性确诊"I/O 发生在主线程" |
| 静置待机时 Process Rx 持续出现周期性脉冲 | 未采用长连接的高频轮询、埋点失败重试等候选方向 | 抓包/代码审查确认具体来源；也需排除合法的心跳/推送保活 | 不能不加区分地把所有静置态流量都当作缺陷——某些场景（VoIP、音频、后台传输）的持续流量是合法的 |
| 反复滑动同一内容仍持续产生网络流量 | 缺乏本地缓存或缓存命中率低等候选方向 | 检查图片/数据缓存配置与 Cache-Control 头 | 不能仅凭流量数字判断具体是哪个缓存策略问题 |
| Device Rx 很高但 Process Rx 很低 | 系统服务或其他 App 的正常/异常活动 | 清理后台环境复测 | 不能直接断言"与被测 App 完全无关"，也不能相减计算"后台消耗多少" |
8. 连续性、质量、missing / 0 / warmup
- Process Network 首点为
warmup，源时钟缺失时降级为candidate-host-window（不与真机源时钟结论混合）； - Device Network 窗口切换（重连/新 epoch）时清空累计字节，不跨窗口拼接；
- Disk I/O 状态机与 CPU 领域的 counter 类指标一致（
warmup/counter-reset/invalid-window）； - 真实 0 收发/0 读写保留为数值 0，不与 missing 混淆。
9. 当前证据与平台覆盖
Process Network 的源时钟修正（source-interval-rate.candidate.v2）已有明确的真机异常发现与修正后复测证据（详见演进文章）；Device Network 与 Disk I/O 证据依附于跨指标联合采集会话，尚无独立专项 E4 批次。
10. 常见误区
- 用 Device 减 Process 计算"后台流量"；
- 引用任何"Socket 字节通常比 HTTP Body 高 X%"的固定比例；
- 把所有静置态网络流量都当作缺陷，而不考虑合法的后台场景；
- 把磁盘 I/O 与卡顿的同窗相关性当作确诊结论。
11. 指标 Canonical 与技术演进入口
12. 继续阅读
- 跨指标诊断与证据升级
- iOS CPU 与调度总览：Disk I/O 与 CPU 共享同一 sysmontap 通道
2026-10-03 当前保护口径
Process v3新增负字节/sign-bit表示域保护，Device v5来源完成秒桶、Disk/Scheduler设备钟修复分列；缺值不补零，分作用域候选值不当已校准物理带宽。新包两轮验证与保留的失败轮见非启动修复记录。
2026-10-03 R7：Device v6生产聚合改为1s定时关已有窗，无字节更新的metadata-only保持缺值，不用超时补0；迟到门不放宽。进程v3负增量/设备钟口径保持，详见设备网络。
2026-10-04 R9当前合同：Device v7新来源完成直接发表完整桶，sys无新桶不覆盖仍新鲜值；1.5s发表/2s显示门保持，CSV全部样本≥90%与wire来源窗口独立核对另验。无标记历史Raw仍旧调度，旧Session不回写。进程v3与设备钟I/O口径不变；参见当前合同，当前新包E4待验。
2026-10-04 R9当前状态：v7来源完成发表的E2回归/旧Raw兼容已通过，b109已公证覆盖安装；Mac再次锁屏、0新轮，两轮CSV全部样本≥90%与wire来源独立复核PENDING，物理校准仍candidate。结果与下一动作。
2026-10-05 G35 · 网络对照的时钟前置
G34进程累计v4和严格身份已在b121验证安装，旧v3录制不变。下一独立流量对照需要先证明native Cocoa NSDate、设备mach参考与host抓包UTC各自的边界。G35在自有Fixture加默认关闭50Hz有界双钟读界，并提供无插值候选括号（E2），尚未部署到目标设备，也未完成host↔device同钟校准。仅把Cocoa加Unix纪元常数或按host收到时间配窗，均不足以关闭这项前置。TCP4/8正文证据和native累计积分不是协议字节定义/全流量精度通过；全54独立精度/五轮100%仍pending。G35。
2026-10-06 G57 · 部署与运行时钟验收分开
含双钟参考及逐API读取区间的新自有参考50.1.0已在原设备A单次覆盖升级。证据只有OS完成/安装元数据与旧文件名保留，尚无新运行记录或host↔device同钟校准；上方G35“尚未部署”是历史阶段而非当前。签名包或部署成功不证明源采样窗口、wire作用域、进程归属或数值准确，不能按host接收时刻拼同窗。完整54独立误差和固定五轮100%门保持。G57安装与下一阶段。