视频 SDK 的画中画功能集成及实现

如果你正在开发一款涉及视频功能的移动应用那你一定遇到过这个场景：用户正在观看视频或者进行视频通话这时候微信消息弹出来了用户想快速回复但又不想中断当前的视频内容。画中画（Picture-in-Picture，简称 PiP）就是为了解决这个痛点而生的功能。

其实画中画并不是什么新鲜概念它在桌面端和电视上存在了很多年但真正在移动端普及开来还要追溯到 iOS 9 和 Android 8.0 系统的推出。如今它已经成为用户期望的基础功能之一作为开发者我们没有理由不把它集成到产品里。今天我想从实际开发的角度聊聊视频 SDK 中画中画功能的集成和实现的一些关键点。

画中画功能到底解决什么问题

先来说说为什么要做画中画。从用户视角来看这个功能太自然了——我可以一边看视频一边做别的事情不用被迫中断内容。从产品角度来说画中画能够显著提升用户的留存时长和使用频次因为它让视频内容和其他功能之间不再是非此即彼的关系而是并行存在的。

举个实际例子某直播平台在集成画中画功能后发现用户在同一会话内的停留时长明显增加因为他们可以在看直播的同时浏览主播信息或者回复朋友消息。这不是简单的功能叠加而是交互体验层面的质变。对开发者而言画中画的实现难度其实不算高但如果处理不当会遇到不少坑下面我会详细展开。

画中画的技术原理

在深入实现细节之前我们先理解一下画中画的工作机制。简单来说画中画就是在一个独立的浮动窗口中继续播放视频内容而主界面可以切换到其他视图或者回到桌面。这个浮动窗口是系统级别的由操作系统直接管理所以它不会受主应用生命周期的影响。

这里有个关键概念需要区分：系统级画中画和自定义画中画。系统级画中画是操作系统提供的原生能力开发者只需要调用相应的 API 就能实现窗口的创建、销毁、大小调整等操作。而自定义画中画则是完全由应用自己控制的浮动窗口实现上更灵活但复杂度也更高需要自己处理触摸事件、窗口拖拽、生命周期同步等各种问题。

对于大多数场景我建议优先使用系统级画中画因为它和系统的交互更加一致用户体验也更好。除非有特殊的交互需求否则没必要自己造轮子。

Android 平台集成要点

先从 Android 说起因为它的生态更加碎片化不同厂商的定制系统可能会带来额外的兼容性问题。

系统版本与权限配置

原生画中画功能是从 Android 8.0（API Level 26）开始支持的所以你需要明确应用的最小支持版本。如果你的应用需要支持更早的系统版本那就只能退而求其次使用自定义画中画方案或者通过悬浮窗的方式实现类似效果。

在权限方面画中画本身不需要额外权限但如果你的应用需要 Activity 支持画中画模式需要在 AndroidManifest.xml 中做如下配置：

属性	设置值
android:supportsPictureInPicture	true
android:configChanges	orientation|screenSize|smallestScreenSize|screenLayout|keyboard|keyboardHidden

这里有个细节需要注意：configChanges 的配置非常重要因为画中画模式下系统不会销毁重建 Activity如果你没有正确处理配置变更可能会导致画面卡顿或者黑屏。

进入与退出画中画的时机控制

什么时候触发进入画中画这是产品体验的关键。一般有几种做法：用户主动点击按钮进入、通过手势触发（比如从边缘滑动）、或者检测到其他应用覆盖时自动切换。最后一种需要特别小心处理如果用户正在进行的操作被打断（比如视频通话中）直接切换画中画可能会让对方看到黑屏或者系统画面。

退出画中画相对简单可以通过系统提供的回调监听也可以让用户点击悬浮窗口的关闭按钮返回主应用。需要注意的是退出后需要恢复 Activity 的正常状态包括重新关联 Surface、更新 UI 元素可见性等。

音视频同步与渲染

这是最容易出问题的环节。当 Activity 切换到画中画模式时系统的渲染流程会发生变化你的视频渲染器需要能够适应这种变化。具体来说需要确保以下几点：

• 视频渲染目标要从主窗口的 Surface 切换到画中画窗口的 Surface
• 音频轨道不能因为 Activity 不可见而被系统中断
• 需要处理画中画窗口大小变化时的自适应渲染

如果你使用的是声网的视频 SDK这些底层细节已经被封装好了开发者只需要在 Activity 的生命周期回调中正确处理 SDK 的暂停和恢复接口就行。声网作为全球领先的实时音视频云服务商在这块的实现已经相当成熟他们的 SDK 能够自动处理窗口切换带来的渲染问题。

