多轨音量静态联动通过VolumeManager统一管理，基于基类Track的isPlaying、muted、getVolume/setVolume等属性描述符实现结构化同步，不依赖动态监听。
在流式音视频播放器中实现多轨音量的静态联动，关键不是动态监听或实时计算，而是利用继承结构中已定义的属性描述符（如 isPlaying、volume、muted）建立统一控制入口，并确保各轨道实例共享同一份音量状态逻辑。
复用 RemoteAudioTrack 与 MicrophoneAudioTrack 的共性属性
两者均继承自基类 Track（RemoteTrack / LocalAudioTrack），并公开以下可用于联动的属性：
- isPlaying：反映轨道当前是否处于有效播放/采集状态，可作为联动生效的前提条件
- muted：本地静音开关，影响本地采集输出，但不改变远端轨道自身状态；联动时需区分“全局静音”与“单轨静音”语义
- getVolume() / setVolume()：虽接口名一致，但实际作用对象不同（本地轨道调节采集增益，远端轨道调节播放增益），需统一映射到一个逻辑音量值
定义中心化音量控制器
不直接操作每个轨道的 setVolume()，而是创建一个 VolumeManager 类，内部维护一个基础音量值（如 0–100 标准化范围），并通过描述符访问器自动同步：
- 当调用
VolumeManager.setMasterVolume(75)，它遍历所有已订阅的RemoteAudioTrack和启用中的MicrophoneAudioTrack - 对每个轨道，根据其类型执行适配：
– 远端轨调用track.setVolume(volume * 4)（因 NERtc Android SDK 要求 [0, 400] 区间）
– 本地轨调用track.setVolume(volume)（假设其 volume 接口接受 0–100） - 该过程不依赖事件监听，而是通过已有属性描述符的读写契约完成，属于“静态联动”——即结构确定、行为可预测、无运行时反射或代理注入
保持 muted 与 volume 的语义隔离
静音（muted）是二值开关，音量（volume）是连续调节量。静态联动中应避免将二者混同：
- 若用户点击“全局静音”，应同时设置所有轨道的
muted = true，而非把 volume 设为 0；因为 volume=0 在部分 SDK 中仍可能触发音频回调，而 muted=true 可彻底中断数据流 - 恢复时，仅还原 muted 状态，不重置 volume 值——这符合用户对“静音键”的直觉预期
- RemoteAudioTrack 的
isPlaying可用于跳过未激活轨道，避免无效调用
适配不同平台的 volume 接口差异
Android AudioManager 使用 stream 类型划分音量域，而 WebRTC 或 DingRTC 将 volume 绑定在 Track 实例上。静态联动需在初始化阶段完成映射：
- 在 Activity.onResume() 中调用
setVolumeControlStream(AudioManager.STREAM_MUSIC)，确保物理音量键作用于媒体流 - 将系统音量（0–15）线性映射至 VolumeManager 的 0–100 区间，再分发至各轨道，形成“系统音量 → 应用主音量 → 各轨音量”的静态链路
- 对固定音量设备（如 Chromebook），跳过系统级调节，只走 VolumeManager 内部 setVolume 流程
