业务 × 内存抓栈拆解

malloc / IOSurface / purgeable 三线闭环 —— 结论、方法论与 Instruments 对比

iPhone 12 Pro · A14 arm64e iOS 14.8 (xnu-7195.141.2) Taurine 越狱 frida-server 17.18.0 采集日期 2026-10-27

01一句话总览

同一条方法论（公开符号 Interceptor hook + 分层采集 + 协议工程 + 内核源码对齐），三条互相印证的线，把"业务申请了多少内存、申请了什么、何时声明可丢弃"全部落到带调用栈的事件级证据上。

malloc（怎么申请·高频小额·churn 主导）→ IOSurface（申请什么·低频大额·持久）→ purgeable（何时声明可丢/取回·状态机迁移）

02内存拆解结论（业务全景）

三线数据合成一张表：IOSurface = 图形/媒体面，malloc 毛申请 = 分配压力，in_use Δ / purgeable = 净持有与可丢纪律。

业务	IOSurface 申请	malloc 毛申请 / 窗口	净变化	主导路径（实抓栈）
相机管线 mediaserverd	531 MB	865.3 MB / 50s 338 万次调用	in_use +66.1MB	全系统最大瞬时内存事件：CVPixelBufferPool 515MB + FigPhoto JPEG 70MB + ANE 14MB ‖ H13ISP 逐帧元数据 176.8MB ← JasperDepth 深度引擎 112.7MB ← 点云 38.8MB
快手	34.4 MB	460.9 MB / 60s 690 万次调用	in_use +1.4MB 存活 28.4MB	Metal `IOGPUResourceListInit` 命令缓冲池 19MB · NSKeyedArchiver 序列化 11MB · JSON 8MB · anon 热补丁代码 36MB
美团	7.4 MB	122.9 MB / 60s 58.6 万次	in_use +4.8MB	JSON 解析驱动：NSJSONReader 22.3MB · dispatch_data 网络 8.1MB · gzip 压缩 6.8MB
bilibili	56.3 MB	39.8 MB / 60s 15.9 万次	in_use +10.4MB	自研 AVIF 解码器 13.7MB（BFCImageAVIFCoder）· CG 图像 2.9MB · boringssl TLS 2.2MB
京东	≈0	3.7 MB / 60s 4.4 万次	in_use −0.8MB	Cronet 双向流 · 小额为主，最安静的业务
淘宝	118.6 MB	不可测（慢启动）	—	IOSurface 面 = MediaToolbox FigPhoto 解码池；malloc 面冷启动 >45s 仍在闪屏
微信	13 MB	不可测（反调试）	—	frida script 加载层挂死 rpc；低频 purgeable hook 也无解
网易云 / 小红书	27.4 MB	不可测（永续分配流）	—	内容流 prefetch 永不停歇：+13/25/45s 任何时点挂钩必触发看门狗
抖音	42 MB 稳态	不可测（反调试）	—	稳态 0 新建 + 42MB 持有已知
SpringBoard	~92 MB / 次切换	2.0 MB / 40s 空闲 28.6k 次	±0（空闲）	CARenderServerCreateSnapshots 快照 + ImageIO；基线 ~715 次调用/秒

结构性规律

malloc churn ≫ 净增长：快手 60s 毛申请 460.9MB，存活仅 28.4MB、in_use 只 +1.4MB —— 分配压力和真实占用是两个口径，只看 RSS/footprint 会把"高周转"误读成"吃内存"。
malloc 栈签名 = 业务指纹：快手（GPU 命令缓冲+序列化）/ 美团（JSON+压缩）/ B 站（自研解码器）/ 京东（Cronet）一眼可分；相机管线（ISP 元数据+深度引擎）独树一帜。
IOSurface 与 malloc 是两个世界：IOSurface 由内核 IOKit 分配、走 tag 88 记账、低频大额持久（purgeable 才回收）；malloc 用户态高频小额、churn 主导。开相机同时点燃两者：531MB 像素池 + 865MB/50s 处理流量。
后台即释放：bilibili 切后台瞬间，CA 把全部层背板 shmem set_volatile（73 次），8.9MB nonvolatile purgeable 清到 0.1MB —— 第一章"后台 tag88 清零"在状态机层得到解释。
purgeable = 持有但不计数：VOLATILE/EMPTY 页（含压缩态）不计入 phys_footprint（xnu vm_purgeable.c 记账模型）→ 快手靠 SQLite 页缓存持有 73.4MB purgeable，是全场最大"合法隐身"持有者。

03purgeable 状态机层结论

hook vm_purgable_control 的 SET 调用并 onLeave 回读旧状态（内核写回），得到完整迁移矩阵：

