iOS的画中画（Picture in Picture）能力自iOS 9引入以来一直是视频类App的标配功能。当业务使用WKWebView加载H5播放器时，情况会复杂得多：H5播放器内部的渲染节奏、WKWebView自身的滚动与手势体系、系统级画中画窗口的位置管理三者交织在一起，拖拽画中画窗口时经常出现窗口贴边抖动、越界回弹不自然、甚至位置反复震荡的现象。这类问题本质上是一个典型的非线性动力学问题，窗口与屏幕边界构成了一个多体碰撞系统，而拖拽手势的输入与窗口位置输出之间存在时滞和非线性映射，很容易进入混沌状态。本文尝试用多尺度模型配合混沌同步控制的思路来处理这个问题。
一、为什么画中画窗口拖拽会抖动：问题建模
先看现象。用户快速拖动画中画小窗到屏幕边缘时，窗口并不是平滑地停在边界上，而是先越过边界，再被系统拉回，然后在边界附近来回小幅震荡几次才稳定。慢速拖拽时问题不明显，速度越快震荡越明显，这是典型的速度依赖型非线性反馈特征。
从力学角度看，画中画窗口是一个受约束的质点，其位置状态为(x, y)，速度状态为(vx, vy)。拖拽手势提供外力输入，屏幕边界提供碰撞约束。碰撞过程本身是一个极短时间尺度的事件——窗口与边界接触的瞬间速度方向反转并伴随能量损耗，而拖拽过程是一个中等时间尺度事件，手势的采样、传递到WKWebView再到原生层的链路又引入了额外的延迟尺度。三个尺度耦合在一起，用单一的低通滤波或者简单的clamp处理很难同时兼顾响应速度和稳定性。
多尺度模型的核心思想是分解。把窗口运动拆成三个层次：快尺度处理碰撞冲击，用等效恢复系数描述碰撞能量损耗；中尺度处理拖拽跟踪，保证窗口位置跟随手指；慢尺度处理吸附与稳定，让窗口最终收敛到屏幕的安全角落。每个尺度独立建模、独立设计控制律，再通过状态耦合项关联起来，这就是多尺度建模的基本框架。
二、边界碰撞检测与多尺度状态观测的实现
碰撞检测是整个方案的地基。这里不直接依赖AVPictureInPictureController暴露的有限接口，而是在原生层维护一份窗口状态的镜像，通过CADisplayLink驱动的观测器持续更新。每次状态更新时，检测窗口矩形与屏幕安全边界矩形的交集情况，交集非空即认为发生碰撞，碰撞法线方向由哪条边越界决定。
碰撞后的速度处理采用恢复系数模型：碰撞后速度等于碰撞前速度乘以负的恢复系数e，e取0到1之间，值越小能量损耗越大，窗口越容易稳定。但要注意，画中画窗口不是一个真实的物理小球，e取太小会导致窗口贴边时毫无回弹、观感僵硬，取太大又容易震荡，工程上建议取0.3到0.5之间，并根据拖拽速度自适应调整。
import UIKit
final class PipCollisionObserver {
// 多尺度状态：快尺度（碰撞）、中尺度（拖拽跟踪）、慢尺度（吸附）
struct WindowState {
var position: CGPoint
var velocity: CGVector
var fastScaleEnergy: CGFloat = 0 // 碰撞冲击能量
var midScaleTracking: CGFloat = 0 // 拖拽跟踪误差
var slowScaleAnchor: CGPoint = .zero // 吸附锚点
}
private var state = WindowState(position: .zero, velocity: CGVector.zero)
private var displayLink: CADisplayLink?
private let restitution: CGFloat = 0.4 // 恢复系数
// 安全边界（避开刘海和底部横条）
private var safeBounds: CGRect {
let screen = UIScreen.main.bounds
let inset: CGFloat = 12
return screen.insetBy(dx: inset, dy: inset + 60)
}
func start() {
displayLink = CADisplayLink(target: self, selector: #selector(tick))
displayLink?.add(to: .main, forMode: .common)
}
@objc private func tick() {
let dt: CGFloat = 1.0 / 60.0
// 中尺度：位置积分
state.position.x += state.velocity.dx * dt
state.position.y += state.velocity.dy * dt
// 快尺度：边界碰撞检测与响应
resolveCollision()
// 慢尺度：向吸附锚点收敛
let anchorPull = CGVector(dx: (state.slowScaleAnchor.x - state.position.x) * 0.02,
dy: (state.slowScaleAnchor.y - state.position.y) * 0.02)
state.velocity.dx += anchorPull.dx
state.velocity.dy += anchorPull.dy
}
private func resolveCollision() {
let bounds = safeBounds
if state.position.x < bounds.minX {
state.position.x = bounds.minX
state.velocity.dx = -state.velocity.dx * restitution
state.fastScaleEnergy = abs(state.velocity.dx)
}
if state.position.x > bounds.maxX {
state.position.x = bounds.maxX
state.velocity.dx = -state.velocity.dx * restitution
state.fastScaleEnergy = abs(state.velocity.dx)
}
if state.position.y < bounds.minY {
state.position.y = bounds.minY
state.velocity.dy = -state.velocity.dy * restitution
state.fastScaleEnergy = abs(state.velocity.dy)
}
if state.position.y > bounds.maxY {
state.position.y = bounds.maxY
state.velocity.dy = -state.velocity.dy * restitution
state.fastScaleEnergy = abs(state.velocity.dy)
}
}
}
上面的代码里，快尺度碰撞响应在每次越界时立即执行，位置被硬性拉回边界，速度按恢复系数反转；慢尺度用一个很小的弹性系数把窗口拉向最近的锚点。问题在于中尺度：拖拽速度快时，位置更新与碰撞响应之间会形成负反馈回路，当反馈增益与时滞不匹配时，这个回路就是混沌的来源。
三、混沌同步控制器的设计与代码落地
混沌同步控制的思路是：为受控系统构造一个结构相同但参数可控的响应系统（驱动系统与响应系统），通过设计同步误差反馈律，让响应系统的状态快速跟踪驱动系统的期望轨迹。映射到画中画场景：驱动系统是用户手指的真实轨迹，响应系统是画中画窗口的实际位置，同步控制器的作用是让窗口位置在存在碰撞扰动的情况下依然精确、平滑地跟踪手指轨迹。
同步误差定义为e = x_hand - x_window，控制律取u = k1 * e + k2 * de/dt + k3 * chaosTerm。前两项是经典的PD跟踪，第三项是混沌抑制项，它基于李雅普诺夫稳定性条件设计，目的是抵消碰撞过程中引入的非线性扰动。直观理解：当检测到快尺度碰撞能量突增时，控制器主动增大阻尼，压制震荡；碰撞能量回落后再释放阻尼，恢复灵活的跟踪手感。
final class ChaosSyncController {
private var errorIntegral: CGVector = .zero
// 自适应阻尼：碰撞能量越高阻尼越大，抑制混沌震荡
private var lastError: CGVector = .zero
/// k1 位置增益，k2 速度增益，k3 混沌抑制增益
let k1: CGFloat = 0.35
let k2: CGFloat = 0.18
let k3: CGFloat = 0.60
func control(handTarget: CGPoint,
windowPos: CGPoint,
collisionEnergy: CGFloat,
dt: CGFloat) -> CGVector {
// 同步误差
let ex = handTarget.x - windowPos.x
let ey = handTarget.y - windowPos.y
// 误差变化率
let dex = (ex - lastError.dx) / dt
let dey = (ey - lastError.dy) / dt
lastError = CGVector(dx: ex, dy: ey)
// 混沌抑制项：碰撞能量越大，阻尼越强
// 使用tanh饱和函数避免增益爆炸
let chaosGain = k3 * tanh(collisionEnergy / 50.0)
let ux = k1 * ex + k2 * dex - chaosGain * dex.signum() * min(abs(dex), 100)
let uy = k1 * ey + k2 * dey - chaosGain * dey.signum() * min(abs(dey), 100)
errorIntegral.dx += ex * dt
errorIntegral.dy += ey * dt
// 积分限幅，防止长时间越界累积导致过冲
errorIntegral.dx = max(-80, min(80, errorIntegral.dx))
errorIntegral.dy = max(-80, min(80, errorIntegral.dy))
return CGVector(dx: ux + errorIntegral.dx * 0.01,
dy: uy + errorIntegral.dy * 0.01)
}
}
这套控制器的关键在于tanh饱和函数的引入。如果混沌抑制项直接与碰撞能量成正比，快速拖拽到角落（两条边同时碰撞）时增益会叠加到很高，窗口反而会被锁死在角落附近动弹不得。饱和函数把增益限制在一个合理区间内，保证系统始终工作在稳定域内。从实际调试经验看，k3取0.5到0.8之间效果最好，低于0.4震荡抑制不足，高于1.0则跟踪延迟明显增加。
四、与WKWebView的整合与常见坑点
控制器写好后，还需要把它的输出真正作用到画中画窗口上。系统提供的AVPictureInPictureController并不直接开放窗口位置修改接口，所以工程上一般有两种做法：一是通过协议与H5层协商，由H5侧的视频元素触发画中画，原生层仅做状态镜像与控制建议；二是放弃系统画中画，用自定义的悬浮窗承载AVPlayerLayer，自己实现画中画交互，这样控制自由度完全掌握在自己手里，代价是要处理后台音频、控制器切换等细节。
如果选择系统画中画方案，可以通过对UIScreen的观察和UIWindow层级遍历拿到实际的画中画窗口引用，但这是私有层级，版本升级随时可能失效，建议只在调试阶段用来验证模型的准确性，线上不要依赖。自定义悬浮窗方案则可以直接把上面两个类接入CADisplayLink循环，每帧计算控制量并更新窗口center。
最后说几个调参之外的实际坑。第一，WKWebView的手势传递有大约一到两帧的延迟，这个时滞必须纳入中尺度模型的考虑，dt不要直接用理想值，用displayLink的实际timestamp差值更稳。第二，iPhone的灵动岛区域和底部Home指示条在竖屏与横屏下的安全边界不同，safeBounds要在旋转回调里重新计算。第三，多窗口场景（iPad分屏）下，边界不是UIScreen而是当前windowScene的坐标，直接用屏幕边界会导致窗口飘到别的分屏里去。这三个坑解决后，画中画窗口的拖拽手感能做到和原生App一致，贴边即停、无抖动、快速甩动也能准确吸附到目标角落。