iOS 与鸿蒙系统相机启动·内存对比实测

一句话结论

549 ms

iOS 冷启动 → 取景器首帧 [534~570]

801 ms

鸿蒙冷启动 → 取景器首帧 [749~810]

+993 MB

iOS 内核 wired 增长 (相机期)

+1585 MB

鸿蒙 ION/dmabuf 池增长 (CameraDaemon 导出 1318MB)

冷启动到首帧 iOS 快 ~250ms (统一到系统受理起点后 ~150ms); 暖恢复加速比两平台几乎相同 (-19%/-22%)。 相机内存的大头在内核缓冲池, 进程记账 (RSS/PSS/fp) 只覆盖 30~40%: iOS 进程 604MB + wired 993MB ≈ 1.0GB; 鸿蒙进程 317MB + ION 1585MB ≈ 1.9GB (含 50MP 级 AI ISP 管线, 硬件规格主导)。两平台关闭相机后内核池均全量归还。

1 · 启动时间分解

指标	iOS (n=5)	鸿蒙 (n=5)	口径
T0 → 系统服务受理	2 [1~36]	107 [107~111]	iOS: SB 收 open 请求; 鸿蒙: AMS StartAbility
T0 → 应用进程诞生	29 [24~57]	198 [190~210]	iOS: tracking; 鸿蒙: stat starttime (fork)
T0 → 前台	657 [648~688]	336 [327~350]	语义不同: 转场完成 ≠ ability 前台
T0 → 取景器首帧	549 [534~570]	801 [749~810]	本报告头条指标
暖恢复 T0w → 首帧 (n=2)	444 [440~449]	626 [617~634]	后台 → 前台重启管线

iOS 冷启动 → 首帧

549 ms

鸿蒙冷启动 → 首帧

801 ms

iOS 暖恢复 → 首帧

444 ms

鸿蒙暖恢复 → 首帧

626 ms

⚠️ 口径: iOS T0 = launchcam 触发 uiopen (XPC 直达, 2ms 到 SB); 鸿蒙 T0 = 探针 spawn aa (fork+exec+IPC, 107ms 到 AMS)。鸿蒙"冷启动"走 HyperSnap 快照路径 (真全冷更慢, 偏差利好鸿蒙); 鸿蒙冷 SoC 首轮 1073ms (DVFS +270ms)。iOS 全部 5 轮无 buffer 池饥饿。

1A · 启动差异下钻 (hitrace + hiperf + iOS syslog, t3 轮)

阶段	iOS	鸿蒙	差
T0 → 系统受理	2ms (XPC 常驻)	107ms (aa fork+exec+IPC)	+105
T0 → 应用进程诞生	29ms	198ms (含上述受理)	+169 (67%)
进程诞生 → 首帧	~520ms	~603ms	+83 (33%)
合计	549ms	801ms	+252

孵化路径差 (+169ms, 占总差距 67%) 是主因——aa 二进制 fork+exec+IPC 要 107ms 才到 AMS, iOS 常驻 XPC 2ms 受理。trace 开销 ~5-10%, 本节用于机理分解而非计时基准。

双平台语义阶段梯子 (核心对比)

语义阶段	iOS (T0+)	鸿蒙 (T0+)	证据
系统受理	+2ms (XPC 常驻)	+107ms (aa fork+exec+IPC)	syslog SB 收据 / 探针 AMS
应用进程诞生	+29ms	+198ms	tracking / fork starttime
相机管线建立起点	+33ms [26~63] — 随应用诞生同步启动, 内联	≤fork — 预建: 与 spawn 并行甚至更早	syslog mediaserverd 首行 / trace SessionImpl
管线建立本体耗时	(内联在 spawn→首帧内)	~1s (OpenCamera span 1010ms / StreamCtrl 416ms) — 被预建掩盖, 不上首帧关键路径	trace B/E 区间
深度管线启动	+435ms [423~466]	预建内含	syslog
AI 初始化	+1153ms [1146~1194] — 首帧后 616ms!	预建内含 (SmartISP 模型常驻, 见 §3/§4)	syslog / bufinfo
相机帧到达应用	≈+549ms (Preview started 口径)	≈+330ms (reportOnFirstFrame, fork+132ms)	trace
首帧呈现 (M3)	+549ms	+801ms	主实验
转场完成 / 稳态 60fps	+657ms (anim1) / —	— / fork+~640ms	syslog / trace vsync

