相机内存拆解: 阶段 × 业务 × 利用率
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)
721 vs 1139ms
M3 首帧 iOS vs OHOS (同协议 idle; 双方大波都在 M3 前完成)
+1305MB
OHOS M3 前 ION (69% — 与 iOS 的 68% 同比例)
5.20GB/s
OHOS 主突发峰值 (50ms 实测, 与 iOS 差 2.7×; 740ms 口径曾低估为 1.49)
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 |
启动窗口 (T0→+2.5s) · wired(IOKit) / mediaserverd / Camera app · fpwatch 50ms 实测
释放窗口 (killall@+26s) · 全量快放
⚠ 勘误 (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: 阶段拆解 (新机 16GB 变体, 对齐 iOS 协议)
新连设备 = 同型号不同机器 (序列 018566257M003177, MemTotal 15.1GB vs 旧机 11.2GB)。ohfpwatch (设备侧 C 采样器, SDK clang 交叉编译, 无 shell fork 开销): 50ms 采样 908 拍 (meminfo+vmstat+5 进程 RSS) + 1.5s dmabuf 快照 + hilog 毫秒锚点; T0 = aa start 请求。锚点: +753ms OpenCamera begin → +1032ms 首Pool (hilog, VIDHANCE_EISAUTO/WarpBuf) → +1446ms M3 isFirstFrame=1 → +7816ms LoadFirstFrameHebc。M3 轮间方差 1139/1280/1446ms (三轮)。本节数字全部来自同一轮 (staged3), 曲线/锚点/业务自洽。
| OHOS 阶段 (新机 idle, 50ms) | 时刻 | ΔION | 说明 |
|---|
| ① 孵化 | 0→0.75s | ≈0 (196→110 回落) | app spawn (T1=0.60s), daemon 待命 |
| ② 主突发 A | 0.78→1.11s | +1075MB | 峰值 5.20GB/s (首拍 +290MB/54ms), 均值 3.3GB/s |
| ③ 间隙 | 1.11→1.36s | +66MB | 喘息 250ms |
| ④ 突发 B | 1.36→1.61s | +465MB | 跨 M3 (M3=1.446s, 落在 B 中段) |
| ⑤ 突发 C | 1.86→2.01s | +248MB | 深管线补池 (稳态存留仅 +75MB, 多为过渡缓冲) |
| ⑥ 收敛 | →2.5s | +30MB | ION 平台 2007MB, dmabuf 1581MB |
| ⑦ 迟到重构 | +7.8~8.4s | +375/−392 | LoadFirstFrameHebc: 拆初始 scouting 池 (旧NORMAL_SOURCE.8 223MB 等 −392) → 建 AI/后处理栈 (Ppraw/VidHanceFake/SmartIsp包/ARSR +375); ION 瞬时 2280→稳态 1979 |
| post 退出 | +24s kill | 回 112MB 地板 | dmabuf 残留 87MB ≈ 轮前基线 85MB → 增量 100% 释放, MA 回升, cache 回填 +2.6GB |
| 进程 (MB) | 基线 | 峰值 | 稳态 | 对照 iOS |
|---|
| CameraDaemon | 184 | 337 (+153) | 310 | mediaserverd 48→582 (含管线对象) |
| 相机 app (ArkTS) | — (首采 +835ms 即 260) | 260 | 259 | Camera app 仅 27MB (10×差) |
| hiaiserver (NPU) | 18 | 34 | 19 | AI 权重在 msd wired 内 |
| camera_service | 21 | 29 | 29 | — |
| allocator_host | 5 | 6 | 6 (dmabuf 在别处计) | — |
启动窗口 (T0→+3.5s) · ION used / MemAvailable · 50ms 采样 · 新机 16GB
全窗 (0→46s) · 迟到波 (+7.8s Hebc) 与释放 (kill@+24s)
50ms 精度改写了 740ms 口径的"单一大波"叙事——实为突发序列, 且峰值被低估 3.5×。主突发 A (+1075MB/330ms, 峰值 5.20GB/s) 在 M3 前 336ms 完成 (与 iOS 波提前 176ms 同构); 突发 B (+465MB) 跨 M3——首帧并不等全部建池完成, 只等主突发 A; 突发 C (+248MB) 多为过渡缓冲; +7.8s Hebc 迟到重构 (拆初始 scouting 池 −392 → 建 AI/后处理栈 +375, ION 瞬时 2280→稳态 1979)。M3 前 ION +1305MB (69%, 与 iOS 的 68% 几乎同比例); M3 时刻 dmabuf 已建 ≈1.3GB/1.55GB (85%)。供给: ION cache 驱逐 −1.4GB"过路资金" + MA −1.25GB。
业务时间线 (SNAP 1.5s + hilog join, 单快照口径): 稳态相机系 dmabuf 1552MB/277 池 (峰值 1581@3.1s, 无过冲)。归属: 1.56s SNAP 已在 1113MB (72%) — movingPhoto 136 (allocator 代持) / NULL 134 / DynamicMap1+2 178 / SMARTISP_MODEL_FRAME 60 / AiCompositionModel 38 / VIDHANCE_EISAUTO 40 / HDC_PREVIEWSurface 34 / "1758" 62; 3.08s 新增 75MB; 迟到重构 364MB@9.27s — 新 NORMAL_SOURCE.8 106 (池 id 变更! 0x100028c→0x10002e2) / ipp_sve_mem 55 / Ppraw 33 / VidHanceFakePreview 32 / SmartIsp AI 包 / ARSR 20。hilog join (54 池有 ms 级分配记录, 24 池存活可归因): 首Pool 1032ms (VIDHANCE_EISAUTO+WarpBuf, 突发 A 尾部); 主突发 A/B 走无日志直配路径; 迟到波 7835~8365ms 与 LoadFirstFrameHebc 对齐。
利用率: 稳态 dmabuf 1552MB (vs 旧机 12GB 的 1231MB, 仅 1.26×——变体内存大不代表相机池等比加深) / ION used 1979MB (dmabuf↔ION 差 ~430MB 内部池); daemon RSS 337→310 (无过冲); ION 瞬时峰 2280 (Hebc 重构) vs 稳态 1979 (+15% 过渡过冲); 退出后 ION 回 112MB 地板、dmabuf 残留 87MB ≈ 轮前基线 (增量 100% 释放); ION cache 1.9GB→0.2GB (借走) →2.6GB (回填)。
诚实清单: 本节曾把多 SNAP 累加误当稳态 (4616MB 实为 1552×3 拍) 且业务归因误用了上一轮数据——本轮已全量重算并同轮自洽 (曲线/锚点/业务均出自 staged3-105835); 740ms 口径曾把波速报为 1.49GB/s——50ms 实测峰值 5.20GB/s (分辨率教训); M3 轮间方差 ±150ms (1139/1280/1446); app RSS 首采 +835ms 即 260MB (0→260 增长在发现间隙内); v1 轮设备缺 tr 致 RSS 全灭; v2 轮 app pid 被 aa start 命令行竞态劫持 (尾锚+验活修复); pgfault 计数在本机 /proc/vmstat 恒 0 (无 faults 佐证, 只能靠 ION 曲线); dmabuf 快照 1.5s 节奏, 毫秒级业务时间靠 hilog join (只覆盖存活池)。
三、OHOS (旧机 12GB): 业务分布 (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 层不可归因。
四、跨平台对齐 (iOS 12Pro vs OHOS 新机, 同协议 idle 实测)
| 维度 | iPhone 12 Pro (iOS 14.8) | Mate 80 Pro (HarmonyOS 7) |
|---|
| M3 首帧 | 721ms (app 自报 446ms, C5 一致) | 1139ms (新机 idle, isFirstFrame=1) |
| M3 首帧前构建量 | ≈1.06GB (wired 818+msd 215+app 27; 大波提前 176ms 完成) | ION +1506MB (85%) (大波提前 ~140ms 完成) |
| M3 后构建量 | ≈0.50GB (AI/深管线, 至 2.1s) | ≈0.58GB (burst B尾/C) + 迟到波 0.36GB@7.8s |
| 大波速率 | ~14GB/s (793MB/55ms, faults Δ13653) | 主突发 A 峰值 5.20GB/s (+290MB/54ms), 均值 3.3 (2.7×差) |
| 大波供给 | free 直付 (free 2.8GB≫需求, 压缩Δ=0) | ION cache 驱逐 −1411MB (过路资金) + MA −1.15GB |
| 首帧等大波? | 是 (波完成→176ms→M3) | 等主突发 A (提前 336ms); B 段跨 M3, 首帧不等全部 |
| 进程拓扑 | Camera app 27MB (壳) + mediaserverd 48→582MB | app 259MB (ArkTS runtime 在进程内, 10×) + daemon RSS 310 + ION 1980 |
| AI/模型内存 | ANE 模型 wired +185MB 于二波 (M3 后 1.18~1.55s) | AiCompositionModel 38MB (主层) + SmartIsp AI 包/ARSR (迟到重构 7.8s) |
| 图像源池 | ISP 池 13 个 (预填 23~93%, 按需补) | NORMAL_SOURCE.8 106MB + DynamicMap 178MB (新机; 旧机 307MB) |
| 峰值 vs 稳态 | wired 回落 2% (无过冲) | daemon RSS 324→308 (无过冲) |
| 退出释放率 | 100% (500ms 内 wire −848MB) | 100% 增量 (ION 回 112MB 地板, 残留 87≈轮前基线 85) |
| 跨启动预热 | 无 (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 池) |
| 细粒度阶段 | 已测 (fpwatch 50ms) | 已测 (ohfpwatch 50ms, 908 拍) |
| wired 语义 | IOKit wired 代理 (mlock 类比已校准) | — |
| 失败记录 | 熄屏锁拒启(code=7)已重跑; camwatch 2s 偏移已勘误 | 新机缺 tr (v1 RSS 全灭); aa start pid 竞态 (v2 劫持, v3 尾锚修复) |
| 已知盲区 | iOS 无 per-buffer 审计 (池消息只有初始下发) | dmabuf↔ION 差 615MB 内核池不可归因; 池内 touch 率不可测 |
数据归档: ios/staged/staged2-103948 (fpwatch) · ohos/staged/staged3-105835 (50ms) · ohos/C5/tp2 (旧机) · 分析器 analyze_ohos_staged.py / analyze_staged_buf.py · 生成器 build_mem_site.py