点击左侧任意节点查看详情
环 = 层级深度（内→外）· 弧长 = 所选度量的子树规模 · 颜色 = 来源（■系统 ■应用私有 ■三方库 ■独立图层，越深越暗）· 对象内存 = class_ro_t.instance_size 设备实测（view+layer 真实壳）· 背衬估算 = contents 实测位图优先（bilibili 66 层）+ 自绘类启发式（容器类无 backing）· 可见节点 = M6 静态可见性判定（hidden 传播/裁剪/离屏/遮挡启发式，假设恒等 transform）· 悬停看子树规模，点击查节点详情
点击旭日图任意环段
悬停查看详情
| 负载 | iOS（lazy + purgeable） | 鸿蒙（eager + DMA + LRU） | 胜者 |
|---|---|---|---|
| 常显示、反复用的图 | 堆位图 + server 纹理 = 系统两份 | DMA 一份全系统共享 · 缓存命中不重解码 | 鸿蒙 |
| 大量隐藏/预建图 （bili 首页 63.2% 隐藏类负载） | 仅压缩数据 0.86MB/张 | 默认解码 48MB × N，直到 LRU 上限 | iOS（量级差） |
| 内存压力行为 | purgeable 静默回收 · 不杀进程 | LRU 逐出 · 256MB 内持久占用，靠应用调参 | iOS |
| 首帧延迟 | 首次绘制主线程解码 → 大图掉帧 | 已就绪 → 流畅 | 鸿蒙 |
| # | 原论证 | 检验结果 |
|---|---|---|
| 修正 ① | 「鸿蒙支持 lazy 可选，所以更优」 | 不成立——两端对称：iOS 可 predecode 转 eager（iOS 15+ preparingForDisplay），鸿蒙可 DIY 转 lazy。差别只是默认值方向，不是能力 |
| 修正 ② | 「iOS 需从 ImageIO 拷贝到 IOSurface」 | 机制说反半步——拷贝是「App 堆 → server 纹理」的一次性上传（server 缓存复用，非每帧）；且 iOS 视频路径（CVPixelBuffer）/Metal 本就零拷贝，「必须拷贝」只对静态图成立。实测：解码产物 tag-88 全程 0，从头到尾不是 IOSurface |
| 修正 ③ | 「PixelMap 走 DMA 零拷贝」 | 设计上限 ≠ 默认现实——硬解路径落 DMA，软解/部分格式仍可能堆 PixelMap + 上传；GPU 采样 dma-buf 还受格式/stride 兼容约束（文档级，待实测） |
task_conversion_eval ipc_tt.c:2183）——「全系统总量」对比在 iOS 侧只能推算不能实测；鸿蒙侧当前全部为文档级推断。| 组 | 配置 | 验证什么 | 状态 |
|---|---|---|---|
| A | 鸿蒙默认 Image + 隐藏（Visibility.None） | eager 基线：隐藏态是否就吃 48MB 解码内存（hidumper --mem 查 PSS/dma_heap） | ⏳ 待设备 |
| B | 鸿蒙 LazyForEach 屏外 item | 组件级懒的边界：组件不创建是否即不解码 | ⏳ 待设备 |
| C | 鸿蒙 DIY：持 ImageSource + 可见才 createPixelMap | 应用级懒 = iOS 语义复刻（四点法直接套用） | ⏳ 待设备 |
| D | iOS 默认（隐藏图片组件） | lazy 基线：隐藏态只有压缩数据 | ✓ 已测（tag-88=0 · 压缩 0.86MB） |
| E | iOS predecode（offscreen 强制绘制） | eager 形态复刻：验证「两端默认值不同、能力对等」 | ⏳ 可立即做 |
raw-data/exp-decode-2026-09-24.md · 解码触发时点 = CA 周期 layout → display（解码在此） → commit（运输）