Skip to main content
会议 SDK 把「后端授权 → 建轨道 → 采集 → 发布」收成一个调用。 本页讲用法与取舍,完整签名见媒体控制接口

开麦:三个动作,别混用

不要用 closeMic + requestOpenMic 来实现”静音”按钮。每次都要走一遍后端授权 + SDP 协商,用户会感到明显延迟;而且轨道消失会让对端的 成员列表状态跳变。

开麦可能被拒绝

requestOpenMic 里的 request 是实义的 —— 主持人开了全体静音时后端会拒绝。
状态变化监听 onRoomMicStateChange,两个字段的语义见 会控

响应主持人的请求

主持人调 adminRequestUserOpenMic(uid) 后,你收到:
第二、三个参数(byAdminadminUid)告诉后端”这是响应请求而非自主开麦”。 SDK 不会自动开 —— 必须先征求用户同意,这是隐私边界。
摄像头同理,走 onAdminRequestOpenCamera + requestOpenCamera(preset, true, opUid)

摄像头

摄像头没有 setMuted 这种”假关” —— 用户预期关摄像头就该真的关(指示灯熄灭)。 本地预览:
switchCamera / switchCameraDevice原地换设备、不重建轨道, 所以不需要重新发布 —— 比直接用 SRTC 少一层心智负担。

按需订阅是控制带宽的主要手段

不要一进会就把所有人的视频都订上。跟着摄像头状态走:
再加上大小流选择
20 人宫格全订 cameraBig 会把下行带宽打满,表现是所有画面一起卡。 宫格一律用 cameraSmall
MeetingUserInfo.trackDescs 告诉你某个人有哪些流可订 —— 里面有 screen 就说明他在共享,比自己维护状态可靠。

远端音频:三种”关”

前两个只影响本地播放,带宽照旧消耗,但切回来是瞬时的。 回读状态用 isUserAudioMuted(uid) / getMutedAudioUids()

屏幕共享

requestShare() 返回只代表已发起,用户点同意之后才出帧。 UI 上不要在 await 返回后立刻显示”正在共享”。另外鸿蒙每次重启屏幕采集都要重新授权,没有”沿用上次授权”。
监听别人的共享:
详见屏幕共享

离会前的清理顺序

先关媒体再离会。反过来的话采集可能还在跑一小段时间, 表现是”已经退会了但摄像头指示灯还亮着”。

相关阅读