与 SRTC 的关系
SMeeting 建在 SRTC 之上,不是替代它:meeting.srtc 是可以直接访问的。这意味着:
- 会议 SDK 覆盖不到的底层能力,可以从
meeting.srtc拿 - 渲染组件、轨道类型、编解码工具都来自
srtc—— 所以import { SRTCVideoView, Track } from 'srtc'是常态,不是绕路 - 媒体相关的错误会是
SRTCError(108xxx),会议业务的错误是SMeetingError(208xxx)
必须同时引入两个 HAR。HAR 没有依赖传递性,SMeeting 把
srtc 声明为
peerDependencies,需要由你的工程提供。只声明 smeeting 会在
ohpm install 阶段直接失败。对象模型
SMeetingEngine:唯一入口。账号、会议、媒体、会控全在它上面SMeetingDelegate:所有 52 个事件的统一回调接口SMeetingRemoteVideoView:远端画面组件(替你管订阅生命周期)MeetingUserInfo/RoomInfo/MeetingInfo:成员、房间、会议的数据模型
Channel 这一层 —— 一个引擎实例同时只在一个会议里,
频道的概念被收进了引擎内部。
三段生命周期
一体化的媒体接口
这是 SMeeting 与直接用 SRTC 的最大差别。SRTC 里开麦是四步:requestOpenMic / requestOpenCamera / requestShare 内部完成
「向会议后端申请授权 → 创建本地轨道 → 启动采集 → 发布到频道」。
名字里的
request 是实义的:会议后端可以拒绝。主持人开了全体静音时,
requestOpenMic() 会失败。所以 UI 上应该按 onRoomMicStateChange 提前禁用按钮,
而不是等调用失败再提示。meeting.micTrack / cameraTrack / screenTrack / mcuTrack。
角色与权限
Role 有三档:
所有
admin* 方法都要求主持人或联席主持人身份,否则抛 unauthorized(208004)。
按角色隐藏 / 禁用按钮,而不是靠捕获
unauthorized。 后者的体验是
“点了才知道不能点”。角色变化通过 onUserRoleChange 事件下发。房间开关是「两个字段一组」
会控里的静音、关摄像头这类开关,事件与状态都是成对的:
组合出三种常见形态:
摄像头同理。判断”开麦按钮能不能点”必须同时看这两个字段。
订阅与渲染
远端画面有两种写法:用 SMeetingRemoteVideoView(推荐)
它替你管订阅生命周期 —— 组件出现时订阅、消失时(防抖)退订。
自己订阅 + SRTCVideoView
需要把同一路画面同时渲染在多处(大窗 + 缩略图)时必须走这条,
原因见视频渲染。
TrackDesc:会议里的轨道是按用途命名的
订阅时传
trackDesc 就能选大流还是小流 —— 宫格视图用 cameraSmall、
大窗用 cameraBig,是控制带宽最直接的手段。
MCU 合流
大型会议可以订阅服务端合成的一路画面,而不是 N 路各自订阅:adminUpdateLayout(layoutData) 控制,LayoutType 提供了 20 种预置布局
(auto / full / grids_2 … grids_25 / right_4 / tb_8 等)。
MCU 同时也是录制的基础,见录制。
事件模型
52 个事件全在一个SMeetingDelegate 接口上,只实现关心的那几个。
所有回调第一个参数都是引擎实例,第二个是该事件的数据对象。