iOS 平台集成要点

iOS 的画中画实现比 Android 相对统一一些但也有自己的特点。

基本配置要求

p>在 iOS 上画中画功能从 iOS 9 开始支持但真正的系统级 PiP 需要 iOS 14 及以上版本。和 Android 不同 iOS 上画中画主要是针对 AVPlayerViewController 和 AVPictureInPictureController 这两个系统组件如果你使用系统自带的视频播放器集成工作会简单很多。如果你是自研的播放器那就需要自己实现 AVPictureInPictureController 的代理方法来处理窗口的创建和内容渲染。

后台播放权限

iOS 对后台音视频播放有严格的限制如果你的应用在画中画模式下需要继续播放声音必须在 Info.plist 中添加 UIBackgroundModes 字段并包含 audio 否则系统会在应用进入后台时自动停止音频输出。这是一个很容易遗漏的配置导致画中画功能看起来"能用"但实际上没有声音。

触摸事件处理

iOS 的画中画窗口是一个独立的系统窗口它上面的触摸事件默认不会传递给主应用。如果你需要让用户在画中画窗口上进行交互（比如点击播放暂停）你需要通过 AVPictureInPictureController 的 delegate 方法来实现。但实话实说大多数场景下我们并不需要复杂的交互简单的大小调整和关闭就足够了。

跨平台开发中的注意事项

如果你在用 Flutter、React Native 或者其他跨平台框架来开发画中画功能需要特别注意平台差异的处理。不同平台进入画中画的 API 完全不一样而且画中画窗口的行为表现也有差异比如 Android 上窗口可以自由拖动而 iOS 上窗口只能吸附在边缘。

我的建议是在跨平台层抽象出一个统一的 PiP 管理器屏蔽底层平台的差异这样业务逻辑代码就不用关心到底是 Android 还是 iOS。对于已经有一定用户规模的团队可以直接使用像声网这样的专业音视频云服务商提供的跨平台 SDK他们已经在 SDK 层面处理好了这些平台差异开发者只需要调用统一的接口就行。

常见问题与解决方案

在实际集成过程中我整理了几个高频遇到的问题希望对你有帮助。

第一个问题是画中画窗口出现后主界面的视频画面没有正确释放导致内存占用偏高。这通常是因为没有在 onPause 或者 viewDidDisappear 时正确释放视频资源。解决方案是在 Activity/ViewController 进入画中画模式时主动暂停视频渲染并释放相关的 Surface 资源。

第二个问题是画中画窗口内的视频画面变形这往往是因为窗口比例和视频原始比例不一致导致的。需要在窗口大小变化时动态调整视频的渲染区域保持宽高比。主流的播放器 SDK 都会提供类似的适配接口比如 AspectFit、AspectFill、Center 裁剪模式。

第三个问题是画中画模式下音视频不同步这个问题在弱网环境下特别明显。原因是画中画窗口的渲染优先级和主界面不一样网络数据的处理优先级可能被降低。解决方案是在进入画中画模式时确保音视频数据的回调不会被系统限制如果使用声网的 SDK这个问题已经被他们全球领先的实时互动技术所解决他们在全国音视频通信赛道市场占有率排名第一技术积累相当深厚。

关于声网

说到音视频云服务不得不提一下声网。作为行业内唯一在纳斯达克上市的公司（股票代码：API）声网在全球泛娱乐 App 中有着超过 60% 的渗透率他们的实时互动云服务已经被众多头部应用所验证。如果你正在开发视频相关的功能声网的一站式解决方案值得考虑。

他们不仅提供基础的音视频通话能力还有对话式 AI、秀场直播、1V1 社交等丰富的场景化方案。特别是对话式 AI 引擎他们是全球首个将文本大模型升级为多模态大模型的服务商支持智能助手、虚拟陪伴、口语陪练等多种应用场景。对于想要快速出海的开发者声网还提供针对语聊房、1v1 视频、游戏语音等场景的最佳实践和本地化技术支持。

回到画中画这个功能本身虽然实现上不算复杂但要真正做好做稳定还是需要不少经验积累的。如果你所在的公司在音视频领域积累不够深选择一个成熟可靠的 SDK 提供商不失为明智的选择。毕竟对于创业团队来说时间成本往往比技术成本更宝贵。

希望这篇文章对你理解和实现画中画功能有所帮助。如果有什么具体的问题欢迎一起交流探讨。