从 9 宫格到 25 宫格：RTC 产品中的体验、资源与取舍

视频会议从 3×3 宫格扩展到 5×5 宫格，用户看到的是一个直观的变化：同一屏幕里能看到更多参会者。

我参与过这样一个项目，在 RTC 侧梳理需求、编写 PRD，并参与业务与研发的方案讨论。随着需求拆解，讨论逐步延伸到服务端和客户端的处理分工、单路画面的分辨率与帧率、弱网下的带宽分配，以及设备能否承受多路视频处理。业务体验、媒体能力和系统约束，在这个项目里紧密地联系到了一起。

回看这段经历，我对 RTC 产品设计形成了一个更具体的理解：产品需要把用户想获得的体验，转化为可实现的能力、可分配的资源，以及资源不足时有先后顺序的取舍。

“更多人同时可见”，需要怎样的画面质量

在多人会议中，用户有时希望一屏看到所有参会者；在集中查看参与情况的场景中，也希望减少翻页，尽可能同时看到更多画面。

这些场景给画面质量带来了新的要求。单屏人数增加后，每个人占据的区域变小，继续给所有小窗口提供原有的视频规格，会增加带宽和处理开销。与此同时，画面仍然需要传递足够的信息，让用户辨认参与者、了解其状态，并关注正在发言的人。

因此，人数、窗口大小、分辨率和帧率需要一起讨论。放大的单人画面与多人小窗口，对清晰度的要求不同；正在发言的人与其他参会者，对动作流畅度的需要也可能不同。窗口尺寸变化时，还需要考虑显示多少人，以及如何调整排列。

当时团队参考了竞品在不同人数下的分辨率、帧率表现，并通过 Demo 和性能测试探索方案。对我来说，这些测试的意义，是让“画面是否够用”与“设备能否承受”有共同的讨论依据。

一个可以复用的产品问题由此变得清楚：用户在当前视图中究竟需要获得什么信息？确定这一点，才有依据讨论应该为每路视频投入多少资源。

架构选择，决定了后续要承担哪些约束

在实现方式上，我们讨论过 MCU 和 SFU 两种方案。

MCU 由服务端合成多路画面，再向客户端下发合成后的视频。客户端需要处理的视频路数较少，但服务端要承担合成和再次编码的开销，画面切换也会受到合成流程的影响。

SFU 由服务端转发各路视频，客户端分别处理并组织布局。这种方式在布局调整和交互上更灵活，也减少了服务端合成带来的处理环节；相应地，客户端需要承担多路视频的接收、解码与渲染压力。

当时研发通过竞品摸底测试，判断 Zoom 在所测宫格场景中采用了多路转发的方式。结合调研和方案比较，团队最终选择 SFU。

这个选择也明确了后续工作的重点：小窗口应该订阅多大的流，多路处理怎样控制开销，哪些设备可以支持，以及性能不足时怎样调整体验。架构方向与这些配套策略需要一起成立。

这段经历让我更注意方案比较中的资源分工。评估一个方案时，要理解它把成本和复杂度放在了哪里，以及选择之后，需要补齐哪些能力。竞品测试可以提供参考，本产品的设备条件、媒体能力和交互要求仍然需要具体评估。

增加 90P，让码流档位覆盖新的使用场景

选择 SFU 后，一个具体问题是：原有最小的视频档位能否适应 25 宫格？

当时会议侧主要使用 180P、360P、720P 三路 Simulcast，也就是同一视频同时提供多个规格，供订阅端按需要选择。面对更密集的小窗口，我们需要增加更小的 90P 码流。

围绕这项需求，讨论进一步落到了档位安排上：用 90P 替换原有的一档，还是增加一路？最终采用的是新增一路，形成包含 90P 在内的四路配置。

回看这个选择，码流档位实际上对应着不同的观看需求。小窗口、大画面和弱网场景，需要的资源配置并不相同。扩展档位可以提供更多选择，同时也需要考虑发布端的编码开销，以及订阅端如何使用新增能力。