鸿蒙 fork→首帧 (~603ms) 内部构成 (trace span 线程栈配对实测)

span (启动窗口 1.2s)	次数	累计线程时间 ms	单次最大 ms	解读
daemon: HispSensorDevice::OpenCamera	1	1010.4	1010.4	传感器 bring-up (预建掩盖)
daemon: HispStreamCtrl::Configure	17	428.7	415.8	流配置一次 ~416ms (预建掩盖)
SourceTextModule::Evaluate (ArkTS 模块求值)	124	222.8	84.7	应用侧最大单项
UI: FlushDirtyNodeUpdate	17	30.5	22.3
daemon: SessionImpl::LoadRequest	18	23.3	2.3	会话装配
daemon: LoadAllFiltersRequest	18	16.3	2.0	会话装配
UI: FlushLayoutTask	16	14.7	12.2
UI: Measure	77	13.3	11.5
UI: OnSubmitUV	70	1.2	0.2
UI: MarshRSTransactionData	8	0.2	0.1
UI 布局/测量/提交合计		60		远小于 ArkTS 求值

即 fork→首帧 ~603ms ≈ ArkTS 求值 223ms + UI 布局测量 60ms + 运行时初始化/binder 等待/vsync 对齐 ~320ms; 相机侧 attach 仅 ~132ms。

三个机理发现

预建管线: CameraDaemon 的会话配置与传感器开启和 app spawn 并行甚至更早——应用 attach 后 ~130ms 即拿到首帧, daemon 侧 ~1s 的 bring-up 被完全掩盖。鸿蒙把"管线建立"从首帧关键路径上摘掉了。
ArkTS 启动风暴吃掉预建红利: 相机帧来得快(≈+330ms vs iOS ≈+549ms 口径), 但应用要跑完 124 次 ArkTS 模块求值(223ms 线程时间) + UI 构建, 首帧呈现仍晚 252ms。hiperf 实锤应用 CPU 98% 在 libark_jsruntime(60%)+stub(24%)+hilog(14%)。
AI 初始化策略镜像内存侧发现: iOS 把 ANEServices 推迟到首帧后 616ms(优先出画, 换取更瘦常驻缓冲); 鸿蒙把 SmartISP/AICOLOR/稳像全部预建常驻(即开即用, 代价是 1.55GB ION 池)——启动策略与内存策略是同一枚硬币的两面。

鸿蒙 fork→首帧时间线 (t3.trace, 相对 daemon 会话配置起点)

t (相对 daemon 会话配置起点)	事件
≤0 (文件起点前)	app 进程诞生; CameraDaemon 已在配置完整会话(LoadRequest/LoadAllFilters/HispStreamCtrl::Configure/SendSetPreviewCamera)
+17ms	app 开始 ArkTS 页面模块求值 (91 次, 含 photobrowser 库)
+50ms	传感器开启 HispSensorDevice::OpenCamera (早于 AppSpawn reply)
+63ms	AppSpawn reply 钩子
+132ms	CameraProxy::reportOnFirstFrame — 应用拿到第 1 帧 (fork 后仅 ~130ms, 管线预建红利)
+145ms	应用窗口首个 vsync
+~640ms	UI 构建风暴结束, 进入稳态 60fps (hilog isFirstFrame ≈ fork+603ms, 与主实验 801-198 吻合)

CPU 热点 (hiperf, 启动窗口)

