边投屏边开会：并行功能的边界与资源分工

在会议室里，用户可能已经把电脑上的内容投到大屏，再加入一个远端会议；也可能先开始视频会议，再把桌面或应用投到会议室大屏。这两种操作顺序，都对应着日常协作中的具体需要。

我们曾为一款投屏设备补充这样的能力。客户希望用较轻量的设备覆盖小型会议室，同时保留原有产品中边投屏边开会的使用方式。缺少这项能力，会成为客户迁移过程中的体验缺口。

先明确两项功能怎样独立运行

会议室投屏服务于现场的大屏观看，视频会议和会中共享服务于远端协作。它们可以同时发生，用户也可能只结束其中一项。

业务方案因此提出了明确的行为要求：会议中可以发起投屏，投屏中也可以开始会议；结束投屏时，会议继续；结束会议时，投屏也能继续。这些规则分别覆盖了两种启动顺序。

内容选择同样需要独立。如果用户投的是某个应用，随后打开会议，该应用仍应保持在大屏上；投整个桌面时，会议窗口则可能随桌面一起被显示。加入会议，不应擅自改变用户原来选择的投屏内容。

此前，本地投屏已经采用 P2P 传输，让电脑与投屏设备之间保持一条本地链路。但在加入远端会议后，原有方式会切换到公网传输，本地大屏的呈现也随之受到影响。

这使方案需要回应一个具体目标：增加远端会议时，本地投屏仍然沿用适合它的传输方式，尽量维持独立投屏时的质量。

在本地投屏与远端屏幕共享同时进行的场景下，电脑需要维持两条屏幕内容传输链路：一路送到本地投屏设备，另一路送给远端会议。两路内容面对的观看端和传输条件不同，媒体规格可以分别安排。

投屏设备则继续承担接收本地投屏内容、呈现到大屏的职责，远端会议由电脑处理。这种分工有助于保持设备侧的能力范围清晰。

在 RTC 侧的需求分析中，我把双链路带来的性能消耗列为需要关注的问题。能力范围首先落在 PC，移动端扩展仍需要评估自己的性能条件。由此可见，传输链路独立之后，还需要检查同一发送设备是否有能力同时支撑它们。

技术设计比较了两种方式。

一种是在单个引擎中支持多个房间，让本地投屏房间和远端会议房间使用各自的连接。另一种是在同一进程中创建两个引擎实例，分别承担本地投屏与远端会议。

两种方式都能对应双链路需求，但改动范围不同。技术设计指出，单引擎多房间需要较大的 SDK 架构调整；多引擎实例已在其他业务中使用，相关机制经过验证，改动相对较小。因此，方案建议先通过多实例满足当前需求，后续再考虑向单引擎多房间演进。

这里的取舍包含两个时间尺度：当前客户需要的能力，以及底层架构后续可能的演进。选择阶段方案时，需要同时检查现有机制的适用性、实现工作量与兼容路径。

相应的接口设计，也没有要求业务直接管理所有引擎与房间细节。技术方案将这些实现封装在投屏相关的操作接口之后，让业务围绕发起、停止、内容输入和状态反馈集成。

这样，业务依赖的是投屏能力的行为契约，内部实现可以保留调整空间。接口设计需要把使用者真正要控制的行为表达清楚，给底层组织方式的变化留下余地。

本地投屏和远端共享能够分别控制，并不意味着它们拥有独立的硬件资源。

两路屏幕内容需要采集、编码和发送，电脑还要处理会议中的其他音视频任务。业务要求本地投屏质量尽量保持原有水平，相应地，方案就需要评估组合场景的性能开销、不同设备的支持范围，以及资源不足时怎样调整媒体规格。

技术方案纳入了编码性能优化、传输调度和性能变化反馈；业务材料也列出了设备分布与性能基线的评估需求。这些安排说明，支持范围需要由实际设备条件支撑，质量目标也需要通过组合场景验证。

声音带来了另一类约束。我在 PRD 中明确指出，两路屏幕共享同时运行时，需要控制声音出口，避免形成回声，并将相应处理放在业务层。

业务方案进一步规定：在这次定义的组合场景中，对共享电脑音频作限制，声音统一由电脑输出。若用户已经在投屏中共享电脑音频，再加入会议，方案要求停止原来的投屏音频输出并提示用户；会议结束后，再按投屏状态恢复。

这个例子体现了功能状态与资源状态之间的区别。投屏画面可以继续，投屏声音却需要因会议的加入而调整。用户需要能够理解变化的原因，操作入口、提示和恢复行为也应与实际策略保持一致。