兼容性也随之进入方案。旧版本无法发送 90P 时，新版本的 25 宫格体验仍要有相应安排。当时设计中包含提前准备发布能力、逐步放开功能，以及订阅较低帧率的已有码流等处理方式。

这让我认识到，一项底层能力的设计需要覆盖它的使用过程：谁能提供、谁会使用、怎样选择，以及暂时不具备能力的一端怎样参与。业务侧新增一个视图，可能要求媒体层同时调整能力和兼容策略。

弱网时先降谁，体现了对业务体验的理解

25 宫格中的带宽分配，是这个项目里很有代表性的产品问题。

网络变差后，可以减少帧率、降低分辨率，也可以停止部分视频的下发。这些手段对用户的影响不同：降低帧率会减少动作的连续性，降低分辨率会损失细节，停止视频则会让一部分人从可见画面中消失。

如果过早停止其他人的视频，用户就会失去宫格视图带来的多人可见性。如果所有视频平均分配有限资源，又可能影响正在发言者的表达。策略需要同时考虑这两种体验目标。

当时的弱网方案在降低帧率的基础上，增加了对其他视频降低分辨率的步骤，再进一步考虑停止部分视频；同时把活跃发言者纳入同级视频之间的优先级，随着发言者变化重新分配资源。

这里体现出的产品思考，是尽可能保留多人可见的体验，并为当前更重要的内容分配更高质量。不同视频可以有不同的退化顺序，优先级也需要随会议过程变化。

同样，翻页时该订阅哪些视频，也需要与用户当前看到的内容对应。业务上的“暂时看不到”，要进一步明确为媒体层的订阅行为，否则资源分配可能与实际观看需求脱节。

对我来说，理解弱网策略的关键，是能把技术动作与体验损失联系起来。讨论“先降谁”之前，需要先说明哪类信息更重要、哪些损失可以先接受。这样的业务理解，才能进入具体的带宽分配规则。

性能与弱网，需要不同的触发条件和可调的底层能力

多路视频还带来了设备性能问题。网络带宽充足，也不代表客户端有足够的处理能力；设备性能足够，也可能遇到网络受限。两类问题需要分别识别。

当时方案同时考虑了机型能力限制、编码与线程等性能优化，以及较低帧率的订阅能力。动态性能检测和调整也进入了讨论，并有后续迭代的安排。

其中，时域分层订阅提供了一种更细的控制方式：订阅端可以在某个分辨率下选择较低帧率，并在订阅过程中调整。它既可以承接设备性能不足时的需求，也能帮助处理旧发布端无法提供更小分辨率的情况。

从产品设计角度看，这让我更重视上层策略与底层能力之间的关系。业务需要说明什么时候调整、优先保住谁、可以接受怎样的体验；RTC 则需要提供足够细的控制能力，让这些策略能够实现。弱网和性能不足可以使用部分相同的调节手段，但触发依据与策略目标要各自明确。

相应地，验证也需要覆盖具体条件：不同设备、不同网络、不同版本组合，以及视图切换等操作过程。正常条件下能够显示 25 个画面，只是方案验证的一部分。

拆解 RTC 需求的方式

今天再看类似需求，我会围绕三个问题组织思考。

首先，用户需要获得什么信息，什么程度的质量足以支撑当前任务？这决定了资源投入的目标。

其次，实现这种体验，需要怎样的媒体能力和资源分工？这关系到架构、档位、订阅方式与设备支持范围。

最后，条件变差时，应该优先保住什么，允许哪些体验先退化？这需要把业务重要性写进明确的策略。

这三层问题共同构成了我理解 RTC 产品需求的路径。从体验目标出发，经过资源与能力设计，再回到用户实际感受到的质量和变化，产品与研发才能围绕同一个问题持续讨论和验证。