层级管理：多个画中画的置顶置底、上移下移逻辑

一、问题的提出：为什么多 PiP 让层级管理重新变难

画中画（Picture-in-Picture, PiP）最初是一个“单例”特性：同一时刻只允许一个小窗悬浮在主内容之上。Android 8.0 引入 PiP 模式时，系统层面默认只维护一个 PiP 窗口；iOS 的 AVPictureInPictureController 同样以单实例为默认语义。然而从 2022 年前后开始，多 PiP 需求快速涌现：视频会议需要同时展示共享屏幕与参会者画面，直播电商需要主画面加商品卡，远程协作需要多路视频流叠加标注。Chrome 在 2023 年前后对 Document Picture-in-Picture API 的推进，使得一个页面可以派生出多个独立 PiP 窗口，层级管理问题由此从“单栈单元素”变成“多栈多元素、且元素间存在约束”。

传统窗口管理器对 Z-order 的处理看似成熟，但多 PiP 引入了三个新变量。第一，PiP 窗口通常由不同进程或不同渲染上下文持有，层级变更需要跨进程同步；第二，PiP 的层级不再是纯视觉问题，还牵涉焦点、输入路由、音频优先级与资源配额；第三，用户对 PiP 的交互预期是“轻量、即时、可预测”，而经典 Z-order 算法在元素数量增长时往往退化为 O(n) 甚至 O(n²) 的重排。本文评述认为，正是这三点叠加，使得层级管理从一个“UI 细节”上升为需要独立建模的系统问题。

本文的分析主线：把多 PiP 层级管理统一抽象为“层级栈 + 约束求解”。栈提供顺序语义，约束提供正确性边界；四类原子操作是栈上的基本变换，而分组、焦点、配额等是叠加在栈上的约束条件。后续每一章都围绕这条主线展开。

1.1 一个具体的失败案例

设想一个远程医疗会诊界面：主窗口是患者影像，三个 PiP 分别是主治医生视频、生命体征仪表盘、以及一个可拖拽的标注工具。当用户把标注工具置顶后，生命体征仪表盘被遮挡；此时若医生视频因网络抖动触发“重新置顶”，标注工具又被压下去，用户正在画的标注被中断。这个案例暴露的问题不是单个操作错误，而是缺少一个统一的层级策略：谁有权置顶、置顶后其他元素如何相对重排、重排是否应保持用户手动调整过的相对顺序。

据 W3C 的 Window Management API 讨论稿（2023）与 Chromium 的 PiP 设计文档（2024）披露，多 PiP 场景下的层级冲突是社区反馈最集中的问题之一。本文评述认为，解决路径不能停留在“给每个操作打补丁”，而应回到栈与约束的形式化建模，先定义清楚语义，再谈实现。

二、经典模型：Z-order 与窗口栈的数学结构

Z-order 的概念可追溯到 1980 年代的窗口系统。X11 协议（1987）明确定义了窗口的 stacking order：每个窗口有一个兄弟节点列表，列表顺序决定遮挡关系。这一模型被后续的 Wayland、macOS Quartz Compositor、Windows DWM 继承。从数学上看，Z-order 就是一个全序关系：给定窗口集合 W，存在一个双射 f: W → {0,1,...,n-1}，f(w) 越大表示越靠前（越靠顶部）。

但真实系统很少用纯全序。原因在于“层叠上下文”（stacking context）：Web 的 CSS 规范（CSS 2.1 第 9.9 节，以及 CSS Positioned Layout Level 3）规定，具有非 static position 且 z-index 非 auto 的元素会创建独立的层叠上下文，其内部子元素的 z-index 只在上下文内比较。这意味着全局 Z-order 实际上是一棵“层叠树”，而非一条链。本文评述认为，多 PiP 的层级管理必须正视这一结构：把每个 PiP 视为一个层叠上下文根节点，其内部元素（如 PiP 内的按钮、字幕）在上下文内排序，而 PiP 之间的排序发生在父层级。

2.1 从全序到偏序：层叠树的偏序语义

设层叠树 T，节点集合 V。对任意两个节点 u、v，若 u 是 v 的祖先，则 u 在 v 之下（祖先先绘制）；若 u、v 无祖先关系，则比较其最近公共祖先下的子树顺序。这定义了一个偏序 ≺。只有当两个节点可比时，遮挡关系才确定；不可比时，视觉结果取决于遍历顺序，这正是许多“层级闪烁”bug 的根源。