进程	Top DSO (hw-cpu-cycles)	解读
相机应用	libark_jsruntime 60% / stub.an 24% / libhilog_inner 14%	启动 CPU 的 98% 是 ArkTS 引擎+日志, 非业务逻辑
CameraDaemon	libcamera_daemon 29% / hispeed_libcopt 16% / libffrt 8% / lib_camerabuffer 7% / libips_core 5% / libDytone 4.7% / libispenhnc 3.4%	管线建立本体: HAL+算法优化+协程+缓冲+ISP
render_service	(全局占比仅 1.6%)	显示/合成不是启动瓶颈

口径注记: iOS 侧无同源 trace 工具(xctrace 在 iOS 14.8 不可采), 分段来自 syslog 收据锚点(r1-r5 跨轮稳定);"reportOnFirstFrame"(客户端收帧)与 hilog "isFirstFrame"(预览呈现)是不同锚点; span 为线程时间非墙钟; t3 单轮, 与主实验锚点交叉吻合。

2 · 进程内存拆解 (C4 全进程差分, n=3)

角色	iOS 进程	iOS Δfp (MB)	鸿蒙进程	鸿蒙 ΔPSS (MB)
应用	Camera	23.9	com.huawei.hmos.camera	198.0
管线服务	mediaserverd (单体)	546.9	CameraDaemon + camera_service	110.4
合成/窗口	backboardd	31.6	render_service + sceneboard	6.0
编解码/媒体	无 mover	0	av_codec 等	0.7
相机栈合计		602.4		315.1

iOS 进程归因 (fp)

604 MB

iOS 内核 wired Δ

993 MB

鸿蒙进程归因 (PSS)

317 MB

鸿蒙 ION 池 Δ

1585 MB

构成分解 (口径分平台, 不可互比)

iOS: mediaserverd ΔIOKit/DMA 497.4MB (三轮一字不差) + internal 52.8; backboardd ΔIOKit 31.1; Camera app internal 18.0 + IOKit 5.9。iOS 相机栈 ≈89% 是 IOKit 映射。
鸿蒙: 应用 PSS 198 (Anon 135 + File 58 + HHP ~28) + Swap 77MB 被 zswap 换出; CameraDaemon Δ 全是 Anon; render_service/sceneboard ≈ 0 (对比 iOS backboardd +32MB 是最大架构反差)。
交叉验证: 鸿蒙 daemon ΔPSS 108.9 ↔ 主实验 ΔRSS 111.2; iOS msd 546.9 ↔ 550.6 — 两套独立方法互相印证。

指标	iOS (n=5)	鸿蒙 (n=5)
应用稳态	phys_footprint 24.9 MB	PSS 202.4 MB / RSS 256.0 MB (口径禁比)
应用峰值 (启动窗)	26.7 MB	RSS 257.5 MB
S-global 可用量回落	1329 [1323~1351]	1310 [1242~1402]
S-attributed 进程归因	576 → 604 (C4 含 backboardd)	316 → 317 (C4 PSS 级)
mediaserverd / CameraDaemon Δ	+551 MB	+111 MB (RSS) / +109 (PSS, C4)
关闭后服务残留	msd ≈0 (完全回落)	daemon +13~27 MB (Anon)

3 · 内核缓冲池 (复测修正: wired 与 ION/dmabuf)

层	iOS	鸿蒙	口径
进程归因	604 MB (24+547+32, ~89% IOKit 映射)	317 MB (198+109+~10)	fp / PSS
内核缓冲池	wired Δ +993 MB [985~995]	ION 池 Δ +1585 MB (CameraDaemon 导出 1318 + hiaiserver 172 + 显示表面 85)	系统计数器
与进程归因重叠	~534 MB (进程内 IOKit ⊂ wired)	≤228 MB (daemon RSS 内映射)	双计警示
系统可用量回落	1329 MB	1310 MB	各自定义, 量级可比

CameraDaemon 导出缓冲构成 (稳态, e1, 按名称聚合 Top8)

NULL

245 MB

BufferPool[0x1000824]_NORMAL_SOURCE.8

173 MB

PP:BASE_POOL

140 MB

