在实现互动直播功能时，你可以遵循以下最佳实践。

建议对连麦主播进行合流的分辨率与单主播模式时推流分辨率保持一致，避免播放器与解码器重置时，导致画面跳帧，确保客户端兼容性更好。
如下图：

对于以下功能或参数，建议你通过业务服务端配置下发：

• RTC视频编码参数（setVideoEncoderConfig)
• 合流转推参数(startLiveTranscoding)
• 使用RTC服务端合流转推还是使用客户端合流转推

如果在客户端应用中硬编码实现，而非使用配置下发实现，参数/功能的更改只能通过客户端发版升级实现，变更流程会比较漫长。

服务端合流转推参数里面主要包含流转推地址、音视频参数、布局信息，RTC 不建议携带频繁更新的业务信息，如主播音量信息，以免给合流服务器带来不必要的压力。
建议通过 RTC SDK 相关 API IMetadataObserver 来添加到视频帧 SEI 里面。如果你自行实现音视频自采集，可以在视频帧中添加和获取 metadata。

建议在使用RTC时，规范化其他模块对 AudioSession 的调用，避免 iOS 14 出现系统 Bug 导致播放声音小。参看 iOS 系统下声音小怎么处理。

出于用户体验考虑，你可以在你的应用界面上通过 UI 告知你的用户所处的 RTC 状态，避免其因一些常规操作造成的预期通话问题产生反馈和投诉。

我们建议你关注以下事件/消息/异常：（仅以 Android 为例）

关于常见的错误码，参看错误码。

通常情况下，从主播发起连麦到看到连麦主播画面，需要经历邀请连麦，邀请确认，双方进房，双方发流，收到远端首帧等一系列过程。这一过程可能会耗时过长，导致用户感知的首帧出图时间过长。参考下文进行优化。

一般的进房逻辑如下：

此时我们注意到：主播 B 会在接受连麦邀请时，加入 RTC 房间，等待来自主播 A 的首帧音视频流。而 A 会在收到接收邀请通知后，完成进房 -> 发流的完整过程。B 需要等待这一完整过程后，才能收到来自 A 的音视频流首帧。这样可能会导致 B 的首帧出图时间过长。

你可以通过调整进房逻辑，优化首帧耗时。优化后的进房逻辑如下：

改进步骤：当主播 A 发起连麦邀请时，可以即刻加入 RTC 房间。这样，B 接收连麦邀请加入 RTC 房间时，无需等待 A 完成完整的进房 -> 发流流程。在实际测试中，这一逻辑的优化，会使受邀主播的首帧出图时间缩短一秒钟以上。

具体实现：在用户接受连麦邀请前，不接受远端音频流且不渲染远端视频，使用户感知的业务建联首帧耗时基本等于等待首帧的时长。

参看如下业务流程图：

你可以通过 1/4 小图策略优化连麦清晰度。
原理如下：

• 主播 pk 场景下：
  连麦合流转推的分辨率 = RTMP直播的分辨率
  进行合流编码时，若主播分辨率未发生变化，则清晰度最佳。一个主播的画面一般占整个合流画面的1/4（如上图）, 其中 RTC 连麦视频宽、高均为合流的1/2；即 RTC_h=h/2; RTC_w=w/2; 即连麦时推对端1/2分辨率。
  例如：
  A主播直播分辨率：540 * 960， B主播直播分辨率：720 * 1280， 那么他们连麦时：
  • 客户端合流：A给B推360 * 640的画面，B给A推270 * 480的画面。
  • 服务端合流：取大分辨率的一半，即都推 360 * 640分辨率。
• 观众连麦（1V6）场景下：
  主播推流分辨率 = 直播分辨率。
  观众分辨率：256 * 256 * 15 * 300。