表 1 对比了三种模型。数据来源：X11 协议规范（X Consortium, 1987）、CSS Positioned Layout Level 3（W3C, 2023 草案）、以及笔者对 Flutter Engine 源码（2024 分支）的整理。本文评述认为，多 PiP 场景最合适的起点是层叠树，因为它在表达力与实现成本之间取得了平衡；只有当出现“A 必须在 B 之上、B 必须在 C 之上、但 C 又必须在 A 之上”这类循环约束时，才需要升级到约束图并引入冲突检测。

三、四类原子操作的语义与实现

置顶、置底、上移、下移是层级管理的四个原子操作。看似简单，但不同系统对它们的语义定义存在微妙差异，而这些差异正是跨端 bug 的高发区。本节先给出形式化定义，再讨论实现。

3.1 形式化定义

设当前层级序列为 L = [w₀, w₁, ..., wₙ₋₁]，下标越大越靠前。对目标窗口 w（位于下标 i）：

• 置顶（bring-to-front）：将 w 移到序列末尾，其余元素相对顺序不变。结果 L' = L \ {w} + [w]。
• 置底（send-to-back）：将 w 移到序列开头。结果 L' = [w] + L \ {w}。
• 上移（raise-one）：将 w 与其前一个元素交换，即 i → i+1。
• 下移（lower-one）：将 w 与其后一个元素交换，即 i → i-1。

这四类操作在 X11 中分别对应 XRaiseWindow、XLowerWindow、XConfigureWindow（sibling 模式）等。但 X11 的 raise 语义是“放到所有兄弟之上”，而 Web 的 z-index 调整是“设置一个数值”，两者并不等价。本文评述认为，语义差异的根源在于“顺序”与“数值”两种表示：顺序表示天然支持相对操作，数值表示天然支持绝对定位，但数值表示在插入新元素时容易出现“z-index 用尽”或“数值跳跃”问题。

3.2 顺序表示 vs 数值表示

表 2 为笔者基于 X11 协议、CSS 规范与 Chromium 合成器源码整理的对比。一个工程上的折中方案是“稀疏数值 + 惰性重排”：初始分配间隔为 1000 的 z-index，插入时取相邻两者中值；当间隔小于阈值（如 2）时触发局部重排。这一策略在 Chromium 的 cc 层（Chromium Compositor）中有类似实现，见其 layer_tree_host_impl.cc 中的排序逻辑（2024 版本）。

3.3 操作的状态机模型

把每个 PiP 窗口建模为状态机，其状态包括：层级位置（整数）、焦点标志（布尔）、可见性（枚举）、锁定标志（布尔）。四类原子操作是状态转移函数。锁定标志用于表达“该窗口不允许被其他窗口置顶覆盖”，这在多 PiP 中很关键——例如系统级提示不应被用户拖拽的 PiP 遮挡。

// 层级栈的原子操作伪代码（顺序表示 + 锁定约束）
function bringToFront(stack, w):
    if w.locked: return stack          // 锁定窗口不可被移动
    stack.remove(w)
    stack.append(w)
    return stack

function sendToBack(stack, w):
    if w.locked: return stack
    stack.remove(w)
    stack.insert(0, w)
    return stack

function raiseOne(stack, w):
    i = stack.indexOf(w)
    if i < 0 or i == stack.length - 1: return stack
    if stack[i+1].locked: return stack  // 不可越过锁定窗口
    swap(stack, i, i+1)
    return stack

上述伪代码为笔者设计，用于说明锁定约束如何嵌入原子操作。注意 raiseOne 中“不可越过锁定窗口”的规则：这保证了锁定窗口的层级边界不被破坏，同时允许非锁定窗口在其下方自由调整。本文评述认为，这类细粒度约束是经典 Z-order 模型所缺失的，而多 PiP 恰恰需要它。

四、数据结构选型：数组、链表、树与索引映射

层级栈的实现方式直接决定操作复杂度。常见选择有四类：动态数组、双向链表、平衡树（如 order-statistic tree）、以及“数组 + 索引哈希”的混合结构。本节逐一分析。

4.1 动态数组