ShareMemoryPool:MAP_TYPE_DYNAMIC_PREVIEW

115 MB

DynamicMapBuffer1

90 MB

DynamicMapBuffer2

88 MB

ShareMemoryPool:MAP_TYPE_SMARTISP_MODEL_FRAM

60 MB

BufferPool[0x1000823]_VIDHANCE_EISAUTO.8

40 MB

逐缓冲来源 /sys/kernel/debug/dma_buf/bufinfo (528 块): CameraDaemon 1325 + hiaiserver 172 (相机 AI 推理) + allocator_host 85 (显示表面) ≈ 1582MB, 与 ΔIonTotalUsed 1585MB 闭合。晚相(+45s) 无延迟爬坡; force-stop 后 8s ION 全量归零。Protected(530MB)/CmaUsed(231MB) 全程不动。

⚠️ 双计警示: 内核池与进程归因有重叠 (iOS 进程 IOKit ~534MB ⊂ wired; 鸿蒙 daemon RSS ≤228MB ⊂ 部分映射)。全栈总量禁止两层简单相加, 以"系统可用量回落"为总口径。

3A · 内存重载场景 (C5: 施压下的冷启动与内存构成, n=1/档)

两平台同源施压工具 (mem_stress -R 随机不可压缩 + -k 8 重触), 档位按剩余可用量对齐; 测量块与主实验同源。协议与安全边界详见报告 §4C。

档位	iOS avail/6GB	iOS 首帧	鸿蒙 MA/11.7GB	鸿蒙首帧
基线(n=5)	~3.0GB	549ms [534~570]	~5.3GB	801ms
中度	1569MB (26%)	560ms (+2%)	2566MB (21%)	1435ms (+79%)
深度	910MB (15%)	549ms (+0%)	2398MB (20%)	1363ms (+70%)
极限	521MB (8%)	624ms (+14%)	不可安全到达 (看门狗防线 ABM≈15% RAM)	—

核心反差: iOS 相机启动对内存压力几乎免疫 (avail 15% 仍零退化), 鸿蒙在 MA 20~22% 档首帧即 +70~80% 退化。鸿蒙无法安全到达 iOS 的 8% 档——看门狗防线 ABM≈1.8GB (约 15% RAM) 约束施压下限 (实测 MA 低于 ABM 861MB 持续 17.7s 幸存, 已是防线态)。鸿蒙退化拆解 (p1): 受理+孵化 +66ms, 应用侧首帧链 +568ms (文件页被逐出后冷缺页重读 + zswap churn + 重触总线竞争)。诚实披露: 鸿蒙 ballast 体量 (4.5GB, ≈560MB/s 重触) 大于 iOS (≤2GB, ≈250MB/s), 施压工具自身负载有差。

重载下的内存构成弹性 (策略相反)

层	iOS (全档恒定)	鸿蒙 p1→p2
相机应用	fp 24~26MB 不变	稳态 PSS 204→173/191MB; HHP 巨页 74→33/6MB 被拆分回收
相机守护	mediaserverdΔ 585~591MB 不变	daemonΔ 112~131MB ≈不变
内核缓冲池	wired/IOKit 映射不可回收	ION 池从 GB 级被压到 207MB
系统层让路	轮内 avail 回升 +559~632MB (jetsam 杀后台)	zswap 吸收 1.3GB churn; 108 条 dma_heap_alloc 警告(系统服务受害, 相机无失败)

iOS = "杀别人保相机" (前台相机高优先级, 系统回收让路); 鸿蒙 = "三层出血" (应用巨页拆分 → ION 池深度回收 → zswap 兜底), 守护进程与核心缓冲全程稳守。极限行为: iOS@500MB 首帧 624ms 且 mediaserverd 15 次 buffer 分配失败仍出画; 鸿蒙@MA2362 首帧 1363ms, MA 谷底 931MB 存活。两平台相机在各自可安全施加的最深压力下都活着, 差异在代价 (+14% vs +70%)。