业务	0→1 置 volatile	1→0 取回	0→2 直接置空	2→0 取回发现被偷	直接调用者
快手稳态 30s	76 (4.75MB)	75 (4.69MB)	4	1	sqlite3_db_release_memory ×295（页缓存 0↔1 高频往返）+ libnetwork nw_segment（0→2）
bilibili 前后台	45	8	1	0	CA::Render::Shmem::set_volatile ×38 + sqlite ×15
SpringBoard 切换	17	10	0	4	sqlite ×24 + CA shmem ×7 —— 快照内容被内核偷过再取回的实锤
mediaserverd 相机	0	0	0	0	SET 全零：捕获管线纪律走 `madvise(MADV_FREE_REUSABLE)` ×1487/40s

入口路由真值表（purg_probe.py 进程内实证 + xnu-7195.141.2 源码实锤）

入口	驱动状态机？	实证 + 源码实锤 [SRC]
`mach_vm_purgable_control` SET	✅ 唯一用户态驱动者	SET VOLATILE → pnv/pv/footprint 字节级精确 2MB 移动 ‖ `vm_object.c:5846-6166`；*SET 回写旧状态 = :6162 `state = old_state`**（onLeave 回读迁移矩阵的机制依据）
`mach_vm_allocate/map(VM_FLAGS_PURGABLE=0x2)`	✅ 创建期赋 NONVOLATILE	创建后 GET_STATE=0；bilibili 25s 内 6 次 `CA::Render::Shmem::new_shmem` 创建层背板 ‖ `vm_map.c:2837-2839`
`madvise(MADV_FREE_REUSABLE/REUSE)`	❌ 与 purgeable 完全正交	purgeable state 纹丝不动；驱动独立 reusable 页级机制（reusable ledger 精确 +2MB）‖ `kern_mman.c:1158-1163`→VM_BEHAVIOR_REUSABLE→`vm_map.c:15429`→`:15937-15943 vm_object_deactivate_pages(reusable_pages=TRUE)`→`:15964 vm_page_stats_reusable` 计数——整条链零 VM_PURGABLE 引用
`madvise(MADV_DONTNEED/FREE)`	❌	state 不动 ‖ `kern_mman.c:1149-1153`→`vm_map.c:15423-15427`（VM_SYNC 页级操作）
`CABackingStoreSetVolatile`	✅ 内部走陷阱	bilibili 38 次带 QuartzCore 栈的 SET
`IOSurfaceSetPurgeable`	⚠️ IOKit 内核侧控制	陷阱 hook 看不到内核调用；业务实测 0 次直接使用 ‖ `vm_object.c:5883-5886`：purgeable_only_by_kernel 对象拒用户态 SET → IOKit 走 SET_STATE_FROM_KERNEL(3)
SET 目标 EMPTY（0→2）	✅ 立即清页	libnetwork nw_segment ×4 实抓 ‖ `vm_object.c:6107-6159` `vm_object_purge(object,0)`——用户态主动丢弃内容的通道
EMPTY 不可逆	状态机约束	`vm_object.c:5901-5905` "what's been emptied must stay empty"
内核偷取（VOLATILE→EMPTY）	⚠️ 用户态 hook 天然不可见	2→0 ×4 间接捕获（回读旧态）‖ `vm_pageout.c:1850-1866`：压力分级 Warning/Urgent/Critical → `vm_purgeable_object_purge_one(force_purge)`

勘误：此前把 madvise(MADV_FREE_REUSABLE) 流量归入 purgeable 是错的——libmalloc/JSC/捕获管线的海量 madvise 属于独立的 reusable 页机制（账记在 task_vm_info.reusable，不驱动状态机）。purgeable 状态机的真实流量只有 SET/GET 调用本身；CA 层背板才是业务侧主角（创建即 purgeable → 后台 SET volatile → 压力下被偷 → 取回回读 EMPTY）。

04抓栈方法论（七步）

零注入普查先行 — ioreg/region 清点 + task_vm_info ledger（phys_footprint / purgeable / media-tag 四联表）扫全部 pid，先知道"谁重"再决定去哪采。tag 88 IOSurface 记账即在此步发现。
hook 面只选公开导出符号 — malloc 8 符号（malloc_get_all_zones iOS 未导出，公开符号无双重计数）；IOSurface 收敛点 IOSurfaceCreate（全部用户态路径汇聚）；purgeable 7 入口（vm/mach_vm_purgable_control、madvise 过滤 advice≥5、IOSurfaceSetPurgeable、CABackingStoreSetVolatile）。设备侧先 enumerateExports 侦察存在性（malloc_create_purgeable_zone 即在侦察中确认 MISSING）。
分层采集控开销 — malloc：≥8KB 记 28 帧符号化栈、≥4KB 进存活集（free 出账 → live-by-stack 视图）、全量按 6 档计数；purgeable：SET 带栈流式、GET 只计数。JS hook 每调用 ~3-10µs，无差别回溯会触发看门狗。
协议工程对抗启动风暴 — uiopen 拉起 → +13s attach → 40-60s 窗口（过早=风暴杀 App，过晚=静态零事件）；死亡分类成四型（启动风暴 / 永续分配流 / 慢启动 / 反调试）；流式 send() + 周期 dump 双保险（mediaserverd 两次窗口内死亡，数据保住）。
多维校准 — malloc_zone_statistics 前后快照对账带栈覆盖率（实测 34-61%）；task_vm_info ledger 前后 Δ 对账；purgeable SET 的 onLeave 回读旧状态（内核语义，源码实证）。
内核源码对齐 — xnu-7195 源码定语义再动手：purgeable 状态机/记账模型（vm_purgable.h、vm_purgeable.c:1690-1718）、mach_vm_region_recurse depth 参数真义（下降上限，传 64；depth++ 会自引用死循环）、ledger 字段偏移。
失败模式本身是结论 — 不可测的业务逐个定位机理（永续流=内容 prefetch 不停、反调试=script 层），记录为工程边界而非数据空洞；CModule 原生过滤（~100ns/次）是唯一升级路径。

