iOS / 鸿蒙 / 安卓 UI 渲染管线深度对比
—— 以 XNU 内核源码为锚点

§0速览结论（TL;DR）

§1iOS 渲染管线：从 UIKit 到屏幕

1.1 全链路总览

注：render server 由 backboardd 承担为架构层结论（Apple 未开源该守护进程），内核侧通路（IPC / 共享内存 / IOKit）全部有 XNU 源码锚点，见 §2。

1.2 应用进程内：视图与 layer 树的构建 ARCH

iOS 上所有视图建模都发生在应用进程内。UIKit 的 UIView 只是 CALayer 的宿主与手势/布局容器——每个 UIView 创建时都会随之创建一个 CALayer； SwiftUI 则在声明式 diff 之后把结果落到 UIKit/CA 层级上（TableViewCell 场景甚至直接复用 layer）。 也就是说，iOS 应用的"组件树"（视图树 + layer 树）完整地活在应用进程的地址空间里， 这一点与用户印象中鸿蒙"把组件发给渲染进程"有本质区别。

Core Animation 采用 client/server 架构：应用进程是 client，负责构建 layer 树、 修改属性、把变更打包进 CA::Transaction；Runloop 的 commit 阶段（或显式 CATransaction.commit()）把事务序列化为紧凑的二进制命令流，通过 Mach IPC 发往 server。 由于 Mach 消息是定长缓冲的 IPC（见 §2.2 源码），树数据必须编码压缩，而不是传对象图。

1.3 跨进程提交：Mach IPC 通道 SRC

应用提交渲染事务走的是 XNU 的 Mach 消息陷阱。内核侧入口是 mach_msg_overwrite_trap（osfmk/ipc/mach_msg.c L513）， 消息体里既可以是内联数据，也可以携带 OOL（out-of-line）内存描述符—— 这是 iOS 渲染管线跨进程传大块数据（纹理、layer backing、参数缓冲）的内核级机制。

1.4 Render Server：backboardd 的职责 ARCH

iOS 上 Core Animation 的 server 端运行在 backboardd（macOS 上是 WindowServer）。 它为每个应用的 layer 树维护一份服务端镜像（WebKit 开源代码中的 RemoteLayerTree 协议即为此通路的公开实现， WebContent 进程 → UI 进程的 layer 树同步用的同一套机制）。它的核心职责：

• 持有 server 侧 layer 树：接收应用提交的事务并应用到镜像树上；
• 动画插值：CABasicAnimation/CAKeyframeAnimation 提交后， 由 server 端逐帧计算属性值，应用进程可以完全休眠——这是 iOS 后台动画不占应用 CPU 的原因；
• 合成调度：把各 layer 的内容（IOSurface）交给 GPU 合成为最终帧；
• 事件反馈：命中测试、动画完成回调等经 IPC 回传应用。

1.5 像素不拷贝：IOSurface 共享内存 SRC

iOS 渲染架构最精妙的一点：跨进程传输的是"命令"，而像素内容从不随 IPC 拷贝。 每个 layer 的 backing store 是一个 IOSurface——本质是一块由内核管理的命名内存， 应用进程与 render server（以及 GPU 驱动）通过同一份物理内存的不同虚拟映射访问它。 内核机制上有两条通路（§2.4 详述）：

• Mach memory entry：mach_make_memory_entry_64 把一块内存变成 port 句柄， 对方进程拿到句柄后映射进自己的地址空间——XNU 源码注释原话："a two-stage vm_remap()"；
• IOKit 路径：IOSurface 框架经 IOUserClient::mapClientMemory64 → IOMemoryDescriptor::createMappingInTask 把驱动侧分配的 buffer 映射进任意目标 task。

这些像素内存同时挂接在内核的 purgeable（可清除）内存状态机上（osfmk/vm/vm_purgeable.c 的 token 机制）：应用退到后台、内存吃紧时，内核可以直接丢弃这些页（内容可由应用重新渲染恢复）， 这是 iOS "后台应用内存自动回收"在渲染侧的底层支撑。

1.6 GPU 触达：Metal 与 IOKit UserClient SRC

iOS 上有两种渲染来源，最终都汇入 render server 的合成：

• 由 server 渲染的 layer：文字、矢量图形、简单形状等由 render server 用 GPU 渲染成 layer 内容；
• 由应用渲染的 layer：CAMetalLayer 场景（游戏、视频、WebView）下， 应用进程自己通过 Metal 渲染到 drawable（本质是一个 IOSurface），server 只做合成。

无论哪种，GPU 命令的用户态提交都经由 IOKit 的 UserClient 机制进入内核 GPU 驱动 （Apple GPU 驱动 + AGX 用户态编译器服务），映射关系同样落在 mapClientMemory64 → createMappingInTask 这条内核通路上（§2.4）。

1.7 安全边界：为什么必须走 IPC 而不能直接读对方内存 SRC