4 · 为什么——内存差异成因分析 (f1 成因取证)

① 为什么鸿蒙应用重 (198MB PSS) 而 iOS 应用薄 (24MB fp) — UI 框架承载方式

鸿蒙相机应用进程构成 (f1, 5583 VMA, 32 线程)

构成类别	VMA 数	RSS MB	PSS MB	Swap MB
ArkTS GC 堆	202	82.2	82.2	3.5
native 堆(jemalloc/brk)	165	50.8	50.8	34.3
其他系统库 .so	3347	41.5	11.2	11.3
应用包/ArkTS字节码	602	36.5	35.0	11.2
ArkUI/ACE UI框架	422	33.1	6.3	9.6
图形/显示/缓冲	66	3.9	0.7	4.6
其他文件	567	3.8	2.3	1.6
相机库	108	3.3	1.8	0.4
设备节点	46	2.7	0.3	0.0
ffrt 协程栈	18	0.9	0.4	0.0
线程栈	1	0.3	0.3	0.0

鸿蒙应用的私有重量(~168MB)不在框架库——ArkUI/ACE 库因跨进程共享摊销后 PSS 仅 6.3MB——而在双运行时私有堆: ArkTS 管理运行时多 GC space 常驻(82.2MB PSS, 202 个区) + native 堆(50.8MB, 被 zswap 盯上换出 34MB) + 应用包整体映射(35MB, 含 PhotoBrowser.hsp 24.4MB 预载)。iOS Camera 是 native ObjC 薄客户端: 无管理运行时堆, internal 仅 18MB + IOKit 5.9MB, 系统框架全在共享 dyld 缓存。这是应用运行时技术栈的差异(ArkTS 管理堆+包资源映射 vs native+共享缓存), 不是相机本身的差异。

② 为什么 iOS 管线集中在 mediaserverd 且 wired ~1GB — 三传感器融合 + IOSurface 投影

ioreg 证据 (相机开启时)	值
BackCameraActive (广角)	Yes
BackSuperWideCameraActive (超广角)	Yes
BackToFActive (LiDAR)	Yes
FrontCameraActive / FrontIRCameraActive	No / No
AppleH13CamInUserClient (mediaserverd 驱动通道)	3
IOSurface / IOSurfaceClient 活对象(全系统)	956 / 500
IOMemoryMap / IOBufferMemoryDescriptor	3517 / 2583
IOKitDiagnostics Pageable allocation (系统级, 含非相机)	1.63 GB

拍照模式下 三枚后摄同时激活(广角+超广角+LiDAR 流式, ioreg 实证), mediaserverd 经 3 条 UserClient 通道驱动融合管线; 所有帧缓冲走 IOSurface→IOKit, 同时映射进 mediaserverd(fp 里 iokit_mapped 497MB 即 DMA 缓冲在服务进程的投影)并被内核 wired(Δwired 993MB = 进程投影 ~534 + 内核侧 ~460)。XNU 对 IOKit/DMA 映射默认 wired——设备缓冲必须物理常驻。iOS 的 AI 摄影(Smart HDR/Deep Fusion)拍摄瞬间按需触发, 预览稳态不为其常驻。

③ 为什么鸿蒙 daemon RSS 仅 ~281MB 但真实 1.55GB — fd 传递的 ION 缓冲不进进程记账

鸿蒙 CameraDaemon 构成 (f1, 2414 VMA, 74 线程)

构成类别	VMA 数	RSS MB	PSS MB	Swap MB
native 堆(jemalloc/brk)	118	194.2	194.2	25.1
其他系统库 .so	672	41.5	33.2	0.8
相机库	153	25.2	25.0	0.7
图形/显示/缓冲	839	8.8	5.9	0.0
ffrt 协程栈	47	5.5	4.8	1.4
其他文件	370	2.4	2.1	1.1
设备节点	42	1.9	0.1	0.0
匿名(未映射文件)	156	0.8	0.8	0.0