入口完备性方法论（深夜补强）：对"hook 面是否全面"的质询，用进程内实证探针回答——亲手 mach_vm_allocate(VM_FLAGS_PURGABLE) 建 16MB 映射，逐个施加 madvise(4/5/7/8)/SET_STATE，每步 GET_STATE + ledger 对账。结果推翻了一个预设（madvise 不走状态机）、证实了创建期入口（补 hook 后立刻抓到 CA shmem 创建 ×6）、并框定了不可观测边界（内核侧迁移只能间接看）。

05与 Instruments 的区别

✓ 本套方法能做（Instruments 做不到或很难）

IOKit/内核分配的申请栈：IOSurface 由内核分配，不在任何 malloc zone —— Allocations 面板看不到申请路径；hook IOSurfaceCreate 拿到全部用户态收敛点。
系统 daemon：mediaserverd 相机管线（531MB+865MB 解剖）、SpringBoard 快照、backboardd —— Instruments 无法 attach 系统 daemon，越狱环境可以。
App Store 原版 App：无需重签名/重打包/重编译，原版二进制直接 hook，保持生产形态。
purgeable 状态迁移事件流：VM Tracker 只有持有量快照；这里给出 SET 迁移矩阵（谁、何时、旧→新）与"被内核偷取"实锤（2→0）。
跨业务统一口径：同一 hook 面、同一协议下横向可比，栈家族分类直接当业务指纹。
内核记账模型联动：ledger 普查（purgeable/media-tag/footprint）与事件流互相印证。

✗ Instruments 更强的地方（诚实交代）

启动风暴窗口：native 记录开销低，能扛 10 万+/秒的启动期；JS hook 会被看门狗杀死（美团/快手稳态扛住了 11.5 万/秒，但小红书/网易云任何时点都死）。
长时跟踪与回放：Instruments 的时间轴/标记/对比是成熟产品能力。
反调试 App：两者都难（微信/抖音在 script 加载层挂死）；Instruments 至少不需注入。
图形界面分析体验：本套方法的产出是 JSON + Python 聚合，分析门槛在脚本侧。

维度	Instruments (Allocations/VM Tracker)	本套方法（越狱 + frida 抓栈）
malloc 用户态栈	✓（需 Xcode/DDI/可调试进程）	✓ 原版 App/daemon 通用
IOSurface/IOKit 申请栈	✗（内核分配，不可见）	✓ IOSurfaceCreate 收敛点
purgeable 状态迁移	仅持有量快照	✓ 迁移矩阵 + 调用者栈
系统 daemon	✗	✓
启动风暴	✓	看门狗边界（CModule 可解）
反调试 App	基本不可用	部分可用（IOSurface 面）
口径一致性	每次配置不同	同一 hook 面横向可比

06边界与升级路径

四类不可测已定位：启动风暴致死（小红书/网易云）、慢启动（淘宝）、反调试（微信/抖音）、永续流与风暴同源。CModule 原生过滤是唯一系统性解法。
<4KB 小额不进存活集（开销边界）；nano zone ≤255B 在 zone 统计外；realloc 双重计数口径已注明。
WebContent/Safari 内嵌页不可 attach；用连接计数佐证持有。
设备锁屏会静默拒绝一切 App 启动（FrontBoard RequestDenied: Locked）——批量采集前必须解锁并设永不锁定。

07产物清单

tracer：frida_malloc_trace.py / frida_iosurface_trace.py / frida_purgeable_trace.py（9 入口：purge_control×2 + madvise 过滤 + IOSurface/CA 4 + 创建期 mach_vm_allocate/map ×2 + ledger 含 reusable 独立记账）
路由实证探针：purg_probe.py（进程内建 purgeable 映射逐操作对账，入口真值表的来源）
驱动与聚合：malloc_batch.py / analyze_mtrace.py / census_inproc.py
报告：REPORT.md（三章：IOSurface / malloc / purgeable）
原始数据：raw-data/iosurface-trace-2026-10-27/（18 文件）· raw-data/malloc-trace-2026-10-27/（14 文件）· raw-data/purgeable-trace-2026-10-27/（5 场景）

业务 × 内存 抓栈拆解