XNU 对跨进程内存访问有硬性门控：ipc_tt.c 的 task_conversion_eval（L2154-2194）规定， 在非 macOS 平台上，若目标 task 是平台二进制（backboardd、SpringBoard 等）而调用方是第三方应用， 所有跨进程 VM 原语（mach_vm_read、mach_vm_region_recurse 等）一律返回 KERN_INVALID_SECURITY。结论：第三方应用无法旁路渲染服务进程直接窥探或操纵合成层， 所有渲染数据必须经由内核裁剪过的公开通道（Mach IPC + 受控共享内存）流动。

§2XNU 源码证据链 SRC

以下锚点全部来自 apple-oss-distributions/xnu @ xnu-7195.141.2（iOS 14.8）， 本机已下载原始文件，行号可复核。

2.1 应用提交事务的内核入口：mach_msg trap

mach_msg_return_t
mach_msg_overwrite_trap(
	struct mach_msg_overwrite_trap_args *args)
{
	mach_vm_address_t       msg_addr = args->msg;        // 应用态消息缓冲
	...
	if (option & MACH_SEND_MSG) {
		ipc_space_t space = current_space();
		ipc_kmsg_t kmsg;

		mr = ipc_kmsg_get(msg_addr, send_size, &kmsg);          // ① 拷入内核 kmsg
		...
		mr = ipc_kmsg_copyin(kmsg, space, map, priority, &option); // ② 解析端口/OOL 描述符
		...
		mr = ipc_kmsg_send(kmsg, option, msg_timeout);            // ③ 入队目标端口 → 唤醒接收方
	}

渲染事务（编码后的 layer 命令流）就是从这里离开应用进程的：①把消息体拷进内核缓冲， ②解析其中的端口权限与 OOL 内存描述符，③挂到目标端口（render server 的接收端口）的队列上并唤醒接收线程。 整个过程在内核里完成原子转换，应用与 server 之间没有任何共享队列的竞态窗口。

2.2 大块数据跨进程：OOL 描述符的 copy-in / copy-out

static mach_msg_descriptor_t *
ipc_kmsg_copyin_ool_descriptor(...)
{
	...
	} else {
		/*
		 * Make a vm_map_copy_t of the of the data.  If the
		 * data is small, this will do an optimized physical
		 * copy.  Otherwise, it will do a virtual copy.       ← 虚拟拷贝：仅建映射不搬字节
		 */
		kern_return_t kr = vm_map_copyin(map, addr,
		    (vm_map_size_t)length, dealloc, copy);
		...
	}

// 接收端（render server）取出 OOL 内存：
kr = vm_map_copyout_size(map, &rcv_addr, copy, size);  // 映射进接收方地址空间

这就是 iOS 渲染数据"跨进程传输"的内核真相：小数据物理拷贝（一次 memcpy 进内核 copy map）， 大数据虚拟拷贝（vm_map_copyin 只建立内核持有的映射权，接收方 vm_map_copyout 时才落映射）——没有应用→server 的整块像素搬运。 真正的像素共享走下面 2.4 的 memory entry / IOSurface 机制。

2.3 端口队列与唤醒：ipc_kmsg_send / ipc_port

mach_msg_return_t
ipc_kmsg_send(ipc_kmsg_t kmsg, mach_msg_option_t option, mach_msg_timeout_t send_timeout)
{
	// 将 kmsg 挂入目标端口的消息队列（ipc_port.c 维护 port 状态/turnstiles），
	// 阻塞式发送时等待接收方取走或超时；CA 事务提交用非阻塞形式。
	// 配对文件：osfmk/ipc/ipc_port.c（3281 行，端口权利与队列状态机）

2.4 像素共享的内核机制：memory entry 与 IOKit 映射

/*
 * Think of it as a two-stage vm_remap() operation.  First
 * you get a handle.  Second, you get map that handle in
 * somewhere else. Rather than doing it all at once (and
 * without needing access to the other whole map).
 */
kern_return_t
mach_make_memory_entry_64(
	vm_map_t                target_map,
	memory_object_size_t    *size,
	...)

↳ 这段内核注释就是 IOSurface 共享的机制本质：把内存变成port 句柄，句柄发给谁，谁就能二次映射同一份物理内存。

IOMemoryDescriptor::createMappingInTask(
	task_t                  intoTask,      // ← 目标可以是“另一个进程”的 task
	mach_vm_address_t       atAddress,
	IOOptionBits            options, ...)
{
	mapping = new IOMemoryMap;
	...
	result = makeMapping(this, intoTask, (IOVirtualAddress) mapping, options | kIOMap64Bit, 0, 0);
	...

IOUserClient::mapClientMemory64(
	IOOptionBits            type,
	task_t                  task,          // ← 调用方进程
	IOOptionBits            mapFlags,
	mach_vm_address_t       atAddress )
{
	...
	err = clientMemoryForType((UInt32) type, &options, &memory );  // 驱动给出 MD
	if (memory && (kIOReturnSuccess == err)) {
		map = memory->createMappingInTask( task, atAddress, options );   // 映射进该进程
		memory->release();
	}

IOSurface 的内核实现（AppleIOSurface 驱动 + IOSurfaceRootUserClient）正是基于这两个原语： 驱动分配 buffer → mapClientMemory64 把它映射进申请进程 → 应用把 surface 句柄 （一个 Mach port）随渲染事务发给 render server → server 侧同样经 UserClient 把同一块物理内存映射进自己。 应用画一个像素，server 立即可见——零拷贝。

2.5 像素内存的生命周期：purgeable token 状态机

// purgeable token 状态机：每个 volatile 对象持有 token，
// 内存压力下内核按 token 顺序把对象页丢弃（vm_object_purge），页表项撤销、记账清零。
// 应用侧重新访问时触发缺页，发现 VM_PURGABLE_EMPTY 后自行重渲染。
// 深读锚点：token L60-62 / volatile 队列 L84-85 / empty L842-867

渲染像素"可丢弃、可重建"的特性正是靠它：layer backing store 标记为 volatile 后， 系统内存吃紧时内核直接回收物理页（不写压缩器、不换出），需要时由应用重新绘制。 这也解释了 iOS 上后台应用回前台时偶发的"白屏→内容渐显"。

2.6 安全门控：平台二进制保护

// 非 macOS 平台：victim 为平台二进制（backboardd / SpringBoard 等）
// 且 caller 为非平台二进制（第三方应用）→ KERN_INVALID_SECURITY。
// 实测推论：mach_vm_read_overwrite / mach_vm_region_recurse / mach_make_memory_entry_64
// 对第三方应用可用于普通进程，对平台二进制全部被拒 → 渲染数据无法被旁路窥探。

§3鸿蒙 ArkUI 渲染管线 ARCH

鸿蒙（HarmonyOS / OpenHarmony）的图形栈是三家中最接近"集中式渲染服务"模型的， 用户的印象基本准确。整体分三个层次：

3.1 全链路总览

3.2 应用进程：组件树的生成

ArkUI 采用声明式范式：ArkTS 前端描述 UI 结构，状态驱动 diff，生成/更新组件树。 组件树（Component）在应用进程内完成状态到渲染属性的换算——这一步 iOS 也在应用进程内做（对应 layer 属性计算）。

3.3 RenderService 渲染进程：渲染树的真正归属

与 iOS 最大的不同在这里：渲染树（RSRenderNode）由独立的 RenderService 进程构建并持有。 应用侧把组件/属性变更通过 IPC 发给 RS，RS 在自己的进程内把组件数据物化成渲染节点树， 并负责：

• 渲染树构建与维护：从应用提交的组件数据构建 RSRenderNode 层级；
• 动画驱动：RS 侧动画（RSRenderAnimation）由渲染进程逐帧插值——与 iOS 的 server 端插值理念一致；
• 绘制与合成：调用 2D 渲染引擎（Skia 系）绘制节点，多 Surface 合成，经 Composer HDI 送显示驱动。

大块像素/纹理数据同样不随 IPC 拷贝，走共享内存（SurfaceBuffer 由 BufferQueue 管理， 应用侧生产、RS 侧消费）。RS 进程作为系统级渲染服务同时服务多个应用， 这与 iOS backboardd 的角色定位类似，但 iOS 的 server 维护的是"应用提交的 layer 树镜像"， 鸿蒙 RS 维护的是"由组件数据构建出的渲染树"——树的语义层级不同（镜像 vs 本尊）。

§4安卓渲染管线 ARCH

安卓是三家中把最多渲染工作留在应用进程内的：渲染树的构建、动画驱动、GPU 命令录制都在应用进程， 系统合成进程（SurfaceFlinger）只做最后一层合成。

4.1 全链路总览

4.2 关键特征

• 渲染树在应用进程内构建：draw 阶段 HardwareRenderer 把 View 层级录制成 RenderNode/DisplayList（GPU 命令的惰性中间表示），树始终属于应用进程；
• RenderThread 是线程不是进程：自 Android 5.0 起每个应用自带渲染线程， 与 UI 线程解耦，但仍在应用进程地址空间内；
• GPU 渲染发生在应用进程：应用直接通过 Vulkan/GLES 驱动把 DisplayList 回放成 GPU 命令， 渲染进 Surface 的 GraphicBuffer；
• 跨进程传的是"成品帧"：应用渲染完的 buffer 经 BufferQueue（Android 12+ 为 BLAST）入队， SurfaceFlinger 只把各窗口的 buffer 做合成（优先 Hardware Composer HAL 卸载给显示硬件， 否则 GPU RenderEngine 兜底）——SF 不构建渲染树、不执行应用动画；
• 动画在应用进程驱动：VSYNC→Choreographer→动画回调链全部在应用进程， 应用必须活着才能动（这也是安卓息屏动画/后台限制策略的由来之一）。

§5三平台渲染架构对比总表

§6最终结论：iOS 是不是鸿蒙那样？

附录XNU 源码锚点清单 SRC

所有 [SRC] 标注均锚定以下文件（xnu-7195.141.2 = iOS 14.8），行号可复核：