动态数组（如 C++ std::vector、Java ArrayList）的置顶操作需要移动元素，最坏 O(n)；但缓存局部性好，遍历与渲染顺序读取快。对于 PiP 数量通常在 2~8 个的场景，O(n) 完全可接受。本文评述认为，工程上不应过早优化：当 n ≤ 16 时，数组是最优选择，代码简单且不易出错。

4.2 双向链表

双向链表的置顶/置底是 O(1)（已知节点指针时），上移/下移也是 O(1)。但查找节点需要 O(n)，且缓存局部性差。X11 服务端历史上使用链表维护窗口栈，见 xorg-server 的 window.c（2023 版本仍保留类似结构）。对于频繁重排且 n 较大的场景，链表有优势；但 PiP 场景 n 小，优势不明显。

4.3 平衡树与 order-statistic tree

若需要同时支持“按层级查询第 k 个窗口”和“插入/删除”，order-statistic tree（如红黑树 + 子树大小）可做到 O(log n)。这在需要频繁随机访问层级的场景（如虚拟化列表、大规模窗口管理）有价值。但实现复杂度高，且 PiP 场景 n 小，收益有限。

4.4 混合结构：数组 + 索引哈希

这是笔者推荐的工程方案：用动态数组存顺序，用哈希表存 windowId → 数组下标。置顶时，把目标元素与末尾元素交换，再更新两个下标；上移/下移同理。这样置顶/置底/上移/下移都是 O(1)（均摊），且保留了数组的缓存友好性。唯一代价是“相对顺序”在交换后可能被打乱——但置顶/置底本身就不保证其他元素的相对顺序，所以可以接受。

表 3 为笔者整理的复杂度对比。* 表示已知节点指针。数据来源：Cormen 等《算法导论》第 3 版（2009）关于 order-statistic tree 的分析，以及笔者对 Chromium cc 层与 Android SurfaceFlinger 源码（2024）的阅读整理。本文评述认为，混合结构在 PiP 场景下是“甜点区”：实现成本低，性能足够，且易于调试。

五、多 PiP 场景的批量重排与分组层级

当 PiP 数量超过 3 个，单个操作往往不够用。用户更常见的诉求是“把这组 PiP 一起置顶”“让 A 始终在 B 之上”。这引出了批量重排与分组层级两个概念。

5.1 批量重排：把一组窗口置顶

设目标集合 S ⊆ W，要求把 S 中所有窗口置顶，且 S 内部保持原有相对顺序。算法：先按原顺序收集 S 中元素，从栈中移除，再按原顺序追加到末尾。复杂度 O(n)。若要求 S 内部按新顺序排列，则先排序再追加。

// 批量置顶，保持 S 内部相对顺序
function bringGroupToFront(stack, S):
    ordered = [w for w in stack if w in S]   // 保持原序
    rest    = [w for w in stack if w not in S]
    return rest + ordered

这个算法看似平凡，但有一个陷阱：若 S 中包含锁定窗口，且锁定窗口要求“不可被非锁定窗口越过”，则批量置顶可能违反约束。此时需要先做约束检查，或在追加时跳过锁定窗口。本文评述认为，批量操作是约束冲突的高发点，工程上应把“约束校验”作为批量操作的前置步骤，而不是事后修补。

5.2 分组层级：用组作为中间层

分组层级借鉴了图形编辑器的“图层组”概念：把若干 PiP 归入一个组，组在父层级中占一个位置，组内元素在组内排序。这样，置顶一个组只需移动组节点，组内元素相对顺序不变。实现上，层级结构从线性栈升级为两层树（组 → 元素），或更一般的层叠树。

分组带来的好处是操作粒度更符合用户心智：用户想“把这一组视频都放前面”，而不是逐个置顶。代价是层级查询从 O(1) 变为 O(depth)，且组内组外的约束需要分别处理。本文评述认为，分组是解决多 PiP 层级复杂度的关键抽象，建议在 PiP 数量 ≥ 4 时默认启用。

六、跨端实现差异：Android / iOS / Web / 合成器

不同平台对 PiP 层级的支持程度差异很大，理解这些差异是跨端一致性的前提。

6.1 Android：SurfaceFlinger 与 WindowManager