daemon 自己的 RSS 基本是 jemalloc 堆 186MB + HAL 库 25MB + ffrt 协程栈(74 线程); 而 1.32GB 缓冲由其工作线程经 ION 堆导出、fd 传递零拷贝、从不 mmap 进自己地址空间——Linux 记账下这些缓冲只进系统 IonTotalUsed。与 iOS 恰好相反: iOS"映射进服务进程+wired", 鸿蒙"fd 持有+不映射", 两者都合法, 但导致跨平台 RSS/fp 完全不可比。

④ 为什么鸿蒙 ION 池 (1.58GB) 大于 iOS wired (0.99GB) — 传感器规格 + 常驻 AI ISP

功能类别	块数	MB
未命名/池基座	44	385.1
其他长尾	134	259.8
图像源池(全分辨率多帧)	95	256.9
AI ISP/算法	196	207.5
预览	1	115.0
VIDHANCE 稳像	20	45.9
RAW 缓冲	5	30.7
后处理流	2	24.1

传感器规格: 50MP 四合一的全分辨率源帧池(NORMAL_SOURCE 257MB)按分辨率天然大于 12MP; 算法常驻策略: 华为把 AI ISP(SmartISP 模型帧 60MB)、稳像(VIDHANCE)、色彩(AICOLOR)、多帧语义(MSC)、跟踪(tracking_aiv)全部做成预览期常驻管线算法(196 块), 另有 hiaiserver 独立推理服务 +172MB; iOS 同期只跑三传感器融合, AI 摄影按需。此差异主要由硬件规格与产品策略驱动, 不能读作系统内存效率差异。

⑤ 合成器、生命周期、换出策略

合成器 +32 vs ~6MB: iOS 预览 IOSurface 必须映射进 BackBoard 参与窗口合成(ΔIOKit 31MB); 鸿蒙取景表面经 BufferQueue 以 dmabuf fd 递交, render_service 短暂导入不常驻(显示表面 +85MB 在 ION 的 allocator_host 名下, 不在 render_service RSS)。
关闭后残留: iOS session teardown 释放全部 IOSurface(wired→基线), 仅 backboardd 留 +1~8MB; 鸿蒙 ION 随 fd 归零全量归还, 但 daemon 的 jemalloc 堆不还给 OS + 保热优化, 留 +15~27MB Anon。内核缓冲两边都"干净", 差别在用户态堆管理策略。
换出 0 vs 77MB: 鸿蒙 12GB 机型常态 zswap 分层(应用冷页换出 77MB + daemon 30MB), PSS 只见常驻部分; iOS 6GB 空闲 2.1GB, XNU 压缩器无压力完全不介入(5 轮 Δcompressed≈0)。策略差异, 不可比优劣。

⑥ 成因汇总

差异点	iOS	鸿蒙	根因分类
应用进程 24 vs 198MB	native 薄客户端+共享 dyld	ArkTS 管理堆 82MB+native 堆 51MB+包 35MB	架构选择 (应用运行时技术栈)
管线归属 547 vs 110MB(PSS)	mediaserverd 单体+IOSurface 投影	daemon 薄 RSS+ION fd 持有	架构选择 (缓冲记账位置)
内核池 993 (wired) vs 1585 (ION) MB	三传感器融合+按需 AI	50MP 多帧+常驻 AI ISP+独立推理服务	硬件规格+产品策略
合成器 +32 vs ~6MB	表面映射进合成器	BufferQueue fd 直通	架构选择 (显示栈)
关闭后服务内存	归零 (session teardown)	留 +15~27MB (jemalloc+保热)	策略 (生命周期管理)
换出 0 vs 77MB	无压力不压缩	zswap 常态分层	硬件容量+策略
记账口径 fp/PSS/wired/ION	—	—	技术口径 (禁互比)

5 · 高置信结论清单

