相机内存拆解: 阶段 × 业务 × 利用率
iPhone 12 Pro (iOS 14.8, 越狱) vs HUAWEI Mate 80 Pro (HarmonyOS 7) · 实测 2026-10-13/14 ·
配套:
启动速率主报告 ·
轻重载与申请效率专页
+1.06GB
iOS M3 首帧前完成构建 (721ms 内, wired 818+msd 215+app 27)
~14GB/s
iOS 大波速率 (793MB wired / 55ms, faults Δ13653)
721ms
iOS M3 首帧 (自报 446ms, 与 C5 基线一致); 大波在其前 176ms 完成
1231MB
OHOS 相机 dmabuf 急建量 (195 池, +12s 完成)
170MB/s
OHOS 建池速率 (MA 曲线, 与 iOS 差 12×)
100%
双方退出释放率 (无跨启动预分配, 再证 lifecycle)
一、iOS: 阶段拆解 (idle 冷启动, fpwatch 50ms 修正轮)
fpwatch (compare/tooling/fpwatch.c): 每采样重扫进程表 (Camera pid +110ms 即被捕获, 无发现延迟), 系统页计数 + faults/zero-fill 活动计数器, 绝对 wall 时间对齐; syslog 毫秒锚点。锚点链: +189 FrontBoard 受理 → +214 M1 spawn → +216 msd 客户端注册 → +711 首帧交付 → +721 M3 "Preview started" (app 自报 0.446s, 与 C5 基线 446ms 完全一致) → +902 UI 动画完成。
| iOS 阶段 (idle 冷启动) | 时刻 | Δwired (IOKit) | Δmsd_fp | Δcam_fp | 业务 |
|---|
| ① T0→spawn | 0→214ms | 0 | +1MB | +19MB | FrontBoard 受理+孵化, 框架装载 |
| ② msd 管线建立 | 214→273ms | 0 | +198MB | 0 | HNISP 客户端注册+管线对象 |
| ③ 蓄势 | 273→490ms | 0 | +11MB | +2MB | 属性探测/建流配置 |
| ④ 大波 | 490→545ms | +793MB | +1MB | 0 | IOKit/ISP 缓冲池 wired (~14GB/s, faults Δ13653) |
| ⑤ 首波下发→M3 首帧 | 545→721ms | +25MB | +5MB | +5MB | 6 池初始缓冲下发固件→首帧交付+Preview started |
| ⑥ M3→二波前 | 721→1182ms | 0 | +120MB | 0 | UI 动画完成, 深管线启动 |
| ⑦ 二波 (AI/深管线) | 1182→1554ms | +185MB | +190MB | 0 | ANE/AI 模型+深管线池 (二波 7 池下发) |
| ⑧ 尾部收敛 | 1554→2105ms | −22MB | +11MB | 0 | 稳态: 2.1s 起全平 |
| post 退出 | +26s killall | −848MB (500ms内) | 588→51MB | 0 | 全量快放, free +1.2GB |
| 聚合窗口 | wired | msd_fp | Camera app | 合计 |
|---|
| M3 前 (T0→721ms) | +818MB | +215MB | +27MB | ≈ +1.06GB |
| M3 后 (721ms→2.1s) | +163MB | +319MB | 0 | ≈ +0.50GB |
| 全程 | +998MB | +554MB | +27MB | ≈ 1.56GB |
⚠ 勘误 (2026-10-14): 本页首版曾发布"首帧轻装 <5MB / 大头全在首帧后"的结论——那是分析错误: 上一轮 camwatch 在 T0 前 2s 启动, 其相对时间 t=0 被误当 T0, 全部"阶段窗"实际落在发射前, 采到的是发射前的平静段。fpwatch 修正轮 (绝对时间对齐) 推翻该结论。正确结论见上表: 大头 (~2/3, ≈1.06GB) 在首帧前急建。两工具在修正 2s 偏移后波形一致 (大波均在 T0+0~0.5s)。
池业务: 初始缓冲下发 (固件池)
| 下发波 | poolID | 初始下发/poolSize | 预填率 |
|---|
| +584ms (主通道, 首帧前) | 0 / 2 / 1 / 8 | 16/24, 10/18, 3/13, 13/14 | 67% / 56% / 23% / 93% |
| +662ms (次通道) | 170 / 173 | 16/27, 10/15 | 59% / 67% |
| +1150~1279ms (二通道, 首帧后) | 136/138/137/144/34/36/42 | 16/28, 10/22, 3/13, 13/14, 16/23, 10/17, 13/14 | 57%~23% |
结构发现: 前装直付 (front-loaded & instant)。启动窗口 (T0→M3 721ms) 内完成 ≈1.06GB 构建: 顺序是 app 框架 (+19MB) → msd 管线对象 (+198MB) → IOKit/ISP 池 wired 大波 +793MB → 首波 6 池下发固件 → 首帧。"启动 <1s"与"1.6GB 内存构建"自洽的原因不是需求少, 而是申请瞬时: idle 供给分层下 (free 2.8GB ≫ 793MB), 大波 55ms 内完成 (~14GB/s, faults Δ13653 印证页触碰), 内核态 wiring 比用户态 mmap+mlock 直付 (5~6GB/s) 还快。M3 后仅剩 AI/深管线 ≈0.5GB (二波)。
进程拓扑: Camera app 本体 27MB (UI 壳), 相机管线全住 mediaserverd (48→582MB, 无跨启动预热)。
利用率: 峰值≈稳态 (2.1s 后全平, 无过冲); 退出 killall 后 500ms 内 wire −848MB / msd 588→51MB (全量快放); 池预填率 23~93% (initial send/poolSize, 其余按需补)。
与 C5/L7 互证: 重载 p3 同样的前装需求 M3 仅 +75ms——文件页捐赠路径 (L0 分层) 快; L7 "分批不提速"结论不变——瞬时性来自供给分层, 与分批无关。
二、OHOS: 业务分布 (dmabuf 四相审计)
/sys/kernel/debug/dma_buf/bufinfo 全表快照 ×4 相位 (pre/steady+12s/late+45s/post)。相机归属 = CameraDaemon 全部 + hiaiserver 全部 + allocator_host 增量 (排除系统常驻数字 tag)。
| OHOS 业务组 (steady) | 池数 | buffers | MB | 占比 |
|---|
| ① 图像源流水线 NORMAL_SOURCE | 100 | — | 307.1 | 24% |
| ② 动态映射缓冲 (对齐/畸变) | 2 | 2 | 178.0 | 14% |
| ④ SmartISP 共享内存/工作区 | 136 | — | 169.6 | 13% |
| ⑨ 未标记 (daemon 内部) | 117 | — | 108.8 | 8% |
| ⑩ 其他小池 | 222 | — | 102.3 | 8% |
| ③ AI 模型权重 (NPU .om) | 20 | — | 94.9 | 7% |
| ⑥ 拍照后处理/XStyle | 69 | — | 86.5 | 7% |
| ⑧ RAW/MSC 处理 | 13 | — | 85.4 | 6% |
| ⑤ 显示/预览通路 | 22 | — | 52.8 | 4% |
| ⑦ VIDHANCE 防抖 | 20 | — | 45.9 | 3% |
| OHOS 相位 | CameraDaemon | allocator_host (代持) | hiaiserver (NPU) | 说明 |
|---|
| pre (相机关) | 0 | 137.8MB (系统常驻) | 0 | floor |
| steady (+12s) | 972.8MB | 223.9MB (+86 相机) | 172.4MB | 急建完成, 合计 ~1231MB |
| late (+45s) | 972.8MB (平) | 223.9MB (平) | 181.8MB (+9.4) | 仅 NPU 模型延迟加载 |
| post (退出+8s) | 0 | 140.3MB (≈pre) | 0 | 100% 释放 |
相位事实: pre 全零 → steady 全量 (启动窗口内急建 100%) → late 几乎零增长 (仅 hiaiserver NPU 模型 +9.4MB 延迟加载) → post 全释放。NORMAL_SOURCE 池深 8~20 buffers。dmabuf 视角 1231MB vs ION 物理 1846MB——~615MB 在内核内部 ION 池, dmabuf 层不可归因。
三、跨平台对齐
| 维度 | iPhone 12 Pro (iOS 14.8) | Mate 80 Pro (HarmonyOS 7) |
|---|
| M3 首帧前构建量 | ≈1.06GB (大波 793MB 在 M3 前 176ms 完成) | 压力轮证据: 大头在首帧后 +2.5~12s (1613MB, MA 曲线); idle 细阶段待测 |
| M3 后构建量 | ≈0.50GB (AI 模型/深管线, 至 2.1s 收敛) | idle 细阶段待测 (重载被排队拉长, 不能直接当 idle 时序) |
| 建池速率 | ~14GB/s (大波 55ms) | ~170MB/s (压力轮 MA 曲线, 差 ~80×; idle 待测) |
| 进程拓扑 | Camera app 25MB (壳) + mediaserverd 48→746MB | CameraDaemon 973MB + allocator 86 + hiaiserver 172 |
| AI/模型内存 | ANE 模型 wired +751MB (73% 大头), 首帧后加载 | AI 权重 94.9MB (.om) + hiaiserver 172MB, late 再 +9.4 |
| 图像源池 | ISP 池 13 个 (预填 23~72%, 按需补) | NORMAL_SOURCE 307MB (池深 8~20 buffers) |
| 峰值 vs 稳态 | 1679→1645 (回落 2%, 无过冲) | steady→late 持平 (仅 NPU +9.4) |
| 退出释放率 | 100% (wired/msd 全回地板) | 100% (dmabuf 全释放, 再次印证) |
| 跨启动预热 | 无 (msd 48MB 地板起步) | 无 (ION 176MB 地板起步) |
与 L7 (分批 vs 一次性) 互证: iOS 大头 (793MB 大波) 在首帧前完成且瞬时 (~14GB/s)——瞬时性来自供给分层直付 (L0 headroom/文件页捐赠, 压缩Δ=0), 与"分批"无关 (L7 已证 JIT 回收下分批零收益)。重载 p3 下同样前装需求 M3 仅 +75ms (捐赠路径快)。两平台真正差异: ① idle 建池速率 ~14GB/s vs 重载 OHOS ~170MB/s; ② 重载下 OHOS 首帧路径的分配排队 (59~62MB/s 有效追赶), iOS 分层直付。
对 C5 表述的修正: "p3 wired +1058MB → 首帧 +14%" 的因果已重写——那 +1GB 在首帧后, +75ms 罚金来自孵化/初始小缓冲的轻度挤压, 不是大分配挤占。
四、方法论与诚实清单
| 项 | iOS | OHOS |
|---|
| 采样 | fpwatch 50ms (页计数+faults 计数+双进程 fp; 首版 camwatch 有 2s 时间偏移分析错误, 已勘误) | bufinfo 四相快照 (per-buffer) |
| 锚点 | syslog 毫秒 (HNISP/ANE/CMSession) | hilog 秒级 (粗) |
| 业务标签 | syslog 池消息 (poolID/count/size) | dmabuf usage tag (195 池) |
| 细粒度阶段 | 已测 (本轮 100ms) | 4 相位粗粒度; 400ms 高频轮已备 (staged_bufaudit.sh), 待设备重连 |
| wired 语义 | IOKit wired 代理 (mlock 类比已校准) | — |
| 失败记录 | 前轮熄屏锁 FrontBoard 拒启 (code=7), 解锁重跑 | 设备 USB 断连, 细阶段轮待重连 |
| 已知盲区 | iOS 无 per-buffer 审计 (池消息只有初始下发) | dmabuf↔ION 差 615MB 内核池不可归因; 池内 touch 率不可测 |
数据归档: compare/data/ios/staged/staged-100630/ · compare/data/ohos/C5/tp2/ · 分析器 compare/tooling/analyze_staged_buf.py · 生成器 compare/tooling/build_mem_site.py