Android 的层级由 WindowManagerService 管理，最终由 SurfaceFlinger 合成。PiP 窗口在 Android 中是一个特殊的 Activity（通过 enterPictureInPictureMode 进入），其层级由 WindowManager.LayoutParams 的 type 与 flags 决定。多 PiP 在原生 Android 上并非默认支持，需要应用自行管理多个 Activity 或使用系统提供的多窗口能力。据 Android 14 官方文档（2023），PiP 窗口默认位于应用窗口之上、系统窗口之下；若需调整，可通过 setPictureInPictureParams 的 aspectRatio 与 sourceRectHint 间接影响，但无法直接设置 Z-order。本文评述认为，Android 的层级控制权高度集中在系统，应用层能做的主要是“请求”而非“决定”，这与 Web 的 z-index 自由控制形成鲜明对比。

6.2 iOS：UIWindow 与 AVKit

iOS 的 PiP 由 AVKit 提供，层级由 UIWindow 的 windowLevel 决定。多 PiP 在 iOS 上同样受限，通常需要应用自行用多个 UIWindow 或视图层级模拟。据 Apple 开发者文档（2024），windowLevel 是一个浮点数，数值越大越靠前；但系统保留了一些级别（如 UIWindowLevelAlert），应用不应占用。本文评述认为，iOS 的 windowLevel 是“数值表示”的典型，其优点是直观，缺点是需要管理数值区间，避免冲突。

6.3 Web：CSS z-index 与层叠上下文

Web 的层级管理最灵活也最复杂。CSS z-index 只在定位元素上生效，且受层叠上下文限制。Document Picture-in-Picture API（Chrome 116+，2023）允许把 DOM 移入独立 PiP 窗口，此时层级由窗口管理器决定，页面内的 z-index 不再适用。本文评述认为，Web 的多 PiP 层级管理需要区分“页面内 PiP”（用 z-index）与“独立 PiP 窗口”（用 Window Management API 或系统能力），两者的模型不同，不能混用。

6.4 桌面合成器：Wayland 与 X11

Wayland 协议中，层级由合成器决定，客户端通过 xdg-shell 的 set_layer 或类似扩展请求层级。X11 则提供 XRaiseWindow 等直接操作。据 Wayland 协议文档（2024），合成器有权忽略客户端的层级请求，以保证安全与一致性。本文评述认为，Wayland 的“合成器主导”模型更接近未来趋势：层级管理从客户端自由操作转向受约束的请求-响应，这与本文主线的“约束求解”视角一致。

表 4 为笔者基于各平台 2023–2024 年官方文档整理的对比。本文评述认为，跨端一致性不能依赖“统一 API”，而应依赖“统一模型”：在应用层维护一个抽象的层级栈，再针对各平台做适配层，把平台能力映射到栈操作上。这是本文主线在工程上的直接推论。

七、并发、一致性与跨进程同步

多 PiP 场景下，层级变更可能来自多个来源：用户拖拽、应用逻辑、系统事件。这些来源可能在不同线程或不同进程中，导致竞态。

7.1 竞态场景

典型竞态：用户正在把 PiP A 置顶，同时应用逻辑把 PiP B 置顶。若两个操作并发执行，最终顺序取决于调度，可能出现 A 在 B 上、B 在 A 上、或两者都未正确置顶。解决思路有三：加锁串行化、操作合并、或使用乐观并发控制。

7.2 操作日志与重放

一个工程上稳健的方案是“操作日志 + 重放”：所有层级变更先写入日志（append-only），再由单一消费者按序应用到栈上。这样天然串行化，且便于调试与回放。日志条目包含操作类型、目标窗口、时间戳、来源。本文评述认为，操作日志的代价是延迟增加（需等待消费者处理），但在 PiP 场景下延迟容忍度高（几十毫秒无感），收益远大于代价。

7.3 跨进程同步

当 PiP 由不同进程持有，层级变更需要 IPC。常见方案是共享内存 + 原子操作，或通过系统窗口管理器代理。据 Wayland 协议与 Chromium 的 Mojo IPC 文档（2024），跨进程层级同步通常采用“代理 + 版本号”模式：客户端发送请求，服务端返回新版本号，客户端据此更新本地缓存。本文评述认为，版本号机制是解决跨进程一致性的关键，应作为适配层的标准组件。

八、约束求解视角：从命令式到声明式

前七章把层级管理建模为栈操作与约束检查。本章进一步：把整个层级管理视为一个约束求解问题，探索声明式路径。

8.1 声明式层级的表达

声明式层级不直接指定“谁在谁上面”，而是声明约束：A 必须在 B 之上；C 必须可见；D 不可被遮挡。求解器根据约束计算出一个满足所有约束的层级顺序。这在多 PiP 场景下很有吸引力：用户或应用只需声明意图，系统负责求解。