冷启动首帧: iOS 549ms vs 鸿蒙 801ms (n=5, 轮间波动 <10ms); ~100ms 差来自受理路径 (XPC vs aa fork+exec)。
暖恢复加速比几乎相同 (iOS -19%, 鸿蒙 -22%): 收益都来自跳过进程创建。
相机内存大头在内核缓冲池; 进程视图只覆盖 30~40%。两平台记账策略相反 (iOS: IOKit 映射进进程; 鸿蒙: fd 持有不映射), 本质相同。
CameraDaemon 真实内存 = RSS 228MB + 导出 ION 1.32GB ≈ 1.55GB; 缓冲名直接可见 DYNAMIC_PREVIEW 115MB / SmartISP 模型帧 60MB / VIDHANCE 稳像 / AICOLOR 等。
关闭相机后两平台内核池均全量归还; 粒度差异: 鸿蒙 daemon Anon 留 +15~27MB, iOS backboardd 留 +1~8MB。
合成器代价: iOS backboardd +32MB vs 鸿蒙 render_service ≈0 — 鸿蒙取景表面不经合成器记账。
鸿蒙依赖 zswap (应用 78MB 换出 + daemon 30MB 常驻 swap); iOS 相机路径零压缩。
系统可用量回落同量级 (~1.3GB): 相机管线都需要 GB 级缓冲的共同本质。

6 · 边界 (不能得出的结论)

硬件混杂变量无法剥离 (A14/6GB vs 麒麟/11.7GB; 12MP vs 50MP+AI ISP) — 不能归因"某系统更优"。
鸿蒙 ION 池更大主要由传感器规格驱动 (SmartISP/VIDHANCE/AICOLOR 缓冲可见), 不能读作系统效率差异。
单设备×单晚间, n=5/n=3, 无统计显著性检验; 只测默认拍照模式; 不能外推其他机型/版本。
越狱 (Taurine) / 工程模式环境与普通用户态略有差异。

7 · 过程数据 (全部轮次明细)

▶ 展开/收起全部过程数据

iOS 主实验 (冷 r1-r5 / 暖 w1-w2, ms / MB)

轮	M0_freeMB	M0_availMB	M5_req_ms	M1_spawn_ms	M2_anim1_ms	M3_prev_ms	M3_self_ms	M7_camfp_MB	M8_campeak_MB	M8_stackpeak_MB	M10_msddelta_MB	M9_Sglob_MB	M9_Sattr_MB	M9_resid_MB	M11_msdtail_MB	M11_availslope_MBps
r1	2179	3044	2	24	648	549	461	25	27	1372	551	1351	575	776	-1	146
r2	2168	3010	36	57	688	570	447	25	27	1351	551	1327	576	751	3	146
r3	2162	2998	1	29	653	534	443	25	27	1363	548	1342	573	769	-3	147
r4	2160	2984	1	27	657	541	446	25	27	1358	551	1329	576	753	0	147
r5	2162	2984	28	55	678	569	453	25	27	1352	552	1323	576	747	0	146
w1	1885	2585	0	NA(warm)	765	440	19599	24	25	1205	545	1168	569	599	-6	145
w2	1881	2609	13	NA(warm)	778	449	19589	24	25	1217	545	1176	569	608	-6	150

鸿蒙主实验 (冷 r1-r5 / 暖 w1-w2, ms / MB)

轮	M0_availMB	M5_ams_ms	M1_spawn_probe_ms	M1_fork_ms	M2_onfg_ms	M3_ff_ms	hypersnap	M7_camPss_MB	M7_camRss_MB	M7_pssHHP_MB	M8_campeak_MB	M8_stackpeak_MB	M10_daemon_delta_MB	M10_svc_delta_MB	M9_Sglob_MB	M9_Sattr_MB	M9_resid_MB	M11_daemon_tail_MB	M11_avail_slope_MBps	cam_pid
r1	5779	107	201	198	331	789	2	204	257	74	258	1356	117	3	1324	324	1000	18	165	10441
r2	5776	107	208	200	336	749	2	204	257	73	259	1343	111	3	1309	317	992	13	163	10441
r3	5786	107	200	190	327	801	2	202	256	74	258	1397	111	3	1402	316	1086	18	170	10441
r4	5778	108	298	210	350	810	2	200	253	71	254	1341	112	3	1310	315	995	16	156	10441
r5	5687	111	201	196	337	802	2	200	253	71	255	1255	104	3	1242	307	935	16	160	10441
w1	5724	96	—	—	146	617	2	210	272	70	272	1408	117	3	1342	330	1012	79	154	10441
w2	5717	101	—	—	170	634	2	211	273	67	273	1382	108	4	1354	322	1032	59	157	10441