近三年学术界对此有直接研究。例如，2023 年 UIST 会议上有工作探讨“可预测的窗口布局约束求解”，2024 年 CHI 上有关于“多窗口层级意图推断”的研究。本文评述认为，声明式层级的最大挑战是“约束冲突时的降级策略”：当约束不可满足时，系统应给出可解释的降级结果，而不是静默失败。

8.2 增量求解

全量求解在每次操作时重算所有约束，成本高。增量求解只重算受影响的约束子集。对于层级栈，一次置顶操作通常只影响目标窗口与少数相关窗口的约束，增量求解可把复杂度从 O(n) 降到 O(k)，k 为受影响约束数。本文评述认为，增量求解是声明式层级落地的关键，也是未来研究的热点。

九、性能评测与工程落地清单

本节给出一份可操作的工程清单，以及基于模拟数据的性能评测。

9.1 模拟性能数据

以下数据为笔者在本地环境（Intel i7-12700, 32GB RAM, Chrome 124）用 JavaScript 实现的模拟测试，n 为 PiP 数量，操作次数 100 万次，取平均单次耗时（微秒）。数据为模拟数据，仅用于说明趋势。

表 5 为模拟数据。趋势清晰：数组在 n 增大时线性退化，混合结构保持常数。但 n ≤ 16 时两者差距在亚微秒级，实际无感。本文评述认为，工程选型应以“可维护性”优先，混合结构在 n 小时并不带来可感知收益，反而增加代码复杂度；建议在 n 超过 32 时再切换到混合结构。

9.2 工程落地清单

1. 定义层级栈抽象接口：bringToFront / sendToBack / raiseOne / lowerOne / bringGroupToFront。
2. 为每个 PiP 维护元数据：id、locked、focusable、groupId、版本号。
3. 实现约束校验层：在每次操作前检查锁定、焦点、配额约束。
4. 使用操作日志串行化并发变更，消费者单线程应用。
5. 跨进程场景引入版本号，客户端缓存与服务端同步。
6. 为批量操作提供原子性保证：要么全部成功，要么全部回滚。
7. 提供调试视图：可视化当前层级栈与约束状态。
8. 性能监控：记录每次操作耗时，超过阈值时告警。

十、前沿预判与开放问题

基于前九章的分析，笔者对多 PiP 层级管理的未来给出三点预判。

预判一：声明式层级将成为主流。随着 PiP 数量增长，命令式逐个操作的成本与出错率上升，声明式约束更符合用户意图。近三年学术界在约束求解与意图推断上的进展（如 UIST 2023、CHI 2024 的相关工作）为这一转变提供了理论基础。本文评述认为，声明式落地的关键不是求解器本身，而是“冲突降级策略”的设计。

预判二：层级管理将与资源调度融合。PiP 窗口占用 GPU 合成资源、编码资源与网络带宽。层级不仅决定视觉遮挡，也影响资源分配优先级。未来系统可能把层级作为资源调度的输入之一，例如“置顶的 PiP 获得更高帧率”。本文评述认为，这一融合需要跨层协作，目前尚无成熟标准，是开放问题。

预判三：跨端统一模型将出现。当前各平台 API 差异大，应用需要大量适配代码。随着 Web 的 Window Management API 与各平台多窗口能力成熟，一个跨端的层级抽象层有望出现。本文评述认为，这一抽象层的核心不是 API 统一，而是模型统一——即本文主线的“层级栈 + 约束求解”。

开放问题包括：约束冲突的可解释降级、增量求解的最坏情况保证、跨进程层级的实时性边界、以及多 PiP 场景下的用户意图推断精度。这些问题需要系统、HCI 与形式化方法的交叉研究。

拓展资源

• MDN：Document Picture-in-Picture API 教程 — https://developer.mozilla.org/en-US/docs/Web/API/Document_Picture-in-Picture_API
• Android 官方 PiP 文档 — https://developer.android.com/develop/ui/views/picture-in-picture
• CSS Positioned Layout Level 3（W3C 草案） — https://drafts.csswg.org/css-position-3/
• X11 协议规范 — https://www.x.org/releases/current/doc/xproto/x11protocol.html
• Wayland 协议文档 — https://wayland.freedesktop.org/docs/html/