iOS 空转轮 (环境漂移)

轮	M0_freeMB	M0_availMB	drift_MB
i1	2178	3041	-4
i2	2157	2983	-0

鸿蒙空转轮 (环境漂移)

轮	M0_availMB	M5_ams_ms	M1_spawn_probe_ms	M1_fork_ms	M2_onfg_ms	M3_ff_ms	hypersnap	M7_camPss_MB	M7_camRss_MB	M7_pssHHP_MB	M8_campeak_MB	M8_stackpeak_MB	M10_daemon_delta_MB	M10_svc_delta_MB	M9_Sglob_MB	M9_Sattr_MB	M9_resid_MB	M11_daemon_tail_MB	M11_avail_slope_MBps	cam_pid
i1	5787	—	-1	-10	—	—	0	-1	—	-1	—	—	—	—	—	—	—	-0	—	-1
i2	5784	—	-1	-10	—	—	0	-1	—	-1	—	—	—	—	—	—	—	-7	—	-1

iOS wired 增长 (r1-r5, watch vm_stat w 列, MB)

轮	Δwired MB
r1	995
r2	985
r3	993
r4	995
r5	986

C4 全进程拆解 (Δ, MB, d1/d2/d3; iOS=Δfp, OH:=ΔPSS)

进程	d1	d2	d3
mediaserverd	546.8	550.2	546.9
backboardd	33.6	31.6	28.3
Camera	23.8	23.9	23.9
OH:wei.hmos.camera	198.0	198.5	191.8
OH:CameraDaemon	104.9	110.7	108.9
OH:render_service	6.2	3.3	1.5
OH:ohos.sceneboard	5.7	2.7	-3.7
OH:camera_service	2.3	1.5	1.5
OH:av_codec_servic	0.7	0.6	0.7
OH:audio_server	0.6	0.0	0.0
OH:media_service	-0.2	-0.4	-0.3
OH:codec_host	0.0	-0.0	-0.0

e 轮 ION/dmabuf 内核池审计 (MB)

轮	ΔIonTotalUsed	CameraDaemon 导出(稳态)	其他导出	ΔIon(关闭后)	ΔMemAvailable
e1	+1583	1325	443	+0.1	-1061
e2	+1599	1318	472	-7.6	-1673
e3	+1585	1318	450	+2.8	-1516

8 · 方法与执行透明度

指标体系 M0~M11: compare/protocol/architecture.md (swarm architect v1→v3); iOS 协议 ios-expert 产出; 拆解扩展 mem-decomp 团队发起 (队友 token 上限, lead 起草+执行, 全程记录)。
iOS 工具: launchcam (syslog 锚点) + camwatch (50ms: 19 列 vm_stat + 8 进程) + appscan 全进程快照 + idevicesyslog 流式留痕 (收据锚定)。
鸿蒙工具: camprobe.c (CLOCK_MONOTONIC, /proc 扫描, cold/idle/warm/decomp 四模式) + bufaudit.sh (ION/dmabuf 审计, 4 相位) + hilog 流式。
统计纪律: r0/i 轮作暖机/漂移控制; median[min~max]; 弃用轮如实标注 (r5b/w0 hilogd 事故)。
复算入口: analyze_ios.py / analyze_ohos.py / analyze_ios_decomp.py / analyze_ohos_decomp.py / analyze_ohos_bufaudit.py; 本页全部数字由 build_site.py 从原始